Mailer component not working anymore

[Bathory]

Hello,

Does anyone know why suddenly the mailer component would stop working? Production environment, Amazon Linux 2, SFS2X 2.15.0, stable for months, no change on my part. I can still log in to my webmail app using the credentials provided in my server.xml file. SFS2X log doesn't indicate an exception. So no error but it doesn't send mail anymore.

Thank you

Code: Select all

SFSEmail myEmail = new SFSEmail(Const.EMAIL_SUPPORT, email, objet, message);
try {
    SmartFoxServer.getInstance().getMailService().sendMail(myEmail);
    }
catch(MessagingException me) {
     trace("Java me " + me.getMessage());
}

[Lapo]

Hi,
maybe something changed on the SMTP server side?
If you have control over the SMTP server you might want to check its logs, although I would also expect some kind of error to show up in the SFS2X logs.

Cheers

[Bathory]

The web host support team says nothing changed on their side and they don't log outgoing e-mails. I restarted SFS last night to no avail, will try to restart the instance tonight.
Meanwhile if you are aware of another log I could check in the Linux environment...

Thank you

[Bathory]

Hello,

Updating this just to say the problem was, I think, Amazon not allowing EC2 to send e-mails anymore for safety and anti-spam reasons. Even though I was making good use of it.

Basically had to sign up to Amazon SES, problem solved.

[Lapo]

Thanks for the update. Good to know.

Cheers

[Bathory]

Hello everyone,

A follow up to this. I still have the same environment (SFS2X 2.15 running on Amazon EC2) and as concluded above, had to make the java extension make a call to Amazon Simple E-mail Service (SES) with credentials created inside that service otherwise Amazon seems to block SFS's mailer now.

But I have been receiving these e-mails from them for a while:

"We have identified TLS 1.0 or TLS 1.1 connections to AWS APIs from your account that must be updated for you to maintain AWS connectivity. Please update your client software as soon as possible to use TLS 1.2 or higher to avoid an availability impact. (......) Please see the following for further details on the TLS 1.0 or TLS 1.1 connections detected from your account to SES using Simple Mail Transfer Protocol (SMTP) to between September 19, 2023 and October 3, 2023. We are unable to provide UserAgent for these connections because it is part of the HTTP protocol, but is not part of SMTP connections."

Not sure how to solve this. I'm trying my luck in AWS communities but also here.

First, if I run this in Putty:

Code: Select all

openssl ciphers -v | awk '{print $2}' | sort | uniq


It returns:

Code: Select all

SSLv3
TLSv1.2


Inside my java extension in the build Libraries I've added javax.mail.jar (version 1.6.2 I think, according to the manifest files inside it). It's sending e-mails like it should using the following code, but I don't know what's missing to force TLS 1.2. Any help appreciated:

Code: Select all

Properties props = System.getProperties();
props.put("mail.transport.protocol", "smtp");
props.put("mail.smtp.port", 587);
props.put("mail.smtp.starttls.enable", "true");
props.put("mail.smtp.auth", "true");
props.put("mail.smtp.ssl.protocols", "TLSv1.2");

// Create a Session object to represent a mail session with the specified properties.
Session session2 = Session.getDefaultInstance(props);

try {
    // Create a message with the specified information.

    MimeMessage msg = new MimeMessage(session2);
    msg.setFrom(new InternetAddress("myemail@email.com","Game App"));
    msg.setRecipient(Message.RecipientType.TO, new InternetAddress("recipientemail@email.com"));
    msg.setSubject("Subject");
    msg.setContent("Test e-mail","text/html");

    // Add a configuration set header. Comment or delete the
    // next line if you are not using a configuration set
    //msg.setHeader("X-SES-CONFIGURATION-SET", CONFIGSET);  commented, not actually used

    // Create a transport.
    transport = session2.getTransport();

    // Send the message.
    ext.trace("Sending...");

    transport.connect("email-smtp.us-east-1.amazonaws.com", 587, MyUserName, MyPassword);

    // Send the email.
    transport.sendMessage(msg, msg.getAllRecipients());
    ext.trace("Email sent!");

    // Close and terminate the connection.
    transport.close();

}
catch (MessagingException e)
 {       
        ext.trace("A Messaging Error occurred: " + e.getMessage());
 }
catch (UnsupportedEncodingException e) {
       
        ext.trace("Unsupported encoding Error occurred: " + e.getMessage());
 }



[Bathory]

More info about this.

