On 14 Jan 2019, at 20:43, Grant Taylor wrote:
On 1/14/19 8:29 PM, John Levine wrote:
When the ABNF about extended-domain was written with the comment
about info derived from the TCP connection, the TCP connection was
synonymous with the transport.
I don't accept that at face value.
IANA has UUCP defined as a VIA link type. I highly doubt that it was
added /after/ the TCP in 5321 (which you state is functionally a copy
of 2821). Or even if it was posthumously added, I would expect there
to be a reference to an RFC for it. Seeing as how there isn't a
reference, I'm going to believe that UUCP link types were around
/before the TCP link type was defined in 5321 ~> 2821. As such, I'm
going to assert that UUCP link types were around (and still in use)
when the ABNF about extended-domain was written. As such, I don't
agree that TCP connections were synonymous with the transport.
Now the transport is TCP plus STARTTLS in various versions plus SNI,
I don't agree. SMTP transport may be predominantly TCP (UUCP is still
out there, as are some other more esoteric things).
Very simply the fact that we have on going efforts to add / require
STARTTLS (MTA-STS and DANE-TLS come to mind) or bare TLS (SMTPS in one
form or another) tells me that the current defacto transport does not
/include/ STARTTLS.
none of which was contemplated back in 2001.
I find that highly suspect. I think that someone working on SMTP in
2001 would have had some knowledge of ongoing STARTTLS work. I'll
concede that it was not enough or stable enough knowledge to influence
2821.
Yes, we knew about STARTTLS, but we didn't understand the
impact/consequences of SNI back then. The DRUMS WG charter also
prevented the addition of new features outside specifically identified
exceptions (e.g., IPv6). Without that restriction, I doubt we could have
completed RFC 2821 & RFC 2822.
I think it would be very useful to write an RFC that changes the
registry for fields in the received header to an "expert-review
registry", and also adds an SNI field. Then it would subsequently be
easy to add new received fields. The overuse of comments in Received
headers suggests the strict registry classification for Received headers
was a design error, just as the overuse of X- headers in email led to
publication of RFC 3864 which loosened the rules and RFC 6648 which
discouraged the naming wart.
- Chris
I think it's reasonable to use extended-domain for info about the
underlying transport, even if the details are not strictly about TCP.
I'm going to disagree with you. However that disagreement is more
opinion and interpretation, which we obviously differ on.
After all, the rDNS name in the FROM extended-domain comes from a DNS
PTR lookup of the IP address which uses IP over UDP so it's never
been strictly about TCP.
The "information derived by the server from (or about) the TCP
connection" is independent of how the server derives said information.
It is possible that the server used TCP for DNS, or NIS(+) via TCP, or
via hosts file entries. The method used to derive the information is
immaterial of what the derived information is. The RFC is concerned
with what the information is, NOT how it was derived.
--
Grant. . . .
unix || die
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
