[Top] [All Lists]

Re: [ietf-smtp] Adding a new value to the WITH protocol type subregistry

2018-07-12 19:13:26

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 
we lie and say SMTP or SMTPS when in reality all Received/X-Received headers 
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.


ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>