-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Douglas Otis
Sent: Thursday, January 31, 2008 1:40 PM
To: Charles Lindsey
Cc: DKIM
Subject: Re: [ietf-dkim] Re: ISSUE 1525 -- Restriction to
posting by firstAuthor breaks email semantics
Disagree. The concept of 1st Party signature would be with
respect to the From email-address. In other words, SSP
assurance is limited to policy statements regarding
email-addresses found within the From domain. When a
signature is signed on-behalf-of the Sender header
(i=) using a key that could encompass that of the From
email-address (g= t=) in question, the signature alone
verifies the signing domain's policy. When the From
email-addresses do not reference SSP records, and the
signature on-behalf-of the Sender does not encompass the From
address, this signature represents that of a Third-Party.
This is where I start to get concerned. I happen to agree with you Doug.
It appears that other respected participants disagree with you on
whether SSP is limited to policy statements regarding email-addresses
found within the From domain - or at least they don't seem to want to
allow strong policy statements.
While this check can be made, checking email-addresses found
in different headers will likely have little benefit, but that
might depend upon the MUA/OS being used. Outlook will show
the From as the "on behalf of" following the Sender's address.
The virtual From header is to support the PRA validations.
This might open the door for Sender header spoofing, but this
will also increase the overhead involved with checking SSP.
Consider that most email is not signed.
Do you only see DKIM being used at MUA/OS? I actually see more value at
the MTA (preferably the border).
So for sure we could build that into SSP if we wanted to.
No need when "all" or "strict" is complaint where just the
signature's domain and key qualify a valid signature.
Only if someone bothers to check <G>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html