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