In the messages that Amazon sent, the list of clients that don't use the proper TLS version according to them includes the EC2 instance's IP address and also my own IP, because last month I used SFS2X v2.13 standalone on a Windows computer running the same code as above to send marketing e-mails, through the same credentials and SES endpoint.

So that's actually 2 different sources not using the right protocol and it might be easier to figure out on Windows what's going on.

My JRE release file on it has: JAVA_VERSION="1.8.0_102" OS_NAME="Windows" OS_VERSION="5.2" OS_ARCH="amd64" (the EC2 server's has JAVA_VERSION="1.8.0_222" OS_NAME="Linux" OS_VERSION="2.6" OS_ARCH="amd64")

Adding those lines of codes in the extension program:

Code: Select all

ext.trace("mail.smtp.ssl.protocols=" + props.get("mail.smtp.ssl.protocols"));
       
 try {
       ext.trace(String.join(" ", SSLContext.getDefault().getSupportedSSLParameters().getProtocols()));
 }
 catch(NoSuchAlgorithmException fff) {
           ext.trace(fff.getMessage());
 }

Prints:

mail.smtp.ssl.protocols=TLSv1.2

SSLv2Hello SSLv3 TLSv1 TLSv1.1 TLSv1.2


In C:\SmartFoxServer_2X\jre\lib\security\java.security around line 537 there is

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768

if I add TLSv1 at the end, then restart the standalone SFS2X app and try to send the e-mail with it, it produces this exception

14:04:29,398 INFO [pool-1-thread-3] Extensions - {MyExt}: Sending...
14:04:29,584 INFO [pool-1-thread-3] Extensions - {MyExt}: A Messaging Error occurred: Can't send command to SMTP host;
nested exception is:
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)


This exception DOES NOT happen if instead of adding TLSv1 to the disabled algorithms in java.security, I add TLSv1.1 or TLSv1.2. It sends the e-mail successfully in those cases.

So definitely, it still tries to use v1 instead of v1.2 despite the props.put("mail.smtp.ssl.protocols", "TLSv1.2"); line.

There seems to be something in the Java environment not set properly, or I may be using the wrong parameters or port to connect to SES.

Their (Amazon SES) SMTP Settings page says to use this:
--------------
SMTP endpoint
email-smtp.us-east-1.amazonaws.com

Transport Layer Security (TLS)
Required

STARTTLS Port
25, 587 or 2587

Custom SSL client support
-

TLS Wrapper Port
465 or 2465
--------------

The code above uses STARTTLS, I connect on port 587. 2587 also works. 25 will timeout if I try it.

[Lapo]

Hi,
I am a bit confused by this and I am no TLS expert...
As I understand it, it is the server that chooses which version to use during the first handshake. If a mail server wants to enforce TLS1.2 it can do it and the client might fail, if it has no support for that version.

See here:
https://security.stackexchange.com/ques ... and-server

If that's the case I'd expect the Amazon service to remove any TLS version < 1.2 from their "white list" and I'd also expect SFS to continue working since Java 8 supports TLS 1.2.
If that's not the case you may want to download the latest JRE 8 available and replace what SFS2X currently uses (the embedded version in your SFS2X is pretty old)

Let us know

[Bathory]

Thanks, as I'm even less of an expert

It's possible that it continues working past their December 2023 deadline, I certainly hope so.

If not, it seems you're right that upgrading to a newer version of SFS2X that ships with a more up-to-date JRE would solve it. Or just replacing the JRE. I just don't like doing this in an otherwise stable environment hehe. Not that I don't trust 2.19, it's just a bit of work and I'm fearful of not being able to redeploy the SSL quickly enough and that players will complain.

If you look at the java.security file from the version that comes with SFS2X 2.19 (its location has changed to /conf/security), TLSv1 and TLSv1.1 are the ones that are disabled. I'm able to send mails with that version with the same code connecting to SES. And if I add TLSv1.2 in the disabled list, it now fails with a different error message about socket issue. So it's the other way around.

I'll let you know how that goes. Thanks

[Lapo]

I guess it makes sense, if you disable TLS 1.2 (in addition to 1.1. and 1.0) it probably doesn't have anything else to use

[Bathory]

Haha right! Sorry. To be more precise the error is the same whether I disable everything or only 1.2:

13:18:00,796 INFO [pool-1-thread-1] Extensions - {Mini}: Sending...
13:18:01,061 INFO [pool-1-thread-1] Extensions - {Mini}: A Messaging Error occurred: Could not convert socket to TLS