On Jul 12, 2018, at 3:07 PM, Brandon Long
<blong=40google(_dot_)com(_at_)dmarc(_dot_)ietf(_dot_)org> wrote:
I remember getting into an argument with someone who complained about it. In
general,
we lie and say SMTP or SMTPS when in reality all Received/X-Received headers
between
internal servers have used our own rpc mechanism.
Which goes to the other thing, if you make this that strict, people will just
drop it or lie. You're not
going to review every internal "gateway" protocol.
This is timely, in that I just dealt with a customer complaint at work
(Hushmail), where the recipient parsed the Received headers and noticed no
indication of TLS on the delivery step to our border incoming MTAs.
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).
Given the proliferation of proxies, content filters, and other muddle-boxes
(sic -- I will let that typo stand!), I wonder how useful the various
annotations in Received actually are these days. Most of the time, the only
useful information is the client's network address, and the timestamp.
Anything else I need comes from our internal logs. Client address + timestamp
+ internal opaque identifier seems to be all that's really needed these days
for Received to provide useful auditing.
--lyndon
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp