>-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] 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
