While you are right the RFC's say you should enclose dotted quad in some
places in the email transaction, when it comes to 'Received' lines,
there is a little more 'free for all'.
These so called 'trace' fields are covered in RFC5322 and RFC5321
"Received:" header fields of messages originating from other
environments may not conform exactly to this specification. However,
the most important use of Received: lines is for debugging mail
faults, and this debugging can be severely hampered by well-meaning
gateways that try to "fix" a Received: line. As another consequence
of trace header fields arising in non-SMTP environments, receiving
systems MUST NOT reject mail based on the format of a trace header
field and SHOULD be extremely robust in the light of unexpected
information or formats in those header fields.
As you can see, they could be generated, and should be left as is.
However, MTA's 'should' use standard formats when possible.
Trace information is specified in section..
4.4. Trace Information (RFC5321)
I think what you are looking for..
TCP-info = address-literal / ( Domain FWS address-literal )
; Information derived by server from TCP connection
; not client EHLO.
You notice that address-literal is (as you mentioned) described as:
address-literal = "[" ( IPv4-address-literal /
IPv6-address-literal /
General-address-literal ) "]"
; See Section 4.1.3
And this is further expanded to be..
"To bypass this barrier, a special literal
form of the address is allowed as an alternative to a domain name.
For IPv4 addresses, this form uses four small decimal integers
separated by dots and enclosed by brackets such as [123.255.37.2],
which indicates an (IPv4) Internet Address in sequence-of-octets
form."
However, that is meant to represent a case where normally you would
expect a domain name, and it isn't available. In this case, since the
information being received is NOT intended to reflect a domain name, eg
they want to display the IP Address retrieved from tcp, not the domain,
this is a different case.
So in this case, while you might be 'more correct' in your RFC
interpretation, you have to accept and deal with any form of Received
line.. and this field is a specific form of the literal, so does not
need the differentiation afforded by section 4.1.3
(IMHO)
Does that help?
On 18-04-18 02:40 PM, Erwin wrote:
Hi,
This may be old hat to some, but staring at the RFCs (specifically 2821)
the only conclusion I see is that Microsoft is (or at least
*.outlook.com <http://outlook.com> servers are) violating the format of
the Received headers here:
Received: from mta.email.thinkgeek.com <http://mta.email.thinkgeek.com>
(66.231.88.32) by SN1NAM04FT019.mail.protection.outlook.com
<http://SN1NAM04FT019.mail.protection.outlook.com> (10.152.88.152) with
Microsoft SMTP Server (version=TLS1_0,
cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.20.675.14 via
Frontend Transport; Mon, 16 Apr 2018 16:33:42 +0000
Should that IPv4 literal be enclosed with "[" and "]" tokens, either as
([a.b.c.d]) or (hostname [a.b.c.d])?
Thanks in advance,
Erwin
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
--
"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.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
