----- Original Message -----
From: "Stephen Farrell" <[EMAIL PROTECTED]>
To: "Frank Ellermann" <[EMAIL PROTECTED]>
Cc: <[email protected]>
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 "[EMAIL PROTECTED]",
> > but not Resent-From "[EMAIL PROTECTED]" ?
> >
> > Can you use an SSP for "B" and 2822-From "[EMAIL PROTECTED]", if the
> > mail was actually Resent-From "[EMAIL PROTECTED]" ?
>
> 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
