On Jul 12, 2018, at 5:12 PM, Lyndon Nerenberg
That's because we have an L7 proxy in the way; it accepts the (TLS)
connection, does some preliminary validation (greylisting, RBL checks, etc)
before passing the connection through to our internal MTAs. It doesn't
insert its own Received header, and the internal proxy->MTA hop isn't
encrypted. The same thing happens on the Submission path, where our
internal encryption proxies don't identify themselves via Received (for
Sorry, I left out some context ...
Our internal MTAs report no TLS because the inside link is not encrypted.
This means incoming TLS-encrypted messages don't show that in Received.
If we were to encrypt the internal hop from the proxy to the MTA, *all* the
messages would show as TLS-encrypted, even when they might not be.
The alternative is modifying the proxy code to insert its own Received
header. That would add a lot of overhead to what is otherwise a very
lightweight front end defence on our SMTP servers. The value of having this
information in Received is negligible, versus having it in the logs, which is
where we go to anyway whenever anyone askes how the transaction actually
Or better still, use XCLIENT. This is it's main use-case.
ietf-smtp mailing list