ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] A few SSP axioms

2006-08-01 20:40:41
There can be other policies but I require those two and am wondering why
there seems to be a tremendous pushback on this. 

You must have a very different model of SSP use from the rest of us.

Neither of these assertions are useful to a recipient, so there's no
point in publishing either for recipients to look up.  You really need
to provide some concrete scenarios that show how receivers will use
your policy info to manage their mail processing.

A. I only sign 3rd party

Scenario A1: message from you arrives with no signature, or with
someone else's signature.  What would a recipient do with this SSP
info?  How would it differ from what the recipient would do anyway?
It wouldn't.

Scenario A2: message from you arrives with your signature.  We now know
that your SSP is wrong, which is not interesting to anyone other than
you. Same question, how would a recipient's mail handling change with
this SSP info?

Scenario A3: message from someone else arrives with your signature.
Same question again, how would a recipient's mail handling change with
this SSP info?

B. I sign exclusively any other sigs make mine broken

This one's simple, we don't believe you.  

My wife gets all her mail relayed through an alumni account at
Cornell, and at some point Cornell will sign the mail they relay as it
passes through.  So we're going to accept lots of mail with Cornell
signatures, and if you insist that we not do so, all you will
accomplish is to persuade us that that you are being silly.  If a
message has your signature, it's your message.  If it also has a
hundred other signatures, it's still your message.

If you disagree, you really have to provide a concrete scenario where
an added signature turns a valid message into an invalid one, keeping
in mind that the existing message headers and the messge body did not
change at all, since the original signature is still good.

R's,
John




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