----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Wednesday, August 09, 2006 7:52 PM
Subject: Re: [ietf-dkim] Re: Requirements comment: Bigbank example
description
Frank,
Frank Ellermann wrote:
Tony Hansen wrote:
This has nothing to do with PRA and its support for
Resent-From and/or Resent-Sender.
If there is an SSP for "A", why apply it to Sender "a(_at_)A",
but not Resent-From "a(_at_)A" ?
Can you use an SSP for "B" and 2822-From "b(_at_)B", if the
mail was actually Resent-From "a(_at_)A" ?
Can I suggest making concrete proposals, aimed at moving
towards consensus, rather then asking open ended questions
that lead to lots of repetition and lots and lots of mail?
Really - it'll lead to less hassle for us all,
If this may help, and Michael can comment and clarify, an old pseudo-code
presented here (or in the old list) did include consideration for the
2822.Sender header:
$outsideheaders = "From, Sender";
$from = ; // 2822 From: address in msg
dkim_bindToOutsideHdrs () {
foreach ($hdr in $outsideheaders) {
if (dkim_bindToHdr ($hdr) == BIND) {
if ($hdr != "From") {
$policy = dkim_signerPolicy (domainpart ($from));
if ($policy == strict || $policy == nomail)
return FAIL;
else
return PASS;
} else
return PASS;
}
}
return NEUTRAL;
}
In layman terms (pending Michael's confirmation)
The SSP policy was ALWAYS done on the 2822.From domain
but ONLY when the DKIM-Signature d= tag was bound to
the 2822.Sender domain.
It was my contention that the SSP should ALWAYS be done against the
2822.From regardless of how DKIM-Signature domain was bounded.
It was from my analysis of Michael's initial pseudo-code that started my
efforts in producing the Policy vs. Verification Result tables and the
genesis of the more restrictive policy concepts.
Hope this provide some insight.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html