Thank you, that was extremely useful information and explanation.
I made a new gmail test account and it worked fine out of gate.
Further research turned up that with gmail you can configure out-bound email
to go through a different mail server. The original test account I used had
been configured that way to testing something with Reply-To and I wasn't aware
of it. Sigh.
I'm doing the port 587 config next.
Thanks all for the help.
-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org]
On Behalf Of Bill Cole
Sent: Friday, November 13, 2015 18:23
To: postfix-users@postfix.org
Cc: postfix-users@postfix.org
Subject: Re: new deployment fails to receive email from "just" gmail
successfully
On 13 Nov 2015, at 13:44, Chris Boylan wrote:
> There is no port number in the log messages you reference. How do I
> interpret
> what's there as a port 587 connection rather than a port 25
> connection?
This log line:
> Nov 12 20:00:41 mail0 postfix/smtpd[24249]: send attr ident =
> submission:209.85.160.172
Viktor's deeper understanding of Postfix debug lines confirms what I
suspected but was unsure of, that 'submission' indicates that the
connection is on the port used for message submission: 587. Note that
you can avoid such uncertainty by overriding the syslog_name parameter
for the submission service in master.cf, so that the submission and
smtpd services tag their log lines differently.
Your 'postconf -M' output indicates that you have no config overrides
for your submission service, so it will behave identically to your port
25 smtp service. That is always wrong. For some unknown reason Google is
trying to talk to you on the submission port and is dropping the
connection AFTER establishing a TLS session and AFTER saying EHLO inside
that session and AFTER you've responded to that EHLO. Were this a TLS
problem, the failure would almost certainly NOT include any exchange of
traffic inside the encrypted session.
If you were running a proper submission service on port 587, it would
offer AUTH in its EHLO reply inside a TLS session, because a compliant
MSA MUST (https://tools.ietf.org/html/rfc6409#section-4.3) require some
form of authentication, normally the SMTP AUTH extension. If Google is
expecting to see SMTP AUTH advertised in the EHLO reply and not seeing
it (as they might, if you were a paying customer using the feature
described at
https://support.google.com/a/answer/2368131?hl=en&ref_topic=2921034 )
then a hard drop of the connection like that is not unreasonable.
The critical next step is to figure out WHY Google is using port 587
instead of port 25. Since there are mandatory differences between SMTP
and message submission that require senders to behave differently, it is
reasonable to assume that when they decide for who-knows-what reason to
use port 587, they also act differently than they would if they were
using SMTP on port 25.
