I'm a software engineer that wrote my own SMTP delivery agent. I recently added the STARTTLS support to my software and I was doing some testing, when I noticed that Google's SMTP transfer agents are not sending STARTTLS
commands to my server. This was very surprising to me!
Does anyone know why Google's mail servers don't even attempt to upgrade the connection to a secure one?
My logs reveal that many transfer agents are upgrading their connections, including Microsoft operated transfer agents.
My server is accepting connections on ports 25, 587, and 2525. I did some experimenting to determine if Google's transfer agent would send STARTTLS
if it were forced to connect to 587 instead of 25, by temporarily closing port 25. But I stopped getting delivery attempts altogether at that point. My understanding is that port 25 is the standard port used for relaying email and that 587 is standard for submission, so that makes sense I guess.
Here's a log sample from Microsoft's MTA:
[20:00:00 INF] Session established
< 220 ***REDACTED***
> EHLO NAM11-DM6-obe.outbound.protection.outlook.com
< 250-STARTTLS
< 250 8BITMIME
> STARTTLS
< 220 Go ahead
[20:00:01 INF] Connection is now using TLS
> EHLO NAM11-DM6-obe.outbound.protection.outlook.com
< 250 8BITMIME
> MAIL FROM:<***REDACTED***>
< 250 ok
> RCPT TO:<mstest@***REDACTED***>
< 250 ok
> DATA
< 354 ok
…
And when Google connects to my server:
[20:10:00 INF] Session established
< 220 ***REDACTED***
> EHLO mail-ed1-f45.google.com
< 250-STARTTLS
< 250 8BITMIME
> MAIL FROM:<***REDACTED***>
< 250 ok
> RCPT TO:<***REDACTED***>
< 250 ok
> DATA
< 354 ok
…
And as you can see, no attempt to upgrade the connection. I'm still learning the protocols and conventions, so if there's a reason for this and I can encourage more transfer servers to upgrade to TLS, I'd like to know what I can do. Or if there's just some other reason that is outside of my control that would be useful information, too.
Thanks!
The documentation that describes how your server should respond to the EHLO command is in rfc5321 4.1.1.1, the notable difference to what you send is the first line in your response contains your domain, only after that extensions may be listed.
Quoting the example from rfc2487 6 - it has the domain (and customary greeting) before the STARTTLS offer:
I would not worry too much about Microsoft attempting the command despite not being properly announced as available.. this one time they have it right, it does not really matter how broken the server is, potentially private messages should be sent over connections with some level of privacy. Also, outside of education it is probably not the best solution to reimplement that stuff from scratch.