On Jan 31, 2008, at 1:06 PM, MH Michael Hammer (5304) wrote:
On Behalf Of Douglas Otis
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.
The confusion is in respect to Jim's definition for complaint
signatures. Jim excluded signatures not on-behalf-of the From header
from fulfilling compliance requirements establish by "strict". A
resulting lack of compliance thus could easily occur when an
authenticated entity's email-address is found within the Sender
header, and the message also happens to contain a From email-address
within the same domain, for example. Except for g= restricted keys, a
signatures i= parameter should not play a role in SSP compliance.
To satisfy Jim's current definition, either an ambiguous signature
(one not associated with a specific local-part) must be used, or the
local-part information must be falsified (misrepresents which identity
had been authenticated).
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).
Yes, DKIM can be used at the MUA and this is currently available. : )
The question would be does DKIM/SSP improve anti-phishing
protections. Is it safe to assume "on behalf of" within a virtualized
From header displayed by Windows MUAs catches the recipient's
attention first? There will also be those fooled when the virtual
From header indicates an unchecked entity as a result of the Sender
email-address being introduced by MUAs as being part of the From.
As a result, SSP might need to be checked against the Sender as well.
This should only cause added overhead and no other problem when the
signature's domain and the key's g= and t= parameters are used to
establish compliance.
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>
Agreed. Should this check be optional or recommended?
Would benefits justify the check?
Should the DKIM WG wait to see how many recipients are deceived by the
use of Sender?
SSP could add scope parameters to specify policies per header. The
value of a scope parameter becomes more apparent when TPA-SSP is
used. Perhaps authorization needs to be limited to the Sender header
when authorizing third-party mail-lists for example.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html