ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: Role of Sender header as signing domain

2006-11-30 05:37:04
On Thursday 30 November 2006 05:55, Charles Lindsey wrote:

Ah! I think I see now what Scott and Eliot are getting at. Suppose we have:
     From: joe(_at_)foo(_dot_)com
     Sender: joe(_at_)bar(_dot_)com
with good signature by bar.com

The verifier informs the recipient that the message was signed by bar.com,
and is confused because he sees no header mentioning bar.com. Or it
reports a failed signature by bar.com, and the user is even more confused.
I.e., he is supposing that the user is merely informed of what signatures
are present and it is left to him to inspect the displayed headers to see
whether he needs to be alarmed.

Not quite.  What I want to be able to do with SSP has nothing to do with user 
interface.

In your example, let's say that foo.com is a heavily phished domain that has 
published a signing complete SSP.  In this case I have received a message 
that is outside the criteria of their declared SSP.  They have published such 
an SSP knowing that it will cause some legitimate use classes of mail to fail 
(e.g. mail sent through mailing lists that break signatures), but that the 
benifits of combatting exact domain forgery are worth the cost (this has been 
extensively debated on the list already and the group is divided on this - I 
don't propose to redo this debate).

What I want to be able to do is retrieve the SSP based on the 2822.From, 
determine that foo.com has published signing complete, look for and fail to 
find a signature by foo.com, and then after the final "." in DATA reply 550.  
Rejecting the message then keeps the end user and MUA considerations out of 
it entirely without negatively impacting the reliabliity of the overall 
e-mail infrastructure.

If a good signature from bar.com can over-ride this, it won't be long before 
all the phishers add it.  If I follow this to it's logical conclusion, we end 
up using the MS PRA algorithm and get:

      From: joe(_at_)foo(_dot_)com
      Resent-Sender: joe(_at_)bar(_dot_)com

With good signature by bar.com over-riding whatever foo.com has to say.  
Whatever limited value SSP could have had in combatting phishing without 
having to upgrade every MUA in the world is pretty well negated.

Scott K
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html