The description of the protocol is fine. The dicta, less so. Setion 3.2 says:
If an MSA is not able to determine a return path to the submitting user, from a valid MAIL FROM, a valid source IP address, or based on authenticated identity, then the MSA SHOULD immediately reject the message. A message can be immediately rejected by returning a 550 code to the MAIL command. I think I understand the motivation, but that just seems wrong. I have lots of web scripts that submit mail using various bounce addresses, and there's no way to tell whose script it was without looking at the web logs. My MUAs put a variety of bounce addresses on the mail they send, some in domains local to the host with the submission server, some not. So what? Suggest deleting this pp and fixing the first sentence two pp down that refers to it. The NOTE: at the end of the section suffers from our endemic bad UI advice syndrome: To properly handle delayed bounces, the client MUA needs to maintain a queue of messages it has submitted, and match bounces to them. Again, that just seems wrong. Humans can and do look at bounces and do whatever they do with no MUA help. Suggest deleting the sentence. Section 3.3, third pp says: IP address restrictions are very widely implemented, but do not allow for travelers and similar situations, and can be easily spoofed unless all transport paths between the MUA and MSA are trustworthy. Spoofing the IP on a TCP session is very difficult, and if an attacker can do that, you've got worse problems than faked mail. The following paragraph mentions IPsec, the pp after that pop-before-smtp. Speaking as the inventor of pop-before-smtp, I think it's time to kill that dinosaur. I'd suggest replacing all three PP with something like this: IP address restrictions are widely used, both fixed IP ranges of known networks, and IP addresses recently validated for use by other protocols such as POP [POP3]. Secure IP [IPSEC] and other encrypted and authenticated tunneling techniques can be used to provide protection against eavesdropping and traffic analysis. Saurian note: I've also done IMAP-before-SMTP. Please don't document it. Section 6,1 refers to "submission rights." They're not defined anywhere. What are they? The phrase appears in RFCs 2476 and 4409 but not in any other RFC as far as I can tell. Section 6.4 describes special case handling of mail addressed to postmaster. Does anyone actually do that? If not, perhaps move it to a deprecated appendix. The NOTE: in section 8 appears to contradict the last paragraph in 4.2. Is it OK to expand single-component domains or not? Section 8.7 makes resolving CNAMES optional. I thought it was still officially mandatory. R's, John _______________________________________________ yam mailing list [email protected] https://www.ietf.org/mailman/listinfo/yam
