On 5/25/10 5:01 AM, Alessandro Vesely wrote: >> I think that Murray was suggesting that in addition to rejecting all >> > mail from domain A it would be polite to also warn anyone from >> > domain A who subscribes to the list that their mail would be >> > rejected (which seems good UX design to me). >> > That warning is an/alternative/ to refusing signups. The BCP > distinguishes between participating and non-participating MLMs, and > that warning belongs to the former kind. I'd expect a participating > MLM has also fixed the double-footer problem, while most lists have no > problems with double subject-tags. Hence, the warning may merely > recall that posts from the discardable address will be rejected unless > they include the correct footer, and the subject-tag appears exactly > once, the latter especially for new posts. (Notice that such practice > is may also help to avoid light-minded posts.) > > We cannot suggest anything to DKIM-unaware MLMs. Hence, the "refuse > signups" option, that would apply in this case, has to be put through > by subscribers themselves. > It should be possible for sending domains to detect mailing-list conversations. When desired, they can then immediately publish third-party authorization labels to allow ADSP exceptions. The exception approach retains their ability to quickly mitigate any reported abuse. >>> >> Since ADSP causes problems for innocent bystanders, I think it's >>> >> reasonable to decline A's mail in the first place. This is doubly >>> >> true since the ADSP RFC rather specifically says that you shouldn't >>> >> mark a domain discardable if its users send mail to lists. >>> Disagree. This suggests ADSP makes a deliver-ability distinction between "discardable" and "all". It does not. Appendix B makes a general statement about what might invalidate DKIM signatures, without mention of "discardable". Appendix B.3 warns "discardable" may cause their email to be discarded (dropped), and makes no specific mention of mailing lists. Appendix B.5 refers to _both_ "all" and "discardable" as causing significant breakage for messages sent through paths lacking Author Domain Signatures. >> > >> > It causes no problems at all to innocent bystanders in that case - the >> > recipient at domain B is a willing participant who has chosen both >> > to pay attention to ADSP and to respond to it by rejecting, rather than >> > discarding, mails labeled "discardable". >> ADSP "all" might be rejected, where ADSP "discardable" might be discarded. Neither ensures delivery without an Author Domain Signature.
A reasonable use for "discardable" would be for domains that don't send email. DSN of rejected mail should be used to report abuse and to escalate take-downs of illegal activity. It is amazing ISPs feel safe in using reverse DNS PTR records to qualify their outbound servers, but then ignore clear evidence of wrong doing that should lead to a similar consequences for ignoring reported ADSP assertions that clearly indicate their lack of authorization. > That user will probably contact postmas...@b and ask for the relevant > list to be whitelisted. If a list's operators seek such explicit > whitelisting at their subscribers' MXes, then they might want to > leverage ADSP that way. > Why should some user be trusted? Only the Author Domain should be allowed to make these exceptions. Ideally this should be done with a single transaction mechanism. SPF will not serve this role. Often SPF must authorize servers carrying messages for thousands of domains. By not knowing with certainty which email headers or parameters should be in compliance, and by not having border MTA IP addresses captured by Authentication-Results, SPF is far less practical at mitigating abuse and potentially dangerous messages. On the other hand, ADSP in conjunction with a third-party authorization mechanism provides a clear and certain indication of non-complaint email, which should offer far greater protection with less overhead. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
