On Thursday, January 22, 2015 23:52:58 Franck Martin wrote: > ----- Original Message ----- > > > From: "Scott Kitterman" <skl...@kitterman.com> > > To: dmarc@ietf.org > > Sent: Thursday, January 22, 2015 8:41:39 PM > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > > nits, while I'm at it> > > On Thursday, January 22, 2015 22:04:59 Franck Martin wrote: > > > ----- Original Message ----- > > > > > > > From: "Scott Kitterman" <skl...@kitterman.com> > > > > To: dmarc@ietf.org > > > > Sent: Thursday, January 22, 2015 7:16:58 PM > > > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more > > > > tiny > > > > nits, while I'm at it> > > > > > > > > On Friday, January 23, 2015 03:03:28 John Levine wrote: > > > > > >RFC 7208 doesn't say the HELO result determines anything. It says > > > > > >IF > > > > > >(I > > > > > >say > > > > > > > > > > > >Avoiding a check that has been determined to be pointless is the > > > > > >only > > > > > >change in this area in RFC 7208. > > > > > > > > > > Indeed, and that turns out to be a lot more incompatible than was > > > > > appreciated at the time. > > > > > > > > I'm up to accepting that there's some ambiguity in the language, but I > > > > don't see any actual incompatibility assuming the ambiguity is > > > > resolved > > > > appropriately. > > > > > > > > If one changes "definitive policy result" to "definitive local policy > > > > result" or > > > > "definitive receiver policy result" then I think there's no ambiguity. > > > > > > > > I'm still a bit boggled that anyone is confused about this, but > > > > obviously > > > > they > > > > are. > > > > > > To try to explain the confusion... > > > > > > Well, DKIM is easy, DKIM is valid or is not (I'm excluding temp failures > > > due > > > to DNS etc..). The DKIM spec tells what the dkim result MUST be, and > > > then > > > the receiver do whatever with this result. > > > > > > With SPF, the spf=pass/fail result (as shown in the > > > authentication-result > > > header) is not depending on the sender policy as expressed in the SPF > > > record, but at whatever the receiver policy is... > > > > No. An SPF result is the deterministic. It's a combination of domain, > > identity, and result. This is always true and always consistent. > > > > Where the variation is in what the receiver decides to do. This is > > exactly > > the same as DKIM. I think the confusion is that people think SPF does > > more > > because of the name and because at one time (pre-RFC) it did. In hind > > sight, we'd have been much better off to keep the original name: Sender > > Permitted From. > > I know the receiver can do whatever of the result, and anyhow the receiver, > its rules. > > but I'm sorry I don't read anywhere in RFC7208 where f() is defined. > > spfresult in > (pass,fail,softfail,permfail,tmpfail,none,...)=f(check_host(HELO identity, > IP), check_host(MAIL FROM identity,IP)) > > it may be clear to you, but it is certainly not for me. Would you please > define f()? > > (note calling MAIL FROM a combination of RFC5321.mailfrom and > postmas...@rfc5321.helo does not help clarity either).
Probably not, but I don't know how else to have dealt with it. f() doesn't exist. SPF's check_host() has inputs and an output. If you call it twice then you have two outputs to decide how to aggregate. The way I've done it typically is something like (let's leave SPF check whitelisting out of the equation to keep it relatively simple): spfresult.helo in (pass,fail,softfail,permfail,tmpfail,none,...)=f(check_host(HELO identity, IP) Apply local policy: if spfresult.helo == fail, neutral, softfail, permerror then reject if spfresult.helo == temperror then defer else no definitive result if no definitive result: If Mail From == "" then Mail From = postmaster@HELO identity spfresult.mailfrom in (pass,fail,softfail,permfail,tmpfail,none,...)=f(check_host(Mail From identity, IP) Apply local policy: if spfresult.mailfrom == fail, permerror then reject if spfresult.mailfrom == temperror then defer else no definitive result If no definitive result, add Received SPF or A-R header fields for both checks and complete the SPF check (the messsage may still end up rejected, deferred, spamfoldered, dropped, or accepted based on other checks - I wouldn't recommend accepting just on SPF). The follow-on processing might include DMARC, but it's unrelated. Scott K Note: This is roughly the default processing the SPF policy server I wrote for postfix. There's lots of ways to do this and most of them wouldn't be wrong. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
