On Tue, Jan 20, 2009 at 9:25 AM, Michael ODonnell
<michael.odonn...@comcast.net> wrote:
> That error message about the Certificate on the line
> just before it was apparently just intended to confuse me.
My guess: Many (most?) MTAs which are doing TLS are using
self-signed certificates. So you'll get SMTP TLS trust errors by
default in many MTAs. (TLS is used just to encrypt the pipe to
protect the user credentials, not to authenticate the host to the
client, so a CA PKI isn't needed.)
> This means it's going to be a PITA to keep my Postfix
> config files up to date such that they stay in sync with that
> externally visible hostname ...
I'm no expert on Postfix, but from the logs, it appears Comcast is
rejecting your SMTP reverse-path (MAIL FROM), not your hostname
(HELO). (Windows mail clients almost never provide a valid HELO, so I
would be amazed if Comcast would require that.) Configure your MTA to
rewrite the reverse-path to be a valid address -- your email address
would be appropriate.
For example, with Sendmail, I just put the following in my
/etc/mail/genericstable:
bscott dragonh...@gmail.com
I presume Postfix has a similar capability. Exim may as well. Anyone?
You *really* should have a valid SMTP reverse-path anyway. Without
it, most hosts will reject your mail, and you also won't be able to
get non-immediate DSNs (Delivery Status Notifications).
> In the past the ComCast SMTP server didn't
> care how my clients ID's themselves but that's apparently
> tightened up when using this "submission" protocol.
I'm kind of surprised. Validating MAIL FROM has been a best
practice, and a very common practice, for longer than a decade. I
don't think Comcast has ever let me relay mail through their systems
with a bogus SMTP reverse-path. Are you sure this isn't something
that changed when you changed MTAs?
-- Ben
_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
