Steve Atkins wrote:
On Oct 16, 2009, at 6:33 AM, Michael Deutschmann wrote:
To review, "dkim=except-mlist" would mean:
..
(Incidentally, anyone have a better name for this policy?)
dkim=all.
dkim=all says that you sign all mail you send, and nothing more. The
difference between that and what you write above for a receiver is
nil, I think.
0.89+ IFF "nothing more" implies additional 3rd party signatures are
possible. In other words, there will be two or more, but the 1st
party signature is expected.
From: person(_at_)1ps(_dot_)com
Dkim-Signature: d=1ps.com ...
Dkim-Signature: d=3ps.com ...
Part of the problem is the lost of integrity and 3ps will strip the
1st party.
From: person(_at_)1ps(_dot_)com
Dkim-Signature: d=3ps.com ...
So the receiver seeing that 1ps has DKIM=ALL sees a violation and does
not know what to do.
Is 3ps.com a known trusted party? << ---- GOOD! Excellent!
Is 3ps.com an anonymous party? << ---- MAYBE BAD?
DKIM=ALL is exactly like the SPF = SOFTFAIL (?ALL rule)
"Something is wrong, but we don't know why. It could be bad
it might be a good partner. We don't know, so its probably
safer if you just record this, maybe score it and watch it.
If you have other proof that 3ps.com is doing something
bad or wrong, then you decide."
DKIM=DISCARDABLE is exactly like a SPF=FAIL (-ALL rule)
"This is not what we expected, I don't care what went wrong.
Its not ours. Please do us a favor and you a favor by getting
rid of it. I promise, I won't sue you."
The point of this discussion, now in its different thread forms, at
least from my POV, is whether 3ps.com should of preempted this problem
by seeing the 1ps.com DKIM=ALL and saying:
"Hmmm, you know, this is a can of worms. I think it is best
to filter this submission and not forward a 1st party
broken message. What is the risk assessment here?
break and forward? GOOD or BAD?
filter? GOOD or BAD?
hmmmm, I wonder if I should send a report to the domain
that it was probably hacked? If I don't get a feedback,
then we can remove its membership if this problem continues."
Who knows steve! :)
==
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html