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