ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Case for ADSP "dkim=except-mlist"

2009-10-16 19:52:57
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