> 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? I'm a little unclear on why you think the requirement to check the validity of the MAIL FROM would be a problem here. Surely the bounce addresses you're using are at least superficially valid? THat's all the text is saying needs to be checked; I don't see it as requiring access restriction or address locality or anyting along those lines. > Suggest deleting this pp and fixing the first sentence two pp down > that refers to it. I don't think this is a major point, but OTOH I fail to see any harm in the text that's there now. > 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. Strongly disagree. Yes, people handle bounce mnaully all the time, and they often handling them badly. MUA correlation of bounces with original messages addresses that and IMO we should encourage it, which is what this section does. > 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 difficulty of IP address spoofing varies tremendously with network geometry and location. The nature of the address you're attempting to spoof can also be a factor. Sitting here in my office connected to the company network only, I would have a very difficult time indeed spoofing an IP to your email server. But things would be very different if I were able to access your LAN and able to do ARP spoofing. Or if I could splice in to your DSL connection. Here the key difference is whether or not I'm able to access the network connection or not. In other words, it boils down to whether or not the path is trustworthy, which is exactly the point the document makes. I see no problem with the present text and I think it should be retained. > 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. Question: Aside from the VPN case, how much IPsec usage for securing SMTP have you seen? I don't think I can come up with even one example. So, while I don't really object to changing this text to deemphazie the POP-before-SMTP hack, I don't see how retaining the idea that using IPSec for this is helpful. And i think removing the text about spoofing would be a mistake. > Saurian note: I've also done IMAP-before-SMTP. Please don't document it. Agreed. > 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. Yes, the concept should be described. > 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. We certainly support doing it; whether or not anyone actually uses this capability is anyone's guess. I don't recall ever seeing an access control setup that allowed sending to postmaster only when in an unauthenticted state. I certainly wouldn't object to deprecacing this. > The NOTE: in section 8 appears to contradict the last paragraph in 4.2. > Is it OK to expand single-component domains or not? The restriction in 4.2 is talking about multi-compponent but not fully qualified domains, so I don't see the conflict. I will say that the advice about allowing foo.sales or bar.us or whatever is sound but likely to fall on deaf ears. > Section 8.7 makes resolving CNAMES optional. I thought it was still > officially mandatory. Actually it's a fairly new requirement, but yes, it is now a requirement, so this needs to be fixed. _______________________________________________ yam mailing list [email protected] https://www.ietf.org/mailman/listinfo/yam
