> Date: Thu, 24 Jan 2008 20:51:59 +0000> From: [EMAIL PROTECTED]> To:
> ietf-dkim@mipassoc.org> Subject: Re: [ietf-dkim] Re: the entire world will
> change their mail systems so that SSP sort of works> CC: [EMAIL PROTECTED]> >
> >I'm not misrepresenting other peoples arguments at all. If the only>
> >signature on the message is from a 3rd party and there is an> >opportunity
> to check for the assertion of the purported From domain> >that is not taken,
> that in fact is giving more weight ... to the> >signature of the third party
> ...> > Right. Let's look at the message you just sent, and imagine that the>
> list signed it with a mipassoc.org signature. Since I know that Dave> runs
> his lists well, I'm done. The "opportunity" to check something> else is
> irrelevant, as is the fact that the list would have broken> your signature.>
So you've picked an example where you don't need to bother with SSP at all
since you already have an existing trust relationship in place, and your
existing systems give you what you would consider to be a valid answer given
just DKIM and no policy or practices statements whatever.
If your answer is, that given this example you are not going to use SSP (and as
an engineer I would probably recommend not mucking with any cases where your
systems already do exactly what you want them to) that is fine. But given that,
how does this have any bearing on what people should be doing in cases where
they decide they do want to use SSP?
Let's modify the example a bit. Imagine that the message had been sent to you
rather than through the mipassoc.org mailing list, but through some entity you
knew nothing about, and that that entity had signed the message.
Does the draft need to explain all the cases or reasons why someone might not
bother to look up a policy at all?
Robert
_________________________________________________________________
Need to know the score, the latest news, or you need your Hotmail®-get your
"fix".
http://www.msnmobilefix.com/Default.aspx
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
