Wt

Hi Mark,

can I assume that in the wt_config.xml you have the following values?

<smtp-host>localhost</smtp-host> (optional)
<smtp-port>465</smtp-port>
<smtp-self-host>localhost</smtp-self-host> (optional)
<smtp-transport-encryption>tls</smtp-transport-encryption>

Does the application instance crash when you try to send the confirmation email, or does it just silently fail to do so?

From your response on this thread, it seems to me the latter is the case?

Matthias (Matt?),

The wt_config.xml has the following for each:

            <property name="smtp-host">smtp.us.appsuite.cloud</property> 
            <property name="smtp-port">465</property> 
            <property name="smtp-self-host">my-website-url.com</property>
            <property name="smtp-transport-encryption">TLS</property> 
            <property name="smtp-auth-method">login</property> 

Followed by the userid and password XML entries for my mail server. The local instance can log-in and successfully send. The AWS instance just fails silently.

From the output you provided from the SMTP codes, it seems that the email is completely sent over to the SMTP provider, since the last two response codes are 250 and 221 respectively.

Is there perhaps a way to monitor what happens inside your email provider? It seems to me that the email gets correctly queued, but then is rejected eventually by the provider or some exchange point.

What is confusing about that is I'm using the exact same mail server using the exact same credentials and getting the exact same responses.

The only difference is one server is Ubuntu 22TLS on AWS using SSL, HTTPS, TLS over 465 etc, and the dev machine is an M1 Mac running with no SSL, but plain HTTP and TLS over 465.

There is not a way to monitor the e-mail server. It's hosted by Encirca and is not under my control.

I should add that my dev environment is compiled against OpenSSL 3.x. Both machines are built using identical cmake scripts.

I switched my mail server to the AWS SES mail server and I think I'm getting somewhere, but I need more debug info.

I'm getting a 554 error when I try to send the actual message. Right now, Client.C is only returning [error] "Mail.Client: Unexpected response 554"

Is there a structure that gives more information from the mail server than just the error code? Seems like everything is run through the following method: failIfReplyCodeNot(ReplyCode::Ok); , which doesn't put much in to the log.

Nevermind... removing "-debug" from wt_config.xml sure is helpful! (Doh!)

The formatting of the From and To portions of the emails are causing problems (email addresses not verified, etc.)

I got it working!!!

I spun up an AWS SES instance, followed the directions to set up the SMTP credentials which I then put in to wt_config.xml, entered the test e-mail addresses and everything worked!

I'm going to re-compile with Release and -O3 to make absolutely sure everything is good to go.

Now I can go find some customers! (And pay Emweb a commercial license fee!)

Hello Mark,

that's good to hear. When you said:

The formatting of the From and To portions of the emails are causing problems (email addresses not verified, etc.)

does that mean that from Wt's side there is something going wrong with SMTPS, or that the data you entered into the Wt interface simply contained bad email addresses?

Maybe "formatting" is the incorrect way to say it, that's just the definition that I found for that return code.

The actual reason is that AWS didn't recognize the email addresses. Once I created an AWS SES instance and defined the "Verified Identities", meaning I told AWS what e-mail address I was using to send and receive, which they, in turn, sent an e-mail verification to those e-mail addresses. Then it started working. I changed it back to Encirca and it still works, but only for those verified identities until they grant me access out of the sandbox to a production status. I'll revert back to AWS instead of Encirca because AWS still sends out the e-mail even though Encirca is hosting the mail service. I guess it's a blind send, but it's all been verified and credentialed, so it works.

I also tested with the code at "Release" and optimization set at -O3. No issues. (I'm on Ubuntu 22LTS.)

Ok, thank you for the additional information!