John, Thanks for the prompt response. Comments inline @ DLB> .
Thanks, --David > -----Original Message----- > From: John R Levine [mailto:[email protected]] > Sent: Thursday, July 17, 2014 6:22 PM > To: Black, David > Cc: [email protected]; General Area Review Team \([email protected]\); apps- > [email protected] > Subject: Re: [taugh.com-standards] Gen-ART and OPS-Dir review of draft-ietf- > appsawg-nullmx-05 > > > Something is wrong with this paragraph in the Security Considerations > section: > > > > In the unlikely event that a domain legitimately sends email but does > > not want to receive email, SMTP servers that reject mail from domains > > that advertise a NULL MX risk losing email from those domains. The > > normal way to send mail for which a sender wants no responses remains > > unchanged, by using an empty RFC5321.MailFrom address. > > > > Why is that treated as a security consideration? > > We think it's a security consideration because of the risk of lost mail. > It's not a new issue -- think of all the mail you get with return > addresses like [email protected]. > > > In light of the first paragraph in Section 4.3 stating that it's > > acceptable for SMTP clients to not send email to domains that publish > > NULL MX records, this text ought to be recommending that such a domain > > (legitimately sends email but does not want to receive email) SHOULD NOT > > publish a NULL MX record and SHOULD provide an SMTP server that promptly > > rejects all email delivery attempt. > > Sorry, but I don't understand this at all. Either way, anyone who sends > mail to the domain gets the mail rejected. The only difference would be > that the error message might be different. DLB> If a NULL MX record is published, then the text in Section 4.3 invites mail servers to reject email sent by the domain that does not want to receive email. That's undesirable, hence "SHOULD NOT publish a NULL MX record." Next, not publishing a NULL MX record invites long email timeouts in the absence of SMTP service, hence "SHOULD provide an SMTP server that promptly rejects all email delivery attempts" to provide prompt delivery failure notification in the absence of a NULL MX record. DLB> I think this revised SHOULD NOT/SHOULD discussion should be in 4.3 where the text that causes this concern resides. > > Nits: > > > > Section 1 is missing from Table of Contents. > > blame xml2rfc > > > First paragraph in Section 4.1: > > "address is not deliverable" -> "the email is not deliverable" > > It's the address. The message might be sent to several addresses, and the > other ones work. I realize its jargon-y, but it's pretty well established > in the mail workd. DLB> Ok, if it's a well-established email term, that's fine. > The other editorial suggestions are fine, I'll address them either in > another version once last call is over. Tnx. > > Regards, > John Levine, [email protected], Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. DLB> I actually know exactly where Trumansburg is and I've been to Taughannock falls many times when I was much younger. It's a small world. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
