<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#000000">Quoting from the "solution":<br> <br>> 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.<br> <br>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?</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#000000"> <br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#000000"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span style="font-family:verdana,sans-serif"><font size="2">Hartmut W Sager - Tel +1-204-339-8331<br></font></span><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 20 Apr 2020 at 10:47, Gilbert E. Detilllieux <<a href="mailto:gedetil@cs.umanitoba.ca">gedetil@cs.umanitoba.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Initially, it was just a guess, based on the reported error message. <br>
Then I started to suspect that was the problem.  (Knowing that the host <br>
names used in the config were in the SAN list, and that the canonical <br>
name wasn't.)  Then, one of our grad students found these forum posts...<br>
<br>
Issue: <a href="https://support.google.com/mail/thread/38789651?hl=en" rel="noreferrer" target="_blank">https://support.google.com/mail/thread/38789651?hl=en</a><br>
Recommended answer: <br>
<a href="https://support.google.com/mail/thread/38336515?msgid=39890656" rel="noreferrer" target="_blank">https://support.google.com/mail/thread/38336515?msgid=39890656</a><br>
<br>
... which confirmed my suspicions.  Adding the PTR record fixed the <br>
problem, and further confirmed my suspicions and what was claimed in the <br>
forum posts.<br>
<br>
Incidentally, cranking the sendmail LogLevel past 11 (and all the way up <br>
to 14) didn't shed any extra light.  All we saw was that connections <br>
from <a href="http://google.com" rel="noreferrer" target="_blank">google.com</a> servers would start TLS negotiations, and then just <br>
disconnect before issuing any SMTP commands.  I had to rely on users to <br>
send me error messages from their bounce messages to see what was <br>
failing on the client side, i.e. Google's side:<br>
<br>
TLS Negotiation failed, the certificate doesn't match the host.<br>
<br>
Not much to go on!<br>
<br>
Gilbert<br>
<br>
On 2020-04-20 10:03 a.m., Hartmut W Sager wrote:<br>
> How did you (and your work colleagues) come to realize that the RDNS <br>
> name is what Google cert is trying to match?<br>
> <br>
> Hartmut W Sager - Tel +1-204-339-8331<br>
> <br>
> <br>
> On Mon, 20 Apr 2020 at 09:20, Gilbert E. Detilllieux <br>
> <<a href="mailto:gedetil@cs.umanitoba.ca" target="_blank">gedetil@cs.umanitoba.ca</a> <mailto:<a href="mailto:gedetil@cs.umanitoba.ca" target="_blank">gedetil@cs.umanitoba.ca</a>>> wrote:<br>
> <br>
>     Yeah, we got bitten by this one at work last week (actually started<br>
>     noticing problems around Wednesday or Thursday of the previous week,<br>
>     but<br>
>     only resolved it last week).  We had some users within the department<br>
>     who wanted to manage their CS e-mail via Gmail, and had set up their<br>
>     Gmail to send out via our SMTP server, which had worked fine until<br>
>     Google unilaterally decided on this new restriction, which most likely<br>
>     violates several standards.<br>
> <br>
>     Since we control reverse DNS on our domain, I was able to fudge things<br>
>     up to get Google to accept our cert (a legitimate cert, issued by<br>
>     Globalsign, that has multiple generic aliases in the SAN list, but<br>
>     intentionally avoided the canonical host name, since these generic<br>
>     aliases should be allowed to migrate to different physical servers,<br>
>     transparently).  I found out that you can have multiple PTR records on<br>
>     one IP address, which is completely legal in DNS, but not usually<br>
>     considered good practice (or so I thought).  Of course, this second PTR<br>
>     record caused some things to fail in a non-deterministic way, since<br>
>     lookups on the IP address gave the PTR records in pseudo-random order,<br>
>     causing code that only looked at the first answer to get inconsistent<br>
>     results.  Grrr!<br>
> <br>
>     Thanks, Google, for once again messing with standards, and forcing<br>
>     everyone else to bend to your will!<br>
> <br>
>     Gilbert<br>
> <br>
>     On 2020-04-18 3:14 p.m., Hartmut W Sager wrote:<br>
>     [... deleted ...]<br>
<br>
-- <br>
Gilbert E. Detillieux        E-mail:  <<a href="mailto:gedetil@cs.umanitoba.ca" target="_blank">gedetil@cs.umanitoba.ca</a>><br>
Dept. of Computer Science    Web:     <a href="http://www.cs.umanitoba.ca/~gedetil/" rel="noreferrer" target="_blank">http://www.cs.umanitoba.ca/~gedetil/</a><br>
University of Manitoba       Phone:   (204)474-8161<br>
Winnipeg MB CANADA  R3T 2N2  Fax:     (204)474-7609<br>
</blockquote></div></div>