On 01/14/2019 03:48 PM, Daniel Kahn Gillmor wrote:
I'm sorry to spoil it for everyone that the word is "The" :P
Agreed.
While the Domain part of that ABNF doesn't describe how it's supposed to be derived from "Information derived by server from TCP connection" for the BY clause specifically, i think using it for SNI is entirely reasonable.
That seems like a layering violation to me. I would think that the information about the TCP connection would consist of the IPs and ports. It seems to me like anything TLS related would be at a higher layer than "the TCP connection".
I would think that any information about STARTTLS and associated SNI would be excluded from "information derived by server from TCP connection (source IP, destination IP, source port, destination port)". Thus I think SNI information would need to be indicated elsewhere.
I feel like the Domain of the TCP-info of the Extended-Domain of the By-domain could / would / should be used to identify which IP address of a multi-homed ""host (I use that term loosely), that has many IP addresses that are each associated with different FQDNs.
Example 1:
by multi-homed-host.example.net (client-mx-1.client-1.example
[192.0.2.1])
Example 2:
by multi-homed-host.example.net (client-mx-2.client-2.example
[198.51.100.2])
Example 3:by multi-homed-host.example.net (client-mx-3.client-3.example [203.0.113.3])
I feel like the Domain of the TCP-info of the Extended-Domain of the By-domain is for information to identify the TCP/IP endpoint of the SMTP connection.
Many implementations don't even use the TCP-info variant for the BY
clause. for example, from a copy of a message i received on this thread:
Received: from mail.ietf.org (mail.ietf.org [4.31.198.44])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by foo.example.com (Postfix) with ESMTPS
for <[email protected]>; Mon, 14 Jan 2019 15:22:20 -0500 (EST)
the BY clause here just uses Extended-Domain as Domain (no TCP-info at
all), and "(Postfix)" is just a Comment.
Agreed.
Hm, you'd need to read RFC 5322 to get to the definition of CFWS to know that's a comment, not just RFC 5321 :P
Yep.
I know that you're frustrated, but please be gentler with people who don't have as much in-depth knowledge of the RFCs as you do.
Agreed.I don't know about other people, but I've found that it works both ways, people that know less about a topic can ask questions that stump people that know more about said topic. I've worn both hats, many times.
Also keep in mind that some people (like myself) participate in this list / community to learn. Not everybody is trying to steer things and make decisions.
Finally, please do not presume that people don't read RFCs. I know that I've read many. I retain many, but certainly not all, aspects of the RFCs that I've read. I frequently need to go back and reference them. I know that I make mistakes more often than I'd like to know about. I like to extend the courtesy to people to make similar mistakes and afford them the same opportunity to correct them that I'd like them to afford to me.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
