On Jul 12, 2018, at 5:12 PM, Lyndon Nerenberg <lyndon(_at_)orthanc(_dot_)ca>
wrote:
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 privacy reasons).
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 played out.
--lyndon
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp