[Top] [All Lists]

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

2018-07-12 19:21:22
I would argue that the information is a lot more important than you think.. standards help.. (often the methods of authentication, or the way the email was processing through 'muddle-boxes' helps in trust factors and reputation...

But I for one agree, that allowing a more 'open' set of identifiers and mappings of what those are, aid in transparency, and should not be restricted to 'approved' identifiers (eg IETF approved) , but 'published' identifiers..

On 18-07-12 05:12 PM, Lyndon Nerenberg wrote:

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

"Catch the Magic of Linux..."
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at @linuxmagic
A Wizard IT Company - For More Info
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

ietf-smtp mailing list

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