Gmail is sure piling up its problems like never before in my 8-10 years of using it. In addition to the other issues of the last two months, we now have:
The recent intermittent Gmail problem in sending from your own SMTP server (if you don't want your "send from" address at your own domain name to be an "alias" of your Gmail address) has now become an "always happens" problem. Here's the failure message you get from Gmail:
Message not delivered You're sending this from a different address or alias using the 'Send mail as' feature. The settings for your 'Send mail as' account are misconfigured or out of date. Check those settings and try resending. TLS Negotiation failed, the certificate doesn't match the host.
After much experimenting and Internet research, I found the answer buried in Gmail support forums - an answer from a smart user, not from Google. In my case, since I use Tucows/OpenSRS for my SMTP server, the chain is
smtp-1.marityme.com [cname] --> smtp.marityme.com.cust.a.hostedemail.com --> 216.40.42.5 --> [RDNS] mail.hostedemail.com
Tucows/OpenSRS specifies the server *smtp.marityme.com.cust.a.hostedemail.com http://smtp.marityme.com.cust.a.hostedemail.com*, which I cname to for concenience and elegance, and that resolves to * 216.40.42.5*, whose RDNS lookup gives *mail.hostedemail.com http://mail.hostedemail.com*. Now, unlike before, Gmail expects me to give *mail.hostedemail.com http://mail.hostedemail.com* as the SMTP server in the "send from" configuration, and then the sending mechanism works again (at least yesterday and today, who knows about tomorrow).
The purpose of this post is to save other members days of headache trying to figure this one out.
Hartmut W Sager - Tel +1-204-339-8331
Yeah, we got bitten by this one at work last week (actually started noticing problems around Wednesday or Thursday of the previous week, but only resolved it last week). We had some users within the department who wanted to manage their CS e-mail via Gmail, and had set up their Gmail to send out via our SMTP server, which had worked fine until Google unilaterally decided on this new restriction, which most likely violates several standards.
Since we control reverse DNS on our domain, I was able to fudge things up to get Google to accept our cert (a legitimate cert, issued by Globalsign, that has multiple generic aliases in the SAN list, but intentionally avoided the canonical host name, since these generic aliases should be allowed to migrate to different physical servers, transparently). I found out that you can have multiple PTR records on one IP address, which is completely legal in DNS, but not usually considered good practice (or so I thought). Of course, this second PTR record caused some things to fail in a non-deterministic way, since lookups on the IP address gave the PTR records in pseudo-random order, causing code that only looked at the first answer to get inconsistent results. Grrr!
Thanks, Google, for once again messing with standards, and forcing everyone else to bend to your will!
Gilbert
On 2020-04-18 3:14 p.m., Hartmut W Sager wrote:
Gmail is sure piling up its problems like never before in my 8-10 years of using it. In addition to the other issues of the last two months, we now have:
The recent intermittent Gmail problem in sending from your own SMTP server (if you don't want your "send from" address at your own domain name to be an "alias" of your Gmail address) has now become an "always happens" problem. Here's the failure message you get from Gmail:
Message not delivered You're sending this from a different address or alias using the 'Send mail as' feature. The settings for your 'Send mail as' account are misconfigured or out of date. Check those settings and try resending. TLS Negotiation failed, the certificate doesn't match the host. After much experimenting and Internet research, I found the answer buried in Gmail support forums - an answer from a smart user, not from Google. In my case, since I use Tucows/OpenSRS for my SMTP server, the chain is smtp-1.marityme.com http://smtp-1.marityme.com [cname] --> smtp.marityme.com.cust.a.hostedemail.com http://smtp.marityme.com.cust.a.hostedemail.com --> 216.40.42.5 --> [RDNS] mail.hostedemail.com http://mail.hostedemail.com
Tucows/OpenSRS specifies the server *smtp.marityme.com.cust.a.hostedemail.com http://smtp.marityme.com.cust.a.hostedemail.com*, which I cname to for concenience and elegance, and that resolves to *216.40.42.5*, whose RDNS lookup gives *mail.hostedemail.com http://mail.hostedemail.com*. Now, unlike before, Gmail expects me to give *mail.hostedemail.com http://mail.hostedemail.com* as the SMTP server in the "send from" configuration, and then the sending mechanism works again (at least yesterday and today, who knows about tomorrow).
The purpose of this post is to save other members days of headache trying to figure this one out.
How did you (and your work colleagues) come to realize that the RDNS name is what Google cert is trying to match?
Hartmut W Sager - Tel +1-204-339-8331
On Mon, 20 Apr 2020 at 09:20, Gilbert E. Detilllieux < gedetil@cs.umanitoba.ca> wrote:
Yeah, we got bitten by this one at work last week (actually started noticing problems around Wednesday or Thursday of the previous week, but only resolved it last week). We had some users within the department who wanted to manage their CS e-mail via Gmail, and had set up their Gmail to send out via our SMTP server, which had worked fine until Google unilaterally decided on this new restriction, which most likely violates several standards.
Since we control reverse DNS on our domain, I was able to fudge things up to get Google to accept our cert (a legitimate cert, issued by Globalsign, that has multiple generic aliases in the SAN list, but intentionally avoided the canonical host name, since these generic aliases should be allowed to migrate to different physical servers, transparently). I found out that you can have multiple PTR records on one IP address, which is completely legal in DNS, but not usually considered good practice (or so I thought). Of course, this second PTR record caused some things to fail in a non-deterministic way, since lookups on the IP address gave the PTR records in pseudo-random order, causing code that only looked at the first answer to get inconsistent results. Grrr!
Thanks, Google, for once again messing with standards, and forcing everyone else to bend to your will!
Gilbert
On 2020-04-18 3:14 p.m., Hartmut W Sager wrote: [... deleted ...]
Initially, it was just a guess, based on the reported error message. Then I started to suspect that was the problem. (Knowing that the host names used in the config were in the SAN list, and that the canonical name wasn't.) Then, one of our grad students found these forum posts...
Issue: https://support.google.com/mail/thread/38789651?hl=en Recommended answer: https://support.google.com/mail/thread/38336515?msgid=39890656
... which confirmed my suspicions. Adding the PTR record fixed the problem, and further confirmed my suspicions and what was claimed in the forum posts.
Incidentally, cranking the sendmail LogLevel past 11 (and all the way up to 14) didn't shed any extra light. All we saw was that connections from google.com servers would start TLS negotiations, and then just disconnect before issuing any SMTP commands. I had to rely on users to send me error messages from their bounce messages to see what was failing on the client side, i.e. Google's side:
TLS Negotiation failed, the certificate doesn't match the host.
Not much to go on!
Gilbert
On 2020-04-20 10:03 a.m., Hartmut W Sager wrote:
How did you (and your work colleagues) come to realize that the RDNS name is what Google cert is trying to match?
Hartmut W Sager - Tel +1-204-339-8331
On Mon, 20 Apr 2020 at 09:20, Gilbert E. Detilllieux <gedetil@cs.umanitoba.ca mailto:gedetil@cs.umanitoba.ca> wrote:
Yeah, we got bitten by this one at work last week (actually started noticing problems around Wednesday or Thursday of the previous week, but only resolved it last week). We had some users within the department who wanted to manage their CS e-mail via Gmail, and had set up their Gmail to send out via our SMTP server, which had worked fine until Google unilaterally decided on this new restriction, which most likely violates several standards. Since we control reverse DNS on our domain, I was able to fudge things up to get Google to accept our cert (a legitimate cert, issued by Globalsign, that has multiple generic aliases in the SAN list, but intentionally avoided the canonical host name, since these generic aliases should be allowed to migrate to different physical servers, transparently). I found out that you can have multiple PTR records on one IP address, which is completely legal in DNS, but not usually considered good practice (or so I thought). Of course, this second PTR record caused some things to fail in a non-deterministic way, since lookups on the IP address gave the PTR records in pseudo-random order, causing code that only looked at the first answer to get inconsistent results. Grrr! Thanks, Google, for once again messing with standards, and forcing everyone else to bend to your will! Gilbert On 2020-04-18 3:14 p.m., Hartmut W Sager wrote: [... deleted ...]
Quoting from the "solution":
It is rare, but it is possible that the server will use a different
certificate on different ports, so switching between 465, 587 and 25 might yield better results. Again, the best source for the settings is your email provider.
I tested both 465 SSL and 587 TLS right after encountering the solution, and they both work, though I am under the impression that Gmail favours TLS (whereas I've hitherto always been using SSL). Any thoughts on that?
Hartmut W Sager - Tel +1-204-339-8331
On Mon, 20 Apr 2020 at 10:47, Gilbert E. Detilllieux < gedetil@cs.umanitoba.ca> wrote:
Initially, it was just a guess, based on the reported error message. Then I started to suspect that was the problem. (Knowing that the host names used in the config were in the SAN list, and that the canonical name wasn't.) Then, one of our grad students found these forum posts...
Issue: https://support.google.com/mail/thread/38789651?hl=en Recommended answer: https://support.google.com/mail/thread/38336515?msgid=39890656
... which confirmed my suspicions. Adding the PTR record fixed the problem, and further confirmed my suspicions and what was claimed in the forum posts.
Incidentally, cranking the sendmail LogLevel past 11 (and all the way up to 14) didn't shed any extra light. All we saw was that connections from google.com servers would start TLS negotiations, and then just disconnect before issuing any SMTP commands. I had to rely on users to send me error messages from their bounce messages to see what was failing on the client side, i.e. Google's side:
TLS Negotiation failed, the certificate doesn't match the host.
Not much to go on!
Gilbert
On 2020-04-20 10:03 a.m., Hartmut W Sager wrote:
How did you (and your work colleagues) come to realize that the RDNS name is what Google cert is trying to match?
Hartmut W Sager - Tel +1-204-339-8331
On Mon, 20 Apr 2020 at 09:20, Gilbert E. Detilllieux <gedetil@cs.umanitoba.ca mailto:gedetil@cs.umanitoba.ca> wrote:
Yeah, we got bitten by this one at work last week (actually started noticing problems around Wednesday or Thursday of the previous week, but only resolved it last week). We had some users within the department who wanted to manage their CS e-mail via Gmail, and had set up their Gmail to send out via our SMTP server, which had worked fine until Google unilaterally decided on this new restriction, which mostlikely
violates several standards. Since we control reverse DNS on our domain, I was able to fudgethings
up to get Google to accept our cert (a legitimate cert, issued by Globalsign, that has multiple generic aliases in the SAN list, but intentionally avoided the canonical host name, since these generic aliases should be allowed to migrate to different physical servers, transparently). I found out that you can have multiple PTR recordson
one IP address, which is completely legal in DNS, but not usually considered good practice (or so I thought). Of course, this secondPTR
record caused some things to fail in a non-deterministic way, since lookups on the IP address gave the PTR records in pseudo-randomorder,
causing code that only looked at the first answer to get inconsistent results. Grrr! Thanks, Google, for once again messing with standards, and forcing everyone else to bend to your will! Gilbert On 2020-04-18 3:14 p.m., Hartmut W Sager wrote: [... deleted ...]-- Gilbert E. Detillieux E-mail: gedetil@cs.umanitoba.ca Dept. of Computer Science Web: http://www.cs.umanitoba.ca/~gedetil/ University of Manitoba Phone: (204)474-8161 Winnipeg MB CANADA R3T 2N2 Fax: (204)474-7609
On 2020-04-20 11:10 a.m., Hartmut W Sager wrote:
Quoting from the "solution":
It is rare, but it is possible that the server will use a different
certificate on different ports, so switching between 465, 587 and 25 might yield better results. Again, the best source for the settings is your email provider.
In our case, the exact same certificate is used, regardless of which port the connection comes in on. I suspect that would be true for just about anyone, except for some weird cloud hosting providers, maybe...
I tested both 465 SSL and 587 TLS right after encountering the solution, and they both work, though I am under the impression that Gmail favours TLS (whereas I've hitherto always been using SSL). Any thoughts on that?
I don't think it makes any difference, really. (YMMV, depending on server software used.)
Note that here the distinction in terminology between SSL and TLS is simply that the "SSL" port negotiates the encryption right on open, rather than after the client issuing a STARTTLS command, which is the case with the "TLS" port.
This is not referring to protocol versions. These days, all actual SSL protocol versions are obsolete, and should not be used. Even older TLS versions 1.0 and 1.1 should now be avoided. This is configured separately, and should be independent of the port used to connect.
Gilbert
On 2020-04-20 Hartmut W Sager wrote:
I tested both 465 SSL and 587 TLS right after encountering the solution, and they both work, though I am under the impression that Gmail favours TLS (whereas I've hitherto always been using SSL). Any thoughts on that?
I've *always* used STARTTLS on 587 in all email setups, and I've never had a problem. It was my understanding that always-immediate-SSL like we use on the http-web was not really the way it evolved on the email side. When it comes to daemons that have to deal with the real world, I prefer to choose most prevalent paradigms, then your problems/bugs will likely have already been solved by others.
YMMV
-
Gilbert E. Detillieux -
Gilbert E. Detilllieux
-
Hartmut W Sager -
Trevor Cordes