ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Issue: Deployment Guide Section 6.1/6.5 (ADSP/Forwader) conflict

2009-10-19 12:56:41
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

<Prev in Thread] Current Thread [Next in Thread>