From stuart at bmsi.com Wed Feb 1 19:18:37 2012 From: stuart at bmsi.com (Stuart D Gathman) Date: Wed, 01 Feb 2012 14:18:37 -0500 Subject: [RFCI-Discuss] Rejecting invalid (forged) DSNs. Message-ID: <4F29900D.5000803@bmsi.com> I have in place a system to accept null sender only for email actually sent by the MTAs for a domain. This is done by "signing" the MAIL FROM. The rejection message is: 550-5.7.1 I did not send you that message. Please consider implementing SPF 550-5.7.1 (http://openspf.net) to avoid bouncing mail to spoofed senders. 550 5.7.1 Thank you. This rejection is not done until the DATA command, so Call Back Verification systems that use null sender work ok. Does this policy warrant a listing in the DSN zone? Someone could try to send a DSN without using an actual envelope sender, or might try to use an expired sender, and conclude that we don't accept DSNs. Even worse, there are certain domains which reject MAIL FROM containing (some undocumented list of) characters they don't like in the localpart (sometimes '+', sometimes others), despite such characters being explicitly allowed in relevant RFCs since 821 and 2821. As a result, we cannot accept DSNs from such domains. You don't have a zone for rejecting email based on undocumented revisions to localpart syntax, so they could list me for not accepting their DSN, but I can't list them! (There is also the less serious offense of case folding localpart when sending DSNs - and expecting it to be somehow delivered. That I can work around.) From dredd at megacity.org Wed Feb 1 20:06:10 2012 From: dredd at megacity.org (Derek J. Balling) Date: Wed, 1 Feb 2012 15:06:10 -0500 Subject: [RFCI-Discuss] Rejecting invalid (forged) DSNs. In-Reply-To: <4F29900D.5000803@bmsi.com> References: <4F29900D.5000803@bmsi.com> Message-ID: On Feb 1, 2012, at 2:18 PM, Stuart D Gathman wrote: > I have in place a system to accept null sender only for email actually sent by the MTAs for a domain. This is done by "signing" the MAIL FROM. The rejection message is: > > 550-5.7.1 I did not send you that message. Please consider implementing SPF > 550-5.7.1 (http://openspf.net) to avoid bouncing mail to spoofed senders. > 550 5.7.1 Thank you. > > This rejection is not done until the DATA command, so Call Back Verification systems that use null sender work ok. Does this policy warrant a listing in the DSN zone? Someone could try to send a DSN without using an actual envelope sender, or might try to use an expired sender, and conclude that we don't accept DSNs. The problem is that MTA-originated DSNs aren't the only messages that exist. MUA-originated DSNs exist as well ("Read-receipts" for example) and those will go to the contents of the From: header, because that's all that the MUA has access to, and they (by spec anyway) should originate from the null-envelope. So you're blocking "illegitimate bounces" but you're also bouncing "legitimate read-receipts and other such types of messages". > Even worse, there are certain domains which reject MAIL FROM containing (some undocumented list of) characters they don't like in the localpart (sometimes '+', sometimes others), despite such characters being explicitly allowed in relevant RFCs since 821 and 2821. As a result, we cannot accept DSNs from such domains. You don't have a zone for rejecting email based on undocumented revisions to localpart syntax, so they could list me for not accepting their DSN, but I can't list them! All of our zones are basically "user-requested" zones. If you could get enough user support for such a zone to justify the management-overhead investment in creating one, we'd do it. But I don't see a huge outpouring of support for it, to be honest. It's such an "edge-case" condition these days that I'm not sure enough people care any more. (The same could be said for a lot of RFCs, even some of the ones we enforce today, but inertia is easy to maintain). Cheers, D