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