Stephen Farrell wrote:
> Hi Jim,
>
> Jim Fenton wrote:
>   
>> SSP does require one additional semantic over that of DKIM-base:  in
>> addition to taking responsibility for the message, those domains that
>> publish SSP records other than "unknown" must assert that, when the
>> address in the From: header field is really their domain, that this is
>> actually true.  
>>     
>
> That statement isn't very clear to me.
>
> Do you mean: When a domain publishes an SSP != unknown, then it
> states that it does not emit messages where the rfc2822.from
> domain is outside its own domain?
>
> If so:
>
> - "emit" and "outside" would need defining
> - should that be "messages" or "signed messages"
>
> If not, I'm confused.
>   

The answer is "no" so let me try again.

Suppose example.com publishes SSP "all".  It signs a message with
resulting header fields:

From: Jim Fenton <[EMAIL PROTECTED]>
DKIM-Signature: [EMAIL PROTECTED];...

No additional assertion regarding the From: address is made in this
case.  example.com is just taking responsibility for the message; it
might be doing so because it operates a mailing list or because it
allows subscribers to mail articles from "The Example Times" to their
friends.

Now suppose it signs a message with resulting header fields:

From: John Doe <[EMAIL PROTECTED]>
DKIM-Signature: [EMAIL PROTECTED];...

In this case, the signer must make an assertion that the message indeed
originates from their domain, because a verifier using SSP depends on
the ability to correlate the From: address to the signing address.

We are depending on an assertion regarding the From: address when it
should be easy to provide:  when that address is the same as that of the
signer, and not when it's difficult:  when that address is something else.

Again, I am not considering the issue of whether the address comparison
includes the local-part, because that's being covered under issue #1399.

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

Reply via email to