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
