Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
- Original Message - > From: "Michael Jack Assels" > To: dmarc@ietf.org > Sent: Friday, January 23, 2015 4:06:12 PM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > nits, while I'm at it > > What seems like ages ago, on Thu, 22 Jan 2015 10:27:40 PST, > "Murray S. Kucherawy" wrote: > > > On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy > > wrote: > > http://www.blackops.org/~msk/dmarc/diff.html > > That sound to me like a call for thumbs up or thumbs down. I'd > personally like to change the infelicitous word "contradiction" > to "contrast", but rather than argue about changes, I think any > remaining argument should be simply about making the change as > proposed by Murray or not making any change at all. I've paid > attention to all the points raised, and I still think -13 is > better than -12. I don't think the floor is open for -14. > Yes "contrast" would make me more happy. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
What seems like ages ago, on Thu, 22 Jan 2015 10:27:40 PST, "Murray S. Kucherawy" wrote: > On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy > wrote: > > > I am asking the IESG and the ISE what the process is for making such > > adjustments now. > > > > Mainly my resistance to further change comes from the fact that we've done > > last calls of varying kinds on this document more times than I can count. > > It really is time to put the non-IETF version to bed and hand it off, even > > with its weaknesses, and let the standards process take it from there. > > There's a working group already chartered to do exactly that; in fact, that > > was one of the premises of creating that working group. > > > > I've consulted with the Area Director sponsoring the document's conflict > review, and the ISE. Both of them agree that we will only make changes > approved by the ISE and only during AUTH48 at this point, and those will be > limited to correcting serious problems that would prevent current DMARC > implementations from interacting properly. Anything else can be left to > the DMARC working group on its standards track deliverable. > > An argument can be made that this proposed change qualifies under that > definition, so please review it and comment as to whether it satisfies the > defect identified, or whether the change is necessary at all. I will > assume "yes" unless I hear otherwise. Again, the diff is here: > > http://www.blackops.org/~msk/dmarc/diff.html That sound to me like a call for thumbs up or thumbs down. I'd personally like to change the infelicitous word "contradiction" to "contrast", but rather than argue about changes, I think any remaining argument should be simply about making the change as proposed by Murray or not making any change at all. I've paid attention to all the points raised, and I still think -13 is better than -12. I don't think the floor is open for -14. MJA ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
- Original Message - > From: "Scott Kitterman" > To: dmarc@ietf.org > Sent: Friday, January 23, 2015 12:30:22 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 12:45:02 Franck Martin wrote: > > - Original Message - > > > > > From: "Scott Kitterman" > > > To: dmarc@ietf.org > > > Sent: Thursday, January 22, 2015 10:14:56 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 23:52:58 Franck Martin wrote: > > > > - Original Message - > > > > > > > > > > > > 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. > > > > First thanks, for describing in details your implementation. Very useful. > > > > > 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. > > > > Yes this is where the point is, RFC7208 does not define how to aggregate > > the > > results. This is the part which is not clear in the spec, and should be > > clearly spelled out, me thinks. > > I guess that's where we'll have to disagree. I don't know what RFC 7208 > could > have said beyond "How to aggregate SPF HELO and SPF Mail From checks is a > matter of local policy". That doesn't really help much. Personally, I don't > think they can be successfully aggregated into a single SPF result since they > are about different things. > No, no, we don't disagree, I did not express myself correctly. I would like to see this text you just wrote in the spec may be something like: "Aggregating SPF HELO and SPF Mail From checks is a matter of local policy. This document does not defines a single result nor how to get one, but defines a result for each check." ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On Friday, January 23, 2015 12:45:02 Franck Martin wrote: > - Original Message - > > > From: "Scott Kitterman" > > To: dmarc@ietf.org > > Sent: Thursday, January 22, 2015 10:14:56 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 23:52:58 Franck Martin wrote: > > > - Original Message - > > > > > > > > > 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. > > First thanks, for describing in details your implementation. Very useful. > > > 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. > > Yes this is where the point is, RFC7208 does not define how to aggregate the > results. This is the part which is not clear in the spec, and should be > clearly spelled out, me thinks. I guess that's where we'll have to disagree. I don't know what RFC 7208 could have said beyond "How to aggregate SPF HELO and SPF Mail From checks is a matter of local policy". That doesn't really help much. Personally, I don't think they can be successfully aggregated into a single SPF result since they are about different things. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On Friday, January 23, 2015 13:06:43 Hector Santos wrote: > On 1/22/2015 7:13 PM, Terry Zink wrote: > > The way it works in Office 365 is this: > > > > 1. When checking SPF, use the domain in the 5321.MailFrom. If it is empty, > > use the domain in the HELO/EHLO. 2. Use the domain extracted from (1) > > when doing the DMARC alignment check for SPF. > > > > We don't check both 5321.MailFrom AND HELO/EHLO for SPF. I've never found > > this to be a problem. > SPF Software that also supports: > > RFC4405 SUBMITTER SMTP Service Extension > RFC4406 Sender ID: Authenticating E-Mail > RFC4407 Purported Responsible Address (PRA) > > will also look at the PRA for SPF calculations. Enable the SMTP > Extension 4405 and watch many of the sessions using the SUBMITTER > field in MAIL FROM: > > MAIL FROM: SUBMITTER=pra Hector, As you know, those are Sender ID, not SPF. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
- Original Message - > From: "Scott Kitterman" > To: dmarc@ietf.org > Sent: Thursday, January 22, 2015 10:14:56 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 23:52:58 Franck Martin wrote: > > - Original Message - > > > > > > 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. First thanks, for describing in details your implementation. Very useful. > > 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. > Yes this is where the point is, RFC7208 does not define how to aggregate the results. This is the part which is not clear in the spec, and should be clearly spelled out, me thinks. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
- Original Message - > From: "Murray S. Kucherawy" > To: dmarc@ietf.org > Sent: Thursday, January 22, 2015 10:27:40 AM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > nits, while I'm at it > On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy < superu...@gmail.com > > wrote: > > I am asking the IESG and the ISE what the process is for making such > > adjustments now. > > > Mainly my resistance to further change comes from the fact that we've done > > last calls of varying kinds on this document more times than I can count. > > It > > really is time to put the non-IETF version to bed and hand it off, even > > with > > its weaknesses, and let the standards process take it from there. There's a > > working group already chartered to do exactly that; in fact, that was one > > of > > the premises of creating that working group. > > I've consulted with the Area Director sponsoring the document's conflict > review, and the ISE. Both of them agree that we will only make changes > approved by the ISE and only during AUTH48 at this point, and those will be > limited to correcting serious problems that would prevent current DMARC > implementations from interacting properly. Anything else can be left to the > DMARC working group on its standards track deliverable. > An argument can be made that this proposed change qualifies under that > definition, so please review it and comment as to whether it satisfies the > defect identified, or whether the change is necessary at all. I will assume > "yes" unless I hear otherwise. Again, the diff is here: > http://www.blackops.org/~msk/dmarc/diff.html So after the whole discussion, I don't think in 4.1 we can say "in contradiction of SPF". DMARC is defining a "local policy" for SPF, which is valid. People implementting DMARC must ensure their SPF implementation follow also this local policy. I would cite Terry's email where his SPF follows what DMARC expects, and where Scott said it is a valid implementation of SPF, and Scott implementation of SPF, which is valid too. I would also cite Tim's conformance tests, that matches operational deployment. So to be pedantic, suggested text: [SPF], which authenticates the HELO identity and the MAIL FROM identity: the domain found in an [SMTP] MAIL command, or the domain found in the HELO/EHLO command if the MAIL command has a null path. Note that in the context of DMARC, this later identity is only used. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On 1/22/2015 7:13 PM, Terry Zink wrote: The way it works in Office 365 is this: 1. When checking SPF, use the domain in the 5321.MailFrom. If it is empty, use the domain in the HELO/EHLO. 2. Use the domain extracted from (1) when doing the DMARC alignment check for SPF. We don't check both 5321.MailFrom AND HELO/EHLO for SPF. I've never found this to be a problem. SPF Software that also supports: RFC4405 SUBMITTER SMTP Service Extension RFC4406 Sender ID: Authenticating E-Mail RFC4407 Purported Responsible Address (PRA) will also look at the PRA for SPF calculations. Enable the SMTP Extension 4405 and watch many of the sessions using the SUBMITTER field in MAIL FROM: MAIL FROM: SUBMITTER=pra I don't know how it works in Hotmail (although I should) but it is moving over to the Office 365 infrastructure over the next several months anyhow so it will be the same. Its good to know that Microsoft is single sourcing it. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On Thursday, January 22, 2015 23:52:58 Franck Martin wrote: > - Original Message - > > > From: "Scott Kitterman" > > 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" > > > > 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
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
- Original Message - > From: "Scott Kitterman" > 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" > > > 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). ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On January 22, 2015 1:27:40 PM EST, "Murray S. Kucherawy" wrote: >On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy > >wrote: > >> I am asking the IESG and the ISE what the process is for making such >> adjustments now. >> >> Mainly my resistance to further change comes from the fact that we've >done >> last calls of varying kinds on this document more times than I can >count. >> It really is time to put the non-IETF version to bed and hand it off, >even >> with its weaknesses, and let the standards process take it from >there. >> There's a working group already chartered to do exactly that; in >fact, that >> was one of the premises of creating that working group. >> > >I've consulted with the Area Director sponsoring the document's >conflict >review, and the ISE. Both of them agree that we will only make changes >approved by the ISE and only during AUTH48 at this point, and those >will be >limited to correcting serious problems that would prevent current DMARC >implementations from interacting properly. Anything else can be left >to >the DMARC working group on its standards track deliverable. > >An argument can be made that this proposed change qualifies under that >definition, so please review it and comment as to whether it satisfies >the >defect identified, or whether the change is necessary at all. I will >assume "yes" unless I hear otherwise. Again, the diff is here: > >http://www.blackops.org/~msk/dmarc/diff.html I think what's in the diff is correct and a good clarification. I'm not sure the problem it fixes qualifies as serious, although the longer this thread goes on, the more I lean in that direction. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On January 22, 2015 4:20:35 PM EST, Michael Jack Assels wrote: >On Thu, 22 Jan 2015 14:46:59 CST, >Franck Martin wrote: > >> - Original Message - >> > From: "Michael Jack Assels" >> > To: dmarc@ietf.org >> > Sent: Thursday, January 22, 2015 12:00:58 PM >> > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two >more tiny nits, while I'm at it >> > >> > On Thu, 22 Jan 2015 12:48:03 CST, >> > Franck Martin wrote: >> > >> > > [] >> > > >> > > Hold on... >> > > >> > > What is the decision matrix of SPF? >> > > >> > > SPF uses two strings, the RFC5321.mailfrom and the >> > > RFC5321.helo. Each string may or may not have an SPF record. >> > > What gives the spf status? >> > >> > As I read RFC7208, it doesn't explicitly provide a decision >> > matrix, but it does clearly recommend in section 2.3, that >> > [i]f a conclusive determination about the message can be made >> > based on a check of "HELO", then the use of DNS resources to >> > process the typically more complex "MAIL FROM" can be avoided." >> > >> > Section 2.4 provides that "SPF verifiers MUST check the >> > [RFC5321.mailfrom] identity if a [RFC5321.helo] check either >> > has not been performed or has not reached a definitive policy" >> > >> > I can't think of a way to read that that doesn't imply that >> > a "pass" or a "fail" on the basis of an SPF record for the >> > RFC5321.helo indentity (if such a record exists) is the spf >> > result; otherwise, the result is based on the RFC5321.mailfrom >> > identity. >> > >> > I believe that this is not what DMARC implementations actually >> > do, and that the proposed change to the draft correctly points >> > out the difference and makes it clear what DMARC does, so if >> > I had a vote, I'd vote "yes" to the change. >> > >> >> Ok, but a specific well known implementation does not seem to >> do that: From http://www.openspf.org/Implementations Mail::SPF >> has passed the test suites >> >> http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm >> "Note: In the case of an empty MAIL FROM SMTP transaction >> parameter (MAIL FROM:<>), you should perform a check with the >> helo scope instead." > >This is what the proposed change says, isn't it? > >> an RFC to reach standard status needs to represent what is out >> there, I'd like to see more code before I form an opinion. > >I think we've crossed wires here. I unreservedly agree that >RFC7208 does NOT represent what all DMARC implementations do, >and it may not even represent what all SPF implementations do. >Perhaps RFC7208 needs correction, but given what it says now, >and given that DMARC has an obvious dependency on SPF, it's >important that DMARC's standard should say "contrary to what >RFC7208 recommends, DMARC normally SPF-checks HELO only when >MAIL FROM is <>". > >I don't think we're disagreeing about what DMARC does, or even >about what SPF usually does, despite what RFC7208 says. I think that's close. DMARC doesn't do SPF, it uses SPF results. Nothing contrary to RFC 7208 (or 4408). Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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" > > 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. > Usually, a SPEC will tell the receiver what it SHOULD do to define the spf= > status, but instead it seems RFC7208 says put whatever result you feel > like... Therefore different implementations will produce different results. > > I could have an implementation that checks HELO only and check MAILFROM and > ignore the last result to put in the SPF result and that would be in > accordance to RFC7208. I could have an implementation that checks HELO and > MAILFROM, where an helo pass is better than a MAILFROM fail or softfail, to > put SPF=pass as result and that would be still in accordance with RFC7208. > > or I'm mistaken? I think your mistake to insist that there be one and only one defined way to deal with SPF results from both HELO and Mail From and there isn't. Since RFC 7208 doesn't attempt (except in one special case) to dictate to receivers, it's not at all surprising the you fail to find direction on what to do as a receiver. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
- Original Message - > From: "Scott Kitterman" > 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... Usually, a SPEC will tell the receiver what it SHOULD do to define the spf= status, but instead it seems RFC7208 says put whatever result you feel like... Therefore different implementations will produce different results. I could have an implementation that checks HELO only and check MAILFROM and ignore the last result to put in the SPF result and that would be in accordance to RFC7208. I could have an implementation that checks HELO and MAILFROM, where an helo pass is better than a MAILFROM fail or softfail, to put SPF=pass as result and that would be still in accordance with RFC7208. or I'm mistaken? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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 > >again IF) a decision has been reached about message disposition based on > >the HELO result, there is no requirement to go ahead and do a pointless > >Mail From check. > > While that is certainly one plausible interpretation of the 7208 > language, it says "definitive policy result", a phrase that's not > defined anywhere, which may or may not involve a decision about mail > disposition. A "pass" result certainly strikes me as a definitive > policy result. Pass is an SPF result. I probably should have added the word local in front of policy when I wrote that. What I wrote above isn't just a random interpretation, it's what I meant when I wrote it and what we discussed in the working group. > >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. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
>RFC 7208 doesn't say the HELO result determines anything. It says IF (I say >again IF) a decision >has been reached about message disposition based on the HELO result, there is >no requirement to go >ahead and do a pointless Mail From check. While that is certainly one plausible interpretation of the 7208 language, it says "definitive policy result", a phrase that's not defined anywhere, which may or may not involve a decision about mail disposition. A "pass" result certainly strikes me as a definitive policy result. >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. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On Thursday, January 22, 2015 20:16:30 Franck Martin wrote: > - Original Message - > > > From: ned+dm...@mrochek.com > > To: "John Levine" > > Cc: dmarc@ietf.org, skl...@kitterman.com > > Sent: Thursday, January 22, 2015 5:41:46 PM > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > > nits, while I'm at it> > > > >DMARC leverages the Mail From identity, so I don't see how independent > > > >HELO checks can be relevant. > > > > > > If you look at sections 2.3 and 2.4 of RFC 7208, a reasonable > > > interpretation is that you check the HELO identity, and if you get a > > > "definitive policy" result, you're done and return that to the caller. > > > > > > So a message comes from host mail.provider.com with From: > > > b...@customer.com. The recipient host does an SPF check on > > > mail.provider.com, it passes, so SPF is done. DMARC sees that the SPF > > > domain isn't aligned so it ignores it, and DMARC says it's unaligned, > > > even though an SPF check of customer.com might have passed. > > > > > > I can't say whether this is a bug in 7208 or a fundamental flaw in > > > DMARC, but something is clearly wrong and this does not match what > > > running code does. As things are written now, I don't see any way to > > > demand that SPF look at the MAIL FROM if it likes the HELO. > > > > > > Fix 1: file an erratum on 7208 to say to switch the order, do the MAIL > > > FROM check first and only do the HELO check otherwise. This may match > > > some running code, I haven't looked. > > > > > > Fix 2: change 7208 to say that SPF can return multiple results. Ugh. > > > > Filing an erratum for purposes of documenting the issue is fine, but since > > this > > is a substantive change to the protocol it far exceeds the scope of what > > approval of an erratum is allowed to do. As such, I believe the best > > outcome you can get here would be "held for document update". > > I tried to understand Scott, and I think this is what is missing in RFC7208. > > Each check_host() is meant to be done as soon as you have the data to do it. > > So after the HELO phase in SMTP RFC5321, you do check_host(HELO identity, > IP). You get a result and apply the SPF policy (and disconnect if policy > says so) after the mail from phase, you do check_host(MAIL FROM identity, > IP). You get a result and apply the SPF policy (and disconnect if policy > says so) > > This makes sense then, except when SPF policy on both check_host is not -all > > The difficulty then comes when you do these check_host() later in the > RFC5321 transaction, as you have to emulate, this serialization. And then > there is still some uncertainty on what to do when both SPF records exist > and do not have -all both (or when receivers consider -all as ~all) There is no uncertainty. What you do it apply local policy. End of story. The only tricky part is you have to decide what local policy is. This is not new. > I think RFC7208 confused more this serialization, that was implicit in > RFC4408, like the elephant in the room. :P > > To come back to operational matters, I think SPF implementations just do > check_host(MAIL FROM identity, IP) as Terry pointed out, this is why I > suggest DMARC spec could just say that: "DMARC uses only the MAIL FROM > identity and results of the check_host() of the MAIL FROM identity as > defined in RFC7208)" > > And we will fix RFC7208 later to match operational deployments, but this > ought to be recorded somewhere. > > (add reporting to emails, and you get plenty new questions about > standardizations :P) What the code I've written and distributed does is check HELO and if there's not a reject (definitive result) store the helo result and then check Mail From (using the synthetic postmaster@HELO if needed). If the message is not rejected/deferred then the appropriate result header (SPF Received or auth- res) is added for both results. There is a configuration option to only check HELO if Mail From is null, but it's not the default. By default, Postfix (which is what I'm writing for) delays all such checks until rcpt to, so no. There's absolutely no need to do check_host() as soon as you have the information. IIRC I first wrote that code in about 2007 based on RFC 4408. The only way it didn't do explicitly what 4408 required was that it didn't both doing a Mail >From check that would have been pointless since the message was already going to be rejected. We fixed that bug in the spec in RFC 7208 during SPFbis. I really think this is making a mountain out of the tiniest of molehills. Recall: The almost complete lack of receiver policy specification in RFC 4408 (and RFC 7208) is not an oversight. It was a deliberate design choice. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On Thursday, January 22, 2015 17:59:42 Kurt Andersen wrote: > On Thu, Jan 22, 2015 at 5:03 PM, Scott Kitterman > > wrote: > > On January 22, 2015 6:35:59 PM EST, Kurt Andersen > > > > wrote: > > >On Thu, Jan 22, 2015 at 3:30 PM, Scott Kitterman > > > > > >wrote: > > >> If I were configuring and SPF verifier to provide an input to DMARC > > >> processing, then I would probably configure it not to reject based on > > >> SPF fail. Then the problem doesn't arise. > > > > > >Are you suggesting that the DMARC spec should say that people SHOULD > > >configure (some would say usurp) SPF in such a way? I seem to recall > > >some > > >contentious discussions about such usurpation during SPFbis (though I > > >could > > >be conflating arguments from another context). > > > > Of course. Section 6.7 discusses this in general terms. If you want to > > only use SPF as an input to DMARC, then it wouldn't make sense to set up > > your system to reject mail just based on SPF. > > > > Specifying receiver policy was somewhat contentious in SPFbis. In the > > end, RFC7208 specifies almost, if not, exactly the same amount of receiver > > policy as did RFC4408 (almost none). > > I think that the crux of the issue is this: > 1) The DMARC spec was written with 4408 as context. That remains true > today, except that in the meantime 7208 was finalized (thanks to SPFbis) > and Murray was seeking to keep up with the times by following the "7208 > obsoletes 4408" statement. > 2) The key problem is that 7208 changes the checking precedence. Here's > what the two specs actually say: > 4408, section 2.2: "SPF clients MUST check the "MAIL FROM" identity." > 7208, section 2.4: "SPF verifiers MUST check the "MAIL FROM" identity if a > "HELO" check either has not been performed or has not reached a definitive > policy. . ." > > My recommendation is to take -12 and amend it to change the SPF reference > back to 4408 and let the WG wrestle through how to handle the change that > was introduced in 7208. If you've already rejected the message (e.g. HELO check reached a definitive result) the DMARC doesn't care. There's no relevant change between 4408 and 7208. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On Thursday, January 22, 2015 17:41:46 Ned Freed wrote: > > >DMARC leverages the Mail From identity, so I don't see how independent > > >HELO checks can be relevant.> > > If you look at sections 2.3 and 2.4 of RFC 7208, a reasonable > > interpretation is that you check the HELO identity, and if you get a > > "definitive policy" result, you're done and return that to the caller. > > > > So a message comes from host mail.provider.com with From: > > b...@customer.com. The recipient host does an SPF check on > > mail.provider.com, it passes, so SPF is done. DMARC sees that the SPF > > domain isn't aligned so it ignores it, and DMARC says it's unaligned, > > even though an SPF check of customer.com might have passed. > > > > I can't say whether this is a bug in 7208 or a fundamental flaw in > > DMARC, but something is clearly wrong and this does not match what > > running code does. As things are written now, I don't see any way to > > demand that SPF look at the MAIL FROM if it likes the HELO. > > > > Fix 1: file an erratum on 7208 to say to switch the order, do the MAIL > > FROM check first and only do the HELO check otherwise. This may match > > some running code, I haven't looked. > > > > Fix 2: change 7208 to say that SPF can return multiple results. Ugh. > > Filing an erratum for purposes of documenting the issue is fine, but since > this is a substantive change to the protocol it far exceeds the scope of > what approval of an erratum is allowed to do. As such, I believe the best > outcome you can get here would be "held for document update". Please don't. There's no error to document. Order was explicitly discussed during SPFbis and is not there by accident. Just because someone working on an unrelated ISE draft thinks it should have been different doesn't create an error. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
- Original Message - > From: "Kurt Andersen" > To: "Scott Kitterman" > Cc: dmarc@ietf.org > Sent: Thursday, January 22, 2015 5:59:42 PM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > nits, while I'm at it > On Thu, Jan 22, 2015 at 5:03 PM, Scott Kitterman < skl...@kitterman.com > > wrote: > > On January 22, 2015 6:35:59 PM EST, Kurt Andersen < kb...@drkurt.com > > > wrote: > > > >On Thu, Jan 22, 2015 at 3:30 PM, Scott Kitterman < skl...@kitterman.com > > > > >wrote: > > > > > > > >> If I were configuring and SPF verifier to provide an input to DMARC > > > >> processing, then I would probably configure it not to reject based on > > > >> SPF fail. Then the problem doesn't arise. > > > > > > > > > > > >Are you suggesting that the DMARC spec should say that people SHOULD > > > >configure (some would say usurp) SPF in such a way? I seem to recall > > > >some > > > >contentious discussions about such usurpation during SPFbis (though I > > > >could > > > >be conflating arguments from another context). > > > Of course. Section 6.7 discusses this in general terms. If you want to only > > use SPF as an input to DMARC, then it wouldn't make sense to set up your > > system to reject mail just based on SPF. > > > Specifying receiver policy was somewhat contentious in SPFbis. In the end, > > RFC7208 specifies almost, if not, exactly the same amount of receiver > > policy > > as did RFC4408 (almost none). > > I think that the crux of the issue is this: > 1) The DMARC spec was written with 4408 as context. That remains true today, > except that in the meantime 7208 was finalized (thanks to SPFbis) and Murray > was seeking to keep up with the times by following the "7208 obsoletes 4408" > statement. > 2) The key problem is that 7208 changes the checking precedence. Here's what > the two specs actually say: > 4408, section 2.2: "SPF clients MUST check the "MAIL FROM" identity." > 7208, section 2.4: "SPF verifiers MUST check the "MAIL FROM" identity if a > "HELO" check either has not been performed or has not reached a definitive > policy. . ." I think this text in 7208 is wrong, if you consider the serialization for the checks implicit in 4408, it should have been written: "SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check either has not been performed or has not reached a definitive fail result that led to the application of the -all policy. . ." But I think the fix is a bit more complex to be elegant. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
- Original Message - > From: ned+dm...@mrochek.com > To: "John Levine" > Cc: dmarc@ietf.org, skl...@kitterman.com > Sent: Thursday, January 22, 2015 5:41:46 PM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > nits, while I'm at it > > > >DMARC leverages the Mail From identity, so I don't see how independent > > >HELO checks can be relevant. > > > If you look at sections 2.3 and 2.4 of RFC 7208, a reasonable > > interpretation is that you check the HELO identity, and if you get a > > "definitive policy" result, you're done and return that to the caller. > > > So a message comes from host mail.provider.com with From: > > b...@customer.com. The recipient host does an SPF check on > > mail.provider.com, it passes, so SPF is done. DMARC sees that the SPF > > domain isn't aligned so it ignores it, and DMARC says it's unaligned, > > even though an SPF check of customer.com might have passed. > > > I can't say whether this is a bug in 7208 or a fundamental flaw in > > DMARC, but something is clearly wrong and this does not match what > > running code does. As things are written now, I don't see any way to > > demand that SPF look at the MAIL FROM if it likes the HELO. > > > Fix 1: file an erratum on 7208 to say to switch the order, do the MAIL > > FROM check first and only do the HELO check otherwise. This may match > > some running code, I haven't looked. > > > Fix 2: change 7208 to say that SPF can return multiple results. Ugh. > > Filing an erratum for purposes of documenting the issue is fine, but since > this > is a substantive change to the protocol it far exceeds the scope of what > approval of an erratum is allowed to do. As such, I believe the best outcome > you can get here would be "held for document update". > I tried to understand Scott, and I think this is what is missing in RFC7208. Each check_host() is meant to be done as soon as you have the data to do it. So after the HELO phase in SMTP RFC5321, you do check_host(HELO identity, IP). You get a result and apply the SPF policy (and disconnect if policy says so) after the mail from phase, you do check_host(MAIL FROM identity, IP). You get a result and apply the SPF policy (and disconnect if policy says so) This makes sense then, except when SPF policy on both check_host is not -all The difficulty then comes when you do these check_host() later in the RFC5321 transaction, as you have to emulate, this serialization. And then there is still some uncertainty on what to do when both SPF records exist and do not have -all both (or when receivers consider -all as ~all) I think RFC7208 confused more this serialization, that was implicit in RFC4408, like the elephant in the room. :P To come back to operational matters, I think SPF implementations just do check_host(MAIL FROM identity, IP) as Terry pointed out, this is why I suggest DMARC spec could just say that: "DMARC uses only the MAIL FROM identity and results of the check_host() of the MAIL FROM identity as defined in RFC7208)" And we will fix RFC7208 later to match operational deployments, but this ought to be recorded somewhere. (add reporting to emails, and you get plenty new questions about standardizations :P) ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On Thu, Jan 22, 2015 at 5:03 PM, Scott Kitterman wrote: > On January 22, 2015 6:35:59 PM EST, Kurt Andersen > wrote: > >On Thu, Jan 22, 2015 at 3:30 PM, Scott Kitterman > >wrote: > > > >> If I were configuring and SPF verifier to provide an input to DMARC > >> processing, then I would probably configure it not to reject based on > >> SPF fail. Then the problem doesn't arise. > > > > > >Are you suggesting that the DMARC spec should say that people SHOULD > >configure (some would say usurp) SPF in such a way? I seem to recall > >some > >contentious discussions about such usurpation during SPFbis (though I > >could > >be conflating arguments from another context). > > Of course. Section 6.7 discusses this in general terms. If you want to > only use SPF as an input to DMARC, then it wouldn't make sense to set up > your system to reject mail just based on SPF. > > Specifying receiver policy was somewhat contentious in SPFbis. In the > end, RFC7208 specifies almost, if not, exactly the same amount of receiver > policy as did RFC4408 (almost none). > I think that the crux of the issue is this: 1) The DMARC spec was written with 4408 as context. That remains true today, except that in the meantime 7208 was finalized (thanks to SPFbis) and Murray was seeking to keep up with the times by following the "7208 obsoletes 4408" statement. 2) The key problem is that 7208 changes the checking precedence. Here's what the two specs actually say: 4408, section 2.2: "SPF clients MUST check the "MAIL FROM" identity." 7208, section 2.4: "SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check either has not been performed or has not reached a definitive policy. . ." My recommendation is to take -12 and amend it to change the SPF reference back to 4408 and let the WG wrestle through how to handle the change that was introduced in 7208. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
> >DMARC leverages the Mail From identity, so I don't see how independent HELO > >checks can be relevant. > If you look at sections 2.3 and 2.4 of RFC 7208, a reasonable > interpretation is that you check the HELO identity, and if you get a > "definitive policy" result, you're done and return that to the caller. > So a message comes from host mail.provider.com with From: > b...@customer.com. The recipient host does an SPF check on > mail.provider.com, it passes, so SPF is done. DMARC sees that the SPF > domain isn't aligned so it ignores it, and DMARC says it's unaligned, > even though an SPF check of customer.com might have passed. > I can't say whether this is a bug in 7208 or a fundamental flaw in > DMARC, but something is clearly wrong and this does not match what > running code does. As things are written now, I don't see any way to > demand that SPF look at the MAIL FROM if it likes the HELO. > Fix 1: file an erratum on 7208 to say to switch the order, do the MAIL > FROM check first and only do the HELO check otherwise. This may match > some running code, I haven't looked. > Fix 2: change 7208 to say that SPF can return multiple results. Ugh. Filing an erratum for purposes of documenting the issue is fine, but since this is a substantive change to the protocol it far exceeds the scope of what approval of an erratum is allowed to do. As such, I believe the best outcome you can get here would be "held for document update". Ned ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On January 22, 2015 6:35:59 PM EST, Kurt Andersen wrote: >On Thu, Jan 22, 2015 at 3:30 PM, Scott Kitterman >wrote: > >> If I were configuring and SPF verifier to provide an input to DMARC >> processing, then I would probably configure it not to reject based on >SPF >> fail. Then the problem doesn't arise. >> >> This really is a non-issue. >> > > >Are you suggesting that the DMARC spec should say that people SHOULD >configure (some would say usurp) SPF in such a way? I seem to recall >some >contentious discussions about such usurpation during SPFbis (though I >could >be conflating arguments from another context). Of course. Section 6.7 discusses this in general terms. If you want to only use SPF as an input to DMARC, then it wouldn't make sense to set up your system to reject mail just based on SPF. Specifying receiver policy was somewhat contentious in SPFbis. In the end, RFC7208 specifies almost, if not, exactly the same amount of receiver policy as did RFC4408 (almost none). Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On January 22, 2015 7:13:46 PM EST, Terry Zink wrote: >The way it works in Office 365 is this: > >1. When checking SPF, use the domain in the 5321.MailFrom. If it is >empty, use the domain in the HELO/EHLO. >2. Use the domain extracted from (1) when doing the DMARC alignment >check for SPF. > >We don't check both 5321.MailFrom AND HELO/EHLO for SPF. I've never >found this to be a problem. > >I don't know how it works in Hotmail (although I should) but it is >moving over to the Office 365 infrastructure over the next several >months anyhow so it will be the same. > >-- Terry > >-Original Message- >From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Franck Martin >Sent: Thursday, January 22, 2015 3:58 PM >To: R E Sonneveld >Cc: dmarc@ietf.org; Michael Jack Assels >Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more >tiny nits, while I'm at it >if you send a bounce, and usually some MTAs have trouble to sign the >bounce they generate (not anymore true with postfix but a bit tricky to >setup), then the only way to recover the message is to ensure there is >an SPF aligned on the string presented by HELO. > >So basically, I would say DMARC takes only the result of the check_host >for the MAIL FROM entity which contains the postmaster@helo if the >RFC5321.mailfrom is empty. > >Murray, I think the elegant way in DMARC to refer to RFC7208 is this. > >"DMARC uses only the result of the check_host() applied on the MAIL >FROM entity as defined by RFC7208. The MAIL FROM entity is the one used >for alignment checking.". > >If I recall the operational test created by Tim, were checking these >cases: http://dmarc-qa.com/ (2.1) > >We all ran these tests during inter-op for conformance. > >___ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc > >___ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc This is a perfectly reasonable way to do it. Spamassassin checks both independently (using Mail::SPF) and applies the results to two different SA tests. There's more than one way to do it (Meng Wong is a Perl programmer). Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
The way it works in Office 365 is this: 1. When checking SPF, use the domain in the 5321.MailFrom. If it is empty, use the domain in the HELO/EHLO. 2. Use the domain extracted from (1) when doing the DMARC alignment check for SPF. We don't check both 5321.MailFrom AND HELO/EHLO for SPF. I've never found this to be a problem. I don't know how it works in Hotmail (although I should) but it is moving over to the Office 365 infrastructure over the next several months anyhow so it will be the same. -- Terry -Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Franck Martin Sent: Thursday, January 22, 2015 3:58 PM To: R E Sonneveld Cc: dmarc@ietf.org; Michael Jack Assels Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it if you send a bounce, and usually some MTAs have trouble to sign the bounce they generate (not anymore true with postfix but a bit tricky to setup), then the only way to recover the message is to ensure there is an SPF aligned on the string presented by HELO. So basically, I would say DMARC takes only the result of the check_host for the MAIL FROM entity which contains the postmaster@helo if the RFC5321.mailfrom is empty. Murray, I think the elegant way in DMARC to refer to RFC7208 is this. "DMARC uses only the result of the check_host() applied on the MAIL FROM entity as defined by RFC7208. The MAIL FROM entity is the one used for alignment checking.". If I recall the operational test created by Tim, were checking these cases: http://dmarc-qa.com/ (2.1) We all ran these tests during inter-op for conformance. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
- Original Message - > From: "Rolf E. Sonneveld" > To: "Franck Martin" , "Michael Jack Assels" > > Cc: dmarc@ietf.org > Sent: Thursday, January 22, 2015 3:08:51 PM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > nits, while I'm at it > > On 01/22/2015 09:46 PM, Franck Martin wrote: > > > > > > > > - Original Message - > >> From: "Michael Jack Assels" > >> To: dmarc@ietf.org > >> Sent: Thursday, January 22, 2015 12:00:58 PM > >> Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > >> nits, while I'm at it > >> > >> On Thu, 22 Jan 2015 12:48:03 CST, > >> Franck Martin wrote: > >> > >>> ----- Original Message ----- > >>> > >>>> From: "Murray S. Kucherawy" > >>>> To: dmarc@ietf.org > >>>> Sent: Thursday, January 22, 2015 10:27:40 AM > >>>> Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more > >>>> tiny nits, while I'm at it > >>>> On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy < > >>>> superu...@gmail.com > > >>>> wrote: > >>>>> I am asking the IESG and the ISE what the process is for > >>>>> making such adjustments now. > >>>>> Mainly my resistance to further change comes from the fact > >>>>> that we've done last calls of varying kinds on this > >>>>> document more times than I can count. It really is time to > >>>>> put the non-IETF version to bed and hand it off, even with > >>>>> its weaknesses, and let the standards process take it from > >>>>> there. There's a working group already chartered to do > >>>>> exactly that; in fact, that was one of the premises of > >>>>> creating that working group. > >>>> I've consulted with the Area Director sponsoring the > >>>> document's conflict review, and the ISE. Both of them agree > >>>> that we will only make changes approved by the ISE and only > >>>> during AUTH48 at this point, and those will be limited to > >>>> correcting serious problems that would prevent current DMARC > >>>> implementations from interacting properly. Anything else can > >>>> be left to the DMARC working group on its standards track > >>>> deliverable. > >>>> An argument can be made that this proposed change qualifies > >>>> under that definition, so please review it and comment as to > >>>> whether it satisfies the defect identified, or whether the > >>>> change is necessary at all. I will assume "yes" unless I hear > >>>> otherwise. Again, the diff is here: > >>>> http://www.blackops.org/~msk/dmarc/diff.html > >>> Hold on... > >>> > >>> What is the decision matrix of SPF? > >>> > >>> SPF uses two strings, the RFC5321.mailfrom and the > >>> RFC5321.helo. Each string may or may not have an SPF record. > >>> What gives the spf status? > >> As I read RFC7208, it doesn't explicitly provide a decision > >> matrix, but it does clearly recommend in section 2.3, that > >> [i]f a conclusive determination about the message can be made > >> based on a check of "HELO", then the use of DNS resources to > >> process the typically more complex "MAIL FROM" can be avoided." > >> > >> Section 2.4 provides that "SPF verifiers MUST check the > >> [RFC5321.mailfrom] identity if a [RFC5321.helo] check either > >> has not been performed or has not reached a definitive policy" > >> > >> I can't think of a way to read that that doesn't imply that > >> a "pass" or a "fail" on the basis of an SPF record for the > >> RFC5321.helo indentity (if such a record exists) is the spf > >> result; otherwise, the result is based on the RFC5321.mailfrom > >> identity. > >> > >> I believe that this is not what DMARC implementations actually > >> do, and that the proposed change to the draft correctly points > >> out the difference and makes it clear what DMARC does, so if > >> I had a vote, I'd vote "yes" to the change. > >> > > Ok, but a specific well known implementation does not seem to do that: >
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On Thu, Jan 22, 2015 at 3:30 PM, Scott Kitterman wrote: > If I were configuring and SPF verifier to provide an input to DMARC > processing, then I would probably configure it not to reject based on SPF > fail. Then the problem doesn't arise. > > This really is a non-issue. > Are you suggesting that the DMARC spec should say that people SHOULD configure (some would say usurp) SPF in such a way? I seem to recall some contentious discussions about such usurpation during SPFbis (though I could be conflating arguments from another context). --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On January 22, 2015 6:17:28 PM EST, John Levine wrote: >>DMARC leverages the Mail From identity, so I don't see how independent >HELO checks can be relevant. > >If you look at sections 2.3 and 2.4 of RFC 7208, a reasonable >interpretation is that you check the HELO identity, and if you get a >"definitive policy" result, you're done and return that to the caller. > >So a message comes from host mail.provider.com with From: >b...@customer.com. The recipient host does an SPF check on >mail.provider.com, it passes, so SPF is done. DMARC sees that the SPF >domain isn't aligned so it ignores it, and DMARC says it's unaligned, >even though an SPF check of customer.com might have passed. > >I can't say whether this is a bug in 7208 or a fundamental flaw in >DMARC, but something is clearly wrong and this does not match what >running code does. As things are written now, I don't see any way to >demand that SPF look at the MAIL FROM if it likes the HELO. > >Fix 1: file an erratum on 7208 to say to switch the order, do the MAIL >FROM check first and only do the HELO check otherwise. This may match >some running code, I haven't looked. > >Fix 2: change 7208 to say that SPF can return multiple results. Ugh. 4408 and 7208 both suggest multiple calls to check_host() each with a single result. If I were configuring and SPF verifier to provide an input to DMARC processing, then I would probably configure it not to reject based on SPF fail. Then the problem doesn't arise. This really is a non-issue. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On January 22, 2015 5:47:42 PM EST, Franck Martin wrote: > > > > >- Original Message - >> From: "Michael Jack Assels" >> To: dmarc@ietf.org >> Sent: Thursday, January 22, 2015 1:20:35 PM >> Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more >tiny nits, while I'm at it >> >> On Thu, 22 Jan 2015 14:46:59 CST, >> Franck Martin wrote: >> >> > - Original Message - >> > > From: "Michael Jack Assels" >> > > To: dmarc@ietf.org >> > > Sent: Thursday, January 22, 2015 12:00:58 PM >> > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two >more >> > > tiny nits, while I'm at it >> > > >> > > On Thu, 22 Jan 2015 12:48:03 CST, >> > > Franck Martin wrote: >> > > >> > > > [] >> > > > >> > > > Hold on... >> > > > >> > > > What is the decision matrix of SPF? >> > > > >> > > > SPF uses two strings, the RFC5321.mailfrom and the >> > > > RFC5321.helo. Each string may or may not have an SPF record. >> > > > What gives the spf status? >> > > >> > > As I read RFC7208, it doesn't explicitly provide a decision >> > > matrix, but it does clearly recommend in section 2.3, that >> > > [i]f a conclusive determination about the message can be made >> > > based on a check of "HELO", then the use of DNS resources to >> > > process the typically more complex "MAIL FROM" can be avoided." >> > > >> > > Section 2.4 provides that "SPF verifiers MUST check the >> > > [RFC5321.mailfrom] identity if a [RFC5321.helo] check either >> > > has not been performed or has not reached a definitive policy" >> > > >> > > I can't think of a way to read that that doesn't imply that >> > > a "pass" or a "fail" on the basis of an SPF record for the >> > > RFC5321.helo indentity (if such a record exists) is the spf >> > > result; otherwise, the result is based on the RFC5321.mailfrom >> > > identity. >> > > >> > > I believe that this is not what DMARC implementations actually >> > > do, and that the proposed change to the draft correctly points >> > > out the difference and makes it clear what DMARC does, so if >> > > I had a vote, I'd vote "yes" to the change. >> > > >> > >> > Ok, but a specific well known implementation does not seem to >> > do that: From http://www.openspf.org/Implementations Mail::SPF >> > has passed the test suites >> > >> > http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm >> > "Note: In the case of an empty MAIL FROM SMTP transaction >> > parameter (MAIL FROM:<>), you should perform a check with the >> > helo scope instead." >> >> This is what the proposed change says, isn't it? >> >> > an RFC to reach standard status needs to represent what is out >> > there, I'd like to see more code before I form an opinion. >> >> I think we've crossed wires here. I unreservedly agree that >> RFC7208 does NOT represent what all DMARC implementations do, >> and it may not even represent what all SPF implementations do. >> Perhaps RFC7208 needs correction, but given what it says now, >> and given that DMARC has an obvious dependency on SPF, it's >> important that DMARC's standard should say "contrary to what >> RFC7208 recommends, DMARC normally SPF-checks HELO only when >> MAIL FROM is <>". >> >> I don't think we're disagreeing about what DMARC does, or even >> about what SPF usually does, despite what RFC7208 says. >> > >Yes, this is my point, seems to me RFC7208 needs an errata... than >DMARC... but I'm ok with the proposed language, I just think DMARC >should avoid to fix problems with lower protocols... > > >If you read the previous RFC: >http://trac.tools.ietf.org/html/rfc4408 section 2.2 > > [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in > RFC 2821). In this case, there is no explicit sender mailbox, and > such a message can be assumed to be a notification message from the > mail system itself. When the reverse-path is null, this document > defines the "MAIL FROM" identity to be the mailbox composed of the > localpart &quo
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
>DMARC leverages the Mail From identity, so I don't see how independent HELO >checks can be relevant. If you look at sections 2.3 and 2.4 of RFC 7208, a reasonable interpretation is that you check the HELO identity, and if you get a "definitive policy" result, you're done and return that to the caller. So a message comes from host mail.provider.com with From: b...@customer.com. The recipient host does an SPF check on mail.provider.com, it passes, so SPF is done. DMARC sees that the SPF domain isn't aligned so it ignores it, and DMARC says it's unaligned, even though an SPF check of customer.com might have passed. I can't say whether this is a bug in 7208 or a fundamental flaw in DMARC, but something is clearly wrong and this does not match what running code does. As things are written now, I don't see any way to demand that SPF look at the MAIL FROM if it likes the HELO. Fix 1: file an erratum on 7208 to say to switch the order, do the MAIL FROM check first and only do the HELO check otherwise. This may match some running code, I haven't looked. Fix 2: change 7208 to say that SPF can return multiple results. Ugh. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On 01/22/2015 09:46 PM, Franck Martin wrote: - Original Message - From: "Michael Jack Assels" To: dmarc@ietf.org Sent: Thursday, January 22, 2015 12:00:58 PM Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it On Thu, 22 Jan 2015 12:48:03 CST, Franck Martin wrote: - Original Message - From: "Murray S. Kucherawy" To: dmarc@ietf.org Sent: Thursday, January 22, 2015 10:27:40 AM Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy < superu...@gmail.com > wrote: I am asking the IESG and the ISE what the process is for making such adjustments now. Mainly my resistance to further change comes from the fact that we've done last calls of varying kinds on this document more times than I can count. It really is time to put the non-IETF version to bed and hand it off, even with its weaknesses, and let the standards process take it from there. There's a working group already chartered to do exactly that; in fact, that was one of the premises of creating that working group. I've consulted with the Area Director sponsoring the document's conflict review, and the ISE. Both of them agree that we will only make changes approved by the ISE and only during AUTH48 at this point, and those will be limited to correcting serious problems that would prevent current DMARC implementations from interacting properly. Anything else can be left to the DMARC working group on its standards track deliverable. An argument can be made that this proposed change qualifies under that definition, so please review it and comment as to whether it satisfies the defect identified, or whether the change is necessary at all. I will assume "yes" unless I hear otherwise. Again, the diff is here: http://www.blackops.org/~msk/dmarc/diff.html Hold on... What is the decision matrix of SPF? SPF uses two strings, the RFC5321.mailfrom and the RFC5321.helo. Each string may or may not have an SPF record. What gives the spf status? As I read RFC7208, it doesn't explicitly provide a decision matrix, but it does clearly recommend in section 2.3, that [i]f a conclusive determination about the message can be made based on a check of "HELO", then the use of DNS resources to process the typically more complex "MAIL FROM" can be avoided." Section 2.4 provides that "SPF verifiers MUST check the [RFC5321.mailfrom] identity if a [RFC5321.helo] check either has not been performed or has not reached a definitive policy" I can't think of a way to read that that doesn't imply that a "pass" or a "fail" on the basis of an SPF record for the RFC5321.helo indentity (if such a record exists) is the spf result; otherwise, the result is based on the RFC5321.mailfrom identity. I believe that this is not what DMARC implementations actually do, and that the proposed change to the draft correctly points out the difference and makes it clear what DMARC does, so if I had a vote, I'd vote "yes" to the change. Ok, but a specific well known implementation does not seem to do that: >From http://www.openspf.org/Implementations Mail::SPF has passed the test suites http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm "Note: In the case of an empty MAIL FROM SMTP transaction parameter (MAIL FROM:<>), you should perform a check with the helo scope instead." an RFC to reach standard status needs to represent what is out there, the current draft is heading for Informational status, not standard status. Having said that I fully agree with: I'd like to see more code before I form an opinion. as from an interoperability point of view it is important to know what the various implementations of the current implementors do exactly with SPF re. the point raised by Anne (SPF use of RFC5321.MailFrom vs. RFC5321.EHLO/HELO). As for the 'SPF part of DMARC only an 'SPF pass' counts it must be crystal clear how an 'SPF pass' is reached. Therefore, if (repeat: if) all current implementations of DMARC only use the RFC5321.MailFrom, I'd suggest to use RFC2119 terminology here, like: -13 text: Note that the RFC5321.HELO identity is not typically used in the context of DMARC (except when required to "fake" an otherwise null reverse-path), even though a "pure SPF" implementation according to [SPF] would check that identifier. Suggested text: If RFC5321.MailFrom identity is present and not null, the RFC5321.HELO identity MUST NOT be used in the context of DMARC, even though a "pure SPF" implementation according to [SPF] would check that identifier. /rolf ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
- Original Message - > From: "Michael Jack Assels" > To: dmarc@ietf.org > Sent: Thursday, January 22, 2015 1:20:35 PM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > nits, while I'm at it > > On Thu, 22 Jan 2015 14:46:59 CST, > Franck Martin wrote: > > > - Original Message - > > > From: "Michael Jack Assels" > > > To: dmarc@ietf.org > > > Sent: Thursday, January 22, 2015 12:00:58 PM > > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more > > > tiny nits, while I'm at it > > > > > > On Thu, 22 Jan 2015 12:48:03 CST, > > > Franck Martin wrote: > > > > > > > [] > > > > > > > > Hold on... > > > > > > > > What is the decision matrix of SPF? > > > > > > > > SPF uses two strings, the RFC5321.mailfrom and the > > > > RFC5321.helo. Each string may or may not have an SPF record. > > > > What gives the spf status? > > > > > > As I read RFC7208, it doesn't explicitly provide a decision > > > matrix, but it does clearly recommend in section 2.3, that > > > [i]f a conclusive determination about the message can be made > > > based on a check of "HELO", then the use of DNS resources to > > > process the typically more complex "MAIL FROM" can be avoided." > > > > > > Section 2.4 provides that "SPF verifiers MUST check the > > > [RFC5321.mailfrom] identity if a [RFC5321.helo] check either > > > has not been performed or has not reached a definitive policy" > > > > > > I can't think of a way to read that that doesn't imply that > > > a "pass" or a "fail" on the basis of an SPF record for the > > > RFC5321.helo indentity (if such a record exists) is the spf > > > result; otherwise, the result is based on the RFC5321.mailfrom > > > identity. > > > > > > I believe that this is not what DMARC implementations actually > > > do, and that the proposed change to the draft correctly points > > > out the difference and makes it clear what DMARC does, so if > > > I had a vote, I'd vote "yes" to the change. > > > > > > > Ok, but a specific well known implementation does not seem to > > do that: From http://www.openspf.org/Implementations Mail::SPF > > has passed the test suites > > > > http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm > > "Note: In the case of an empty MAIL FROM SMTP transaction > > parameter (MAIL FROM:<>), you should perform a check with the > > helo scope instead." > > This is what the proposed change says, isn't it? > > > an RFC to reach standard status needs to represent what is out > > there, I'd like to see more code before I form an opinion. > > I think we've crossed wires here. I unreservedly agree that > RFC7208 does NOT represent what all DMARC implementations do, > and it may not even represent what all SPF implementations do. > Perhaps RFC7208 needs correction, but given what it says now, > and given that DMARC has an obvious dependency on SPF, it's > important that DMARC's standard should say "contrary to what > RFC7208 recommends, DMARC normally SPF-checks HELO only when > MAIL FROM is <>". > > I don't think we're disagreeing about what DMARC does, or even > about what SPF usually does, despite what RFC7208 says. > Yes, this is my point, seems to me RFC7208 needs an errata... than DMARC... but I'm ok with the proposed language, I just think DMARC should avoid to fix problems with lower protocols... If you read the previous RFC: http://trac.tools.ietf.org/html/rfc4408 section 2.2 [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in RFC 2821). In this case, there is no explicit sender mailbox, and such a message can be assumed to be a notification message from the mail system itself. When the reverse-path is null, this document defines the "MAIL FROM" identity to be the mailbox composed of the localpart "postmaster" and the "HELO" identity (which may or may not have been checked separately before). SPF clients MUST check the "MAIL FROM" identity. SPF clients check the "MAIL FROM" identity by applying the check_host() function to the "MAIL FROM" identity as the . so the MAIL FROM entity contains postmaster@helo if the RFC5321.mailfrom is empty... Now in this document, it says to do the check_host on mail from and helo separately, it says the check_host function will return a result, and that result is deterministic, I see the code. However I reread quickly the spec, it does not say how you would merge both results to a single one: Did SPF passes or not? For instance, RFC7001 expects one result. http://tools.ietf.org/html/rfc7001#section-2.6.2 RFC7208 was written to make the text of the document more suitable for a "Standard" track. The charter was to not modify the protocol. So RFC7208 is not addressing this issue either. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On January 22, 2015 3:46:59 PM EST, Franck Martin wrote: > > > > >- Original Message - >> From: "Michael Jack Assels" >> To: dmarc@ietf.org >> Sent: Thursday, January 22, 2015 12:00:58 PM >> Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more >tiny nits, while I'm at it >> >> On Thu, 22 Jan 2015 12:48:03 CST, >> Franck Martin wrote: >> >> > - Original Message - >> > >> > > From: "Murray S. Kucherawy" >> > > To: dmarc@ietf.org >> > > Sent: Thursday, January 22, 2015 10:27:40 AM >> > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two >more >> > > tiny nits, while I'm at it >> > >> > > On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy < >> > > superu...@gmail.com > >> > > wrote: >> > >> > > > I am asking the IESG and the ISE what the process is for >> > > > making such adjustments now. >> > > >> > >> > > > Mainly my resistance to further change comes from the fact >> > > > that we've done last calls of varying kinds on this >> > > > document more times than I can count. It really is time to >> > > > put the non-IETF version to bed and hand it off, even with >> > > > its weaknesses, and let the standards process take it from >> > > > there. There's a working group already chartered to do >> > > > exactly that; in fact, that was one of the premises of >> > > > creating that working group. >> > > >> >> > > I've consulted with the Area Director sponsoring the >> > > document's conflict review, and the ISE. Both of them agree >> > > that we will only make changes approved by the ISE and only >> > > during AUTH48 at this point, and those will be limited to >> > > correcting serious problems that would prevent current DMARC >> > > implementations from interacting properly. Anything else can >> > > be left to the DMARC working group on its standards track >> > > deliverable. >> > >> > > An argument can be made that this proposed change qualifies >> > > under that definition, so please review it and comment as to >> > > whether it satisfies the defect identified, or whether the >> > > change is necessary at all. I will assume "yes" unless I hear >> > > otherwise. Again, the diff is here: >> > >> > > http://www.blackops.org/~msk/dmarc/diff.html >> > >> > Hold on... >> > >> > What is the decision matrix of SPF? >> > >> > SPF uses two strings, the RFC5321.mailfrom and the >> > RFC5321.helo. Each string may or may not have an SPF record. >> > What gives the spf status? >> >> As I read RFC7208, it doesn't explicitly provide a decision >> matrix, but it does clearly recommend in section 2.3, that >> [i]f a conclusive determination about the message can be made >> based on a check of "HELO", then the use of DNS resources to >> process the typically more complex "MAIL FROM" can be avoided." >> >> Section 2.4 provides that "SPF verifiers MUST check the >> [RFC5321.mailfrom] identity if a [RFC5321.helo] check either >> has not been performed or has not reached a definitive policy" >> >> I can't think of a way to read that that doesn't imply that >> a "pass" or a "fail" on the basis of an SPF record for the >> RFC5321.helo indentity (if such a record exists) is the spf >> result; otherwise, the result is based on the RFC5321.mailfrom >> identity. >> >> I believe that this is not what DMARC implementations actually >> do, and that the proposed change to the draft correctly points >> out the difference and makes it clear what DMARC does, so if >> I had a vote, I'd vote "yes" to the change. >> > >Ok, but a specific well known implementation does not seem to do that: >>From http://www.openspf.org/Implementations Mail::SPF has passed the >test suites > >http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm >"Note: In the case of an empty MAIL FROM SMTP transaction parameter >(MAIL FROM:<>), you should perform a check with the helo scope >instead." > >an RFC to reach standard status needs to represent what is out there, >I'd like to see more code before I form an opinion. Mail::SPF is a library that can be called by various applications. It's not an application which is where such logic would be implemented. You're quoting one library author's recommendations to application developers, not an actual implementation detail. Note:also not yet updated for RFC 7208. Also, DMARC isn't standards track. DMARC leverages the Mail From identity, so I don't see how independent HELO checks can be relevant. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On Thu, 22 Jan 2015 14:46:59 CST, Franck Martin wrote: > - Original Message - > > From: "Michael Jack Assels" > > To: dmarc@ietf.org > > Sent: Thursday, January 22, 2015 12:00:58 PM > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > > nits, while I'm at it > > > > On Thu, 22 Jan 2015 12:48:03 CST, > > Franck Martin wrote: > > > > > [] > > > > > > Hold on... > > > > > > What is the decision matrix of SPF? > > > > > > SPF uses two strings, the RFC5321.mailfrom and the > > > RFC5321.helo. Each string may or may not have an SPF record. > > > What gives the spf status? > > > > As I read RFC7208, it doesn't explicitly provide a decision > > matrix, but it does clearly recommend in section 2.3, that > > [i]f a conclusive determination about the message can be made > > based on a check of "HELO", then the use of DNS resources to > > process the typically more complex "MAIL FROM" can be avoided." > > > > Section 2.4 provides that "SPF verifiers MUST check the > > [RFC5321.mailfrom] identity if a [RFC5321.helo] check either > > has not been performed or has not reached a definitive policy" > > > > I can't think of a way to read that that doesn't imply that > > a "pass" or a "fail" on the basis of an SPF record for the > > RFC5321.helo indentity (if such a record exists) is the spf > > result; otherwise, the result is based on the RFC5321.mailfrom > > identity. > > > > I believe that this is not what DMARC implementations actually > > do, and that the proposed change to the draft correctly points > > out the difference and makes it clear what DMARC does, so if > > I had a vote, I'd vote "yes" to the change. > > > > Ok, but a specific well known implementation does not seem to > do that: From http://www.openspf.org/Implementations Mail::SPF > has passed the test suites > > http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm > "Note: In the case of an empty MAIL FROM SMTP transaction > parameter (MAIL FROM:<>), you should perform a check with the > helo scope instead." This is what the proposed change says, isn't it? > an RFC to reach standard status needs to represent what is out > there, I'd like to see more code before I form an opinion. I think we've crossed wires here. I unreservedly agree that RFC7208 does NOT represent what all DMARC implementations do, and it may not even represent what all SPF implementations do. Perhaps RFC7208 needs correction, but given what it says now, and given that DMARC has an obvious dependency on SPF, it's important that DMARC's standard should say "contrary to what RFC7208 recommends, DMARC normally SPF-checks HELO only when MAIL FROM is <>". I don't think we're disagreeing about what DMARC does, or even about what SPF usually does, despite what RFC7208 says. MJA ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
- Original Message - > From: "Michael Jack Assels" > To: dmarc@ietf.org > Sent: Thursday, January 22, 2015 12:00:58 PM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > nits, while I'm at it > > On Thu, 22 Jan 2015 12:48:03 CST, > Franck Martin wrote: > > > - Original Message - > > > > > From: "Murray S. Kucherawy" > > > To: dmarc@ietf.org > > > Sent: Thursday, January 22, 2015 10:27:40 AM > > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more > > > tiny nits, while I'm at it > > > > > On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy < > > > superu...@gmail.com > > > > wrote: > > > > > > I am asking the IESG and the ISE what the process is for > > > > making such adjustments now. > > > > > > > > > Mainly my resistance to further change comes from the fact > > > > that we've done last calls of varying kinds on this > > > > document more times than I can count. It really is time to > > > > put the non-IETF version to bed and hand it off, even with > > > > its weaknesses, and let the standards process take it from > > > > there. There's a working group already chartered to do > > > > exactly that; in fact, that was one of the premises of > > > > creating that working group. > > > > > > > I've consulted with the Area Director sponsoring the > > > document's conflict review, and the ISE. Both of them agree > > > that we will only make changes approved by the ISE and only > > > during AUTH48 at this point, and those will be limited to > > > correcting serious problems that would prevent current DMARC > > > implementations from interacting properly. Anything else can > > > be left to the DMARC working group on its standards track > > > deliverable. > > > > > An argument can be made that this proposed change qualifies > > > under that definition, so please review it and comment as to > > > whether it satisfies the defect identified, or whether the > > > change is necessary at all. I will assume "yes" unless I hear > > > otherwise. Again, the diff is here: > > > > > http://www.blackops.org/~msk/dmarc/diff.html > > > > Hold on... > > > > What is the decision matrix of SPF? > > > > SPF uses two strings, the RFC5321.mailfrom and the > > RFC5321.helo. Each string may or may not have an SPF record. > > What gives the spf status? > > As I read RFC7208, it doesn't explicitly provide a decision > matrix, but it does clearly recommend in section 2.3, that > [i]f a conclusive determination about the message can be made > based on a check of "HELO", then the use of DNS resources to > process the typically more complex "MAIL FROM" can be avoided." > > Section 2.4 provides that "SPF verifiers MUST check the > [RFC5321.mailfrom] identity if a [RFC5321.helo] check either > has not been performed or has not reached a definitive policy" > > I can't think of a way to read that that doesn't imply that > a "pass" or a "fail" on the basis of an SPF record for the > RFC5321.helo indentity (if such a record exists) is the spf > result; otherwise, the result is based on the RFC5321.mailfrom > identity. > > I believe that this is not what DMARC implementations actually > do, and that the proposed change to the draft correctly points > out the difference and makes it clear what DMARC does, so if > I had a vote, I'd vote "yes" to the change. > Ok, but a specific well known implementation does not seem to do that: >From http://www.openspf.org/Implementations Mail::SPF has passed the test >suites http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm "Note: In the case of an empty MAIL FROM SMTP transaction parameter (MAIL FROM:<>), you should perform a check with the helo scope instead." an RFC to reach standard status needs to represent what is out there, I'd like to see more code before I form an opinion. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
I’ve reviewed the diff between -12 and -13 and I’m comfortable with the changes. Mike From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, January 22, 2015 1:28 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy mailto:superu...@gmail.com>> wrote: I am asking the IESG and the ISE what the process is for making such adjustments now. Mainly my resistance to further change comes from the fact that we've done last calls of varying kinds on this document more times than I can count. It really is time to put the non-IETF version to bed and hand it off, even with its weaknesses, and let the standards process take it from there. There's a working group already chartered to do exactly that; in fact, that was one of the premises of creating that working group. I've consulted with the Area Director sponsoring the document's conflict review, and the ISE. Both of them agree that we will only make changes approved by the ISE and only during AUTH48 at this point, and those will be limited to correcting serious problems that would prevent current DMARC implementations from interacting properly. Anything else can be left to the DMARC working group on its standards track deliverable. An argument can be made that this proposed change qualifies under that definition, so please review it and comment as to whether it satisfies the defect identified, or whether the change is necessary at all. I will assume "yes" unless I hear otherwise. Again, the diff is here: http://www.blackops.org/~msk/dmarc/diff.html -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On Thu, 22 Jan 2015 12:48:03 CST, Franck Martin wrote: > - Original Message - > > > From: "Murray S. Kucherawy" > > To: dmarc@ietf.org > > Sent: Thursday, January 22, 2015 10:27:40 AM > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > > nits, while I'm at it > > > On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy < superu...@gmail.com > > > > > wrote: > > > > I am asking the IESG and the ISE what the process is for > > > making such adjustments now. > > > > > > Mainly my resistance to further change comes from the fact > > > that we've done last calls of varying kinds on this > > > document more times than I can count. It really is time to > > > put the non-IETF version to bed and hand it off, even with > > > its weaknesses, and let the standards process take it from > > > there. There's a working group already chartered to do > > > exactly that; in fact, that was one of the premises of > > > creating that working group. > > > > I've consulted with the Area Director sponsoring the > > document's conflict review, and the ISE. Both of them agree > > that we will only make changes approved by the ISE and only > > during AUTH48 at this point, and those will be limited to > > correcting serious problems that would prevent current DMARC > > implementations from interacting properly. Anything else can > > be left to the DMARC working group on its standards track > > deliverable. > > > An argument can be made that this proposed change qualifies > > under that definition, so please review it and comment as to > > whether it satisfies the defect identified, or whether the > > change is necessary at all. I will assume "yes" unless I hear > > otherwise. Again, the diff is here: > > > http://www.blackops.org/~msk/dmarc/diff.html > > Hold on... > > What is the decision matrix of SPF? > > SPF uses two strings, the RFC5321.mailfrom and the > RFC5321.helo. Each string may or may not have an SPF record. > What gives the spf status? As I read RFC7208, it doesn't explicitly provide a decision matrix, but it does clearly recommend in section 2.3, that [i]f a conclusive determination about the message can be made based on a check of "HELO", then the use of DNS resources to process the typically more complex "MAIL FROM" can be avoided." Section 2.4 provides that "SPF verifiers MUST check the [RFC5321.mailfrom] identity if a [RFC5321.helo] check either has not been performed or has not reached a definitive policy" I can't think of a way to read that that doesn't imply that a "pass" or a "fail" on the basis of an SPF record for the RFC5321.helo indentity (if such a record exists) is the spf result; otherwise, the result is based on the RFC5321.mailfrom identity. I believe that this is not what DMARC implementations actually do, and that the proposed change to the draft correctly points out the difference and makes it clear what DMARC does, so if I had a vote, I'd vote "yes" to the change. MJA ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
- Original Message - > From: "Murray S. Kucherawy" > To: dmarc@ietf.org > Sent: Thursday, January 22, 2015 10:27:40 AM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > nits, while I'm at it > On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy < superu...@gmail.com > > wrote: > > I am asking the IESG and the ISE what the process is for making such > > adjustments now. > > > Mainly my resistance to further change comes from the fact that we've done > > last calls of varying kinds on this document more times than I can count. > > It > > really is time to put the non-IETF version to bed and hand it off, even > > with > > its weaknesses, and let the standards process take it from there. There's a > > working group already chartered to do exactly that; in fact, that was one > > of > > the premises of creating that working group. > > I've consulted with the Area Director sponsoring the document's conflict > review, and the ISE. Both of them agree that we will only make changes > approved by the ISE and only during AUTH48 at this point, and those will be > limited to correcting serious problems that would prevent current DMARC > implementations from interacting properly. Anything else can be left to the > DMARC working group on its standards track deliverable. > An argument can be made that this proposed change qualifies under that > definition, so please review it and comment as to whether it satisfies the > defect identified, or whether the change is necessary at all. I will assume > "yes" unless I hear otherwise. Again, the diff is here: > http://www.blackops.org/~msk/dmarc/diff.html Hold on... What is the decision matrix of SPF? SPF uses two strings, the RFC5321.mailfrom and the RFC5321.helo. Each string may or may not have an SPF record. What gives the spf status? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy wrote: > I am asking the IESG and the ISE what the process is for making such > adjustments now. > > Mainly my resistance to further change comes from the fact that we've done > last calls of varying kinds on this document more times than I can count. > It really is time to put the non-IETF version to bed and hand it off, even > with its weaknesses, and let the standards process take it from there. > There's a working group already chartered to do exactly that; in fact, that > was one of the premises of creating that working group. > I've consulted with the Area Director sponsoring the document's conflict review, and the ISE. Both of them agree that we will only make changes approved by the ISE and only during AUTH48 at this point, and those will be limited to correcting serious problems that would prevent current DMARC implementations from interacting properly. Anything else can be left to the DMARC working group on its standards track deliverable. An argument can be made that this proposed change qualifies under that definition, so please review it and comment as to whether it satisfies the defect identified, or whether the change is necessary at all. I will assume "yes" unless I hear otherwise. Again, the diff is here: http://www.blackops.org/~msk/dmarc/diff.html -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On Wed, Jan 21, 2015 at 11:18 AM, John R Levine wrote: > I was under the impression that the reason this version's going through > the ISE is that the DMARC group isn't willing to hand change control to the > IETF. If they are willing, it makes no sense to do it outside of a WG. > It's a little late to re-hash the path by which we got here now, I think, and it was a rancorous debate. The agreement we have with the IESG is to do it via the path we're now on. Likewise, I was under the impression that publishing something through the ISE is deliberately restricted to Informational status specifically because what the document specifies might have flaws as it hasn't been subjected to any kind of IETF Review. I would agree with you if it were on the Standards Track, but it isn't. The idea of a process for ensuring that all implementations are based on -12 (or -13) and thus any two versions of the code do the same thing sounds dreadfully open-ended. I'd really like to have the goal posts sit still for a while. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
It really is time to put the non-IETF version to bed and hand it off, even with its weaknesses, and let the standards process take it from there. There's a working group already chartered to do exactly that; in fact, that was one of the premises of creating that working group. I was under the impression that the reason this version's going through the ISE is that the DMARC group isn't willing to hand change control to the IETF. If they are willing, it makes no sense to do it outside of a WG. I sympathize with your concern about the length of the process, and the lack of timely review, but DMARC is unusually complex for a mail thing, the implementations have all been from different drafts (did anyone ever do reporting by http?) and it's not surprising that there are still places where the code doesn't match the text, or two versions of code do different things. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
On Tue, Jan 20, 2015 at 6:14 PM, John Levine wrote: > >Do people concur with this change, or something close to it? > > I'm OK with it, but to the meta-question, I realize the practical > issues involved with yanking something out of the production queue, > but in this case I wonder if that's not the right thing to do. > > There's no great hurry in getting the DMARC document published, since > nothing currently depends on it, and if reasonable people are finding > holes in it that make it hard to write interoperable code, I'd rather > fix the holes than add lengthy errata or recycle later. > I am asking the IESG and the ISE what the process is for making such adjustments now. Mainly my resistance to further change comes from the fact that we've done last calls of varying kinds on this document more times than I can count. It really is time to put the non-IETF version to bed and hand it off, even with its weaknesses, and let the standards process take it from there. There's a working group already chartered to do exactly that; in fact, that was one of the premises of creating that working group. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
John Levine writes: > There's no great hurry in getting the DMARC document published, since > nothing currently depends on it, and if reasonable people are finding > holes in it that make it hard to write interoperable code, I'd rather > fix the holes than add lengthy errata or recycle later. *If* the existing code bases are interoperable, then it makes sense to postpone publication to fix the spec to conform to actual practice (which is its purpose, after all). Is it worth the effort/editor time to compose and discuss better language and the calendar time to wait for confirmation from implementors? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it
>Do people concur with this change, or something close to it? I'm OK with it, but to the meta-question, I realize the practical issues involved with yanking something out of the production queue, but in this case I wonder if that's not the right thing to do. There's no great hurry in getting the DMARC document published, since nothing currently depends on it, and if reasonable people are finding holes in it that make it hard to write interoperable code, I'd rather fix the holes than add lengthy errata or recycle later. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
