I agree with most of this. We need to trust software people and operators - in principle they are not going to do something the specification does not say and is very clear about it. We cane skeptical about it, but good engineering faith is all we have. IMO, ADSP "discardable" is very clear. ADSP "all" is not and as you implied, and I always thought was understood, it is good for warnings, Logging, Learning, AI, scoring, feed to reputations or other new classifications methods, what have you. We can build with all.
But overall, its all for nothing if we exempt remailers for ADSP considerations. We should leave it up to implementations about how they want to challenge DKIM=ALL domains that arrive into their network. What is ironic about all this DKIM forwarding issue is the same issue that SPF forwarding had. This was one of the marketing advantages of DKIM - that it didn't have a forwarding problem. Well, it does. -- Michael Thomas wrote: > I haven't seen the various lists proposals but two things: > > 1) what to do with ADSP discard is a legitimate discussion for list software > 2) what to do with ALL is NOT. A list that discards or otherwise rejects a > submission *solely* on ALL is BROKEN. Doubly so if the ALL message had > a legitimate signature on input to the list. > > My feeling is this: > > 1) Make DISCARD rejection a knob and see how it goes. > 2) For ALL or just plain old DKIM signatures, use that information as an > end receiver would to make a spam/ham decision, but otherwise pass > *everything* > through to the final recipient even if they're 100% sure they broke the > signature. (Forensics) > 3) Always resign the message if it's possible. > > Mike > > On 10/18/2009 08:06 PM, Daniel Black wrote: >> On Monday 19 October 2009 12:18:04 John Levine wrote: >>>> The point here, I suppose, is that forwarders that are meant to >>>> forward ... while forwarders that are meant to fan out to multiple >>>> recipients ... should get different advice. >>> This is the mailing list advice that I strongly suggest we NOT attempt >>> to provide at this point. >> strongly disagree. Filtering early is more likely to pickup signature >> breakage >> and protect the down stream recipient. Its more likely to reject back to the >> sender if they configured stuff wrong. >> >> Advice could be split between forwarders that break signature and those that >> done. Keep in mind the dkim goal of is message integrity not reputation >> (despite its usefulness here). >> >>> All these arguments about what to do with >>> DKIM and ADSP and mailing lists are based on pure speculation. >> Rejecting mail based on signature failure combined with dkim=all/discard is >> working quite well on the mail lists I manage. I don't do this on the final >> recipient domain though. >> >>> I know what my lists do (just out of curiosity, how many other people >>> in this argument host active lists? >> me - lists.cacert.org >> >>> ) and I know what works for me, but >>> there are a lot of other opinions and we won't know what works until >>> we have some actual experience. >> Though involvement with Sympa and Mailman devs, who for the most part are >> sick >> of request saying change this so I can fillter spam/forgeries, still want to >> provide unsubscribe links and bottoms of email and generally meet the user >> requested features. >> >> Responses based on shared experience has been: >> - Sympa Dev - Serge Aumont - DKIMfriendly switch >> http://mipassoc.org/pipermail/dkim- >> dev/attachments/20090930/e767bd81/attachment.html >> http://www.sympa.org/manual/dkim#summary_of_parameters >> >> - Mailman Dev - Barry Warsaw - mta problem >> http://mail.python.org/pipermail/mailman-developers/2009-October/020818.html >> >> - Mailman Dev -Stephen Turnbull - develop List Domain Signing Practices >> http://mail.python.org/pipermail/mailman-developers/2009-October/020814.html >> >> - Infrastructure Manger - Ian Eiloart - reject when signature breaks and ADSP >> says all/discardable >> http://mail.python.org/pipermail/mailman-developers/2009-October/020805.html >> >> There's plenty of experience. Just need to look a bit beyond this list. >> >> _______________________________________________ >> NOTE WELL: This list operates according to >> http://mipassoc.org/dkim/ietf-list-rules.html > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
