On Jan 30, 2008, at 3:18 AM, Charles Lindsey wrote:
On Tue, 29 Jan 2008 17:52:57 -0000, Jeff Macdonald <jmacdonald(_at_)e-dialog(_dot_)com
> wrote:
On Wed, Jan 16, 2008 at 09:46:26AM -0800, Dave Crocker wrote:
<snip>
In any event, "on behalf of" is key wording that permits more
flexibility than you seem to be acknowledging. Note, for example,
that the agent specified in the Sender field is acting "on behalf
of" the author.
Is that agent authorized to work "on behalf of" the author?
That is what the person who actually sent it is claiming.
A well-organized 1st party signer will not sign anything that did
not originate within is domain, and containing a From/Sender within
bis domain.
So if the Sender is in his domain, then he ought to establish that
is where it came from, and then include that header within his
signature.
But, in that case, he really needs some mechanisn to be able to say,
in his SSP, that "we check and sign Sender headers where present".
Ditto for Resent-From and Resent-Sender.
BTW, would it be useful for a signature to contain some feature to
indicate whether it claimed to be a 1st/2nd/3rd/whatever-party
signature?
SSP should be applied only when there are _no_ valid signatures
encompassing the identities in question by the domain in question.
When the key used to sign the message is not restricted from
encompassing the From email-address in question, there is _no_ reason
to question whether this identity is complaint with the signing
domain's policy. The domain signed it, so therefore it MUST be
compliant!
There is no need to check SSP in these cases. Doing so represents
wasted overhead and adds undue complexity. Why create a list of
semantic corner cases for anyone claiming to use RFC 4871 to sign all
messages? Why should SSP change how RFC 4871 is to be used? Why
should SSP require a domain to add ambiguous or falsified signatures
only to satisfy SSP convoluted requirements for what constitutes a
compliant signature?
The easy solution would be a statement that by signing the message,
all headers containing identities within the scope of the key and
within the signature's hash will be considered complaint whenever
their signature is found to be valid.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html