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
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
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"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
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp