Re: [dmarc-ietf] Jim Fenton's review of -04
On 12/23/2014 10:11 PM, Murray S. Kucherawy wrote: -08 text says: If the RFC5322.From domain does not exist in the DNS, Mail Receivers SHOULD direct the receiving SMTP server to reject the message. The choice of mechanism for such rejection and the implications of those choices are discussed in Section 9.3. I suggest removing it. Although a common anti-abuse mechanism, it's out of scope for DMARC. I disagree. DMARC operators all seem to apply this practice, so it's correct to say that if you play this game, you reject mail from non-existent domains. Essentially in this way DMARC is a profile of RFC5321/RFC5322, which is perfectly acceptable. We are not updating those standards here, merely profiling them. The fact that its use happens to correlate with DMARC use is a distraction. For example, there are plenty of operators who use apply this check but do not use DMARC. If the test is documented in a specification, it should be in /one/ specification. Putting it into the DMARC spec means it has to be documented somewhere else, for the folk who don't use DMARC. Broadly, there are all sorts of things that DMARC operators commonly do, but that are not appropriate to document in the DMARC specification. DMARC concerns the domain name in the From: field and finding that it has a DMARC record associated with it. If there is no record associated with the domain name, then it is not participating in DMARC. There are other places to document other, common anti-abuse practices. The check for an MX is completely out of scope for the DMARC spec. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On Wed, Dec 24, 2014 at 4:09 AM, Scott Kitterman skl...@kitterman.com wrote: 5.6.2 promises 5.6.3 addresses the question and it doesn't. At the very least, 5.6.2 should be fixed not to over promise what 5.6.3 will provide. I'm not clear why you say it doesn't. 5.6.3 describes two options for handling a message when the query for the DMARC policy fails due to transient DNS errors. Is your issue that it doesn't prescribe one specific action? I also don't understand why you say the reference is dangling. 5.6.2 says that transient DNS errors for SPF and DKIM can occur and says the handling for that case is left to receiver discretion, but also points out that what 5.6.3 says can also be applied when that happens. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman skl...@kitterman.com wrote: The draft strongly encourages DMARC implementers to ignore SPF policy, so I don't think assuming messages will be deferred due only due to SPF or DKIM results indicating a temporary DNS error is appropriate. If there's a transient DNS error getting the SPF policy, then there's no SPF policy to be ignored. That's quite a different situation. I think that in the case of a temporary DNS error in one of the lower level protocols, insufficient inputs are available to conclude a message has failed DMARC tests. I agree. Receivers can either ignore DMARC for this message due to incomplete evaluation or they can defer the message in the hope that the temporary error will be resolved when the message is retried. Receivers MUST NOT apply DMARC policy and reject or quarantine because the DMARC evaluation is incomplete. Can you provide specific changes, with section numbers, that you'd like to see applied to resolve this? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On Wed, Dec 24, 2014 at 10:22 AM, Dave Crocker d...@dcrocker.net wrote: I disagree. DMARC operators all seem to apply this practice, so it's correct to say that if you play this game, you reject mail from non-existent domains. Essentially in this way DMARC is a profile of RFC5321/RFC5322, which is perfectly acceptable. We are not updating those standards here, merely profiling them. The fact that its use happens to correlate with DMARC use is a distraction. For example, there are plenty of operators who use apply this check but do not use DMARC. If the test is documented in a specification, it should be in /one/ specification. Putting it into the DMARC spec means it has to be documented somewhere else, for the folk who don't use DMARC. This paragraph appears in the DMARC spec because the operators participating all agreed that it should be part-and-parcel of this operating profile of email. It's not as happenstance as this sounds so far; the very thrust of DMARC is to make the From: content believable, and permitting a nonexistent domain name to make it to the inbox contradicts that goal. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
- Original Message - From: Murray S. Kucherawy superu...@gmail.com To: Dave Crocker dcroc...@bbiw.net Cc: dmarc@ietf.org Sent: Wednesday, December 24, 2014 7:50:16 AM Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 On Wed, Dec 24, 2014 at 10:22 AM, Dave Crocker d...@dcrocker.net wrote: I disagree. DMARC operators all seem to apply this practice, so it's correct to say that if you play this game, you reject mail from non-existent domains. Essentially in this way DMARC is a profile of RFC5321/RFC5322, which is perfectly acceptable. We are not updating those standards here, merely profiling them. The fact that its use happens to correlate with DMARC use is a distraction. For example, there are plenty of operators who use apply this check but do not use DMARC. If the test is documented in a specification, it should be in /one/ specification. Putting it into the DMARC spec means it has to be documented somewhere else, for the folk who don't use DMARC. This paragraph appears in the DMARC spec because the operators participating all agreed that it should be part-and-parcel of this operating profile of email. It's not as happenstance as this sounds so far; the very thrust of DMARC is to make the From: content believable, and permitting a nonexistent domain name to make it to the inbox contradicts that goal. All of this I feel strongly is part of security considerations, even if they may be not in that chapter. What is the use of doing DMARC, if you allow weak input and vulnerabilities? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On 12/24/2014 7:50 AM, Murray S. Kucherawy wrote: This paragraph appears in the DMARC spec because the operators participating all agreed that it should be part-and-parcel of this operating profile of email. It's not as happenstance as this sounds so far; the very thrust of DMARC is to make the From: content believable, and permitting a nonexistent domain name to make it to the inbox contradicts that goal. The goal, as you state it, is at the level of seeking world peace. It is very laudable and and very, very broad. It covers vastly more than the scope of DMARC. DMARC is a specific bit of technology working towards that broader goal. That something happens to fall within this very broad scope does not automatically justify documenting it within the much narrower scope of a detailed specification, unless it is part of that specification's technology. The MX record check has no /technical/ relationship to the /technical/ details of DMARC. Please note that I'm not commenting on the efficacy of the record check, but on the need to document it in a place that makes sense for the full range of its implementers. There are, and will continue to be, plenty of operators using that check but not DMARC. That simple fact provides a very pragmatic reason for moving its specification into some document outside of DMARC. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On Wednesday, December 24, 2014 10:46:42 Murray S. Kucherawy wrote: On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman skl...@kitterman.com wrote: The draft strongly encourages DMARC implementers to ignore SPF policy, so I don't think assuming messages will be deferred due only due to SPF or DKIM results indicating a temporary DNS error is appropriate. If there's a transient DNS error getting the SPF policy, then there's no SPF policy to be ignored. That's quite a different situation. I think that in the case of a temporary DNS error in one of the lower level protocols, insufficient inputs are available to conclude a message has failed DMARC tests. I agree. Receivers can either ignore DMARC for this message due to incomplete evaluation or they can defer the message in the hope that the temporary error will be resolved when the message is retried. Receivers MUST NOT apply DMARC policy and reject or quarantine because the DMARC evaluation is incomplete. Can you provide specific changes, with section numbers, that you'd like to see applied to resolve this? Yes, but I just finished a 20 hour drive, so I'll probably sleep first. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On December 24, 2014 9:43:40 AM CST, Murray S. Kucherawy superu...@gmail.com wrote: On Wed, Dec 24, 2014 at 4:09 AM, Scott Kitterman skl...@kitterman.com wrote: 5.6.2 promises 5.6.3 addresses the question and it doesn't. At the very least, 5.6.2 should be fixed not to over promise what 5.6.3 will provide. I'm not clear why you say it doesn't. 5.6.3 describes two options for handling a message when the query for the DMARC policy fails due to transient DNS errors. Is your issue that it doesn't prescribe one specific action? I also don't understand why you say the reference is dangling. 5.6.2 says that transient DNS errors for SPF and DKIM can occur and says the handling for that case is left to receiver discretion, but also points out that what 5.6.3 says can also be applied when that happens. And 5.6.3 is completely silent on what to do with SPF or DKIM results indicating a temporary DNS error. The only references to transient DNS errors in 5.6.3 are specific to errors retrieving DMARC records. Scott K Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
- Original Message - From: Scott Kitterman skl...@kitterman.com To: dmarc@ietf.org Sent: Wednesday, December 24, 2014 2:48:17 PM Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 On Wednesday, December 24, 2014 10:46:42 Murray S. Kucherawy wrote: On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman skl...@kitterman.com wrote: The draft strongly encourages DMARC implementers to ignore SPF policy, so I don't think assuming messages will be deferred due only due to SPF or DKIM results indicating a temporary DNS error is appropriate. If there's a transient DNS error getting the SPF policy, then there's no SPF policy to be ignored. That's quite a different situation. I think that in the case of a temporary DNS error in one of the lower level protocols, insufficient inputs are available to conclude a message has failed DMARC tests. I agree. Receivers can either ignore DMARC for this message due to incomplete evaluation or they can defer the message in the hope that the temporary error will be resolved when the message is retried. Receivers MUST NOT apply DMARC policy and reject or quarantine because the DMARC evaluation is incomplete. Can you provide specific changes, with section numbers, that you'd like to see applied to resolve this? Here's my suggestion. Replace this text at the end of section 5.6.2: Handling of messages for which SPF and/or DKIM evaluation encounters a DNS error is left to the discretion of the Mail Receiver. Further discussion is available in Section 5.6.3. with: Messages for which SPF and/or DKIM evaluation encounters a temporary DNS error have not received a definitive result for steps 3 and/or 4 above. If the message has not passed the the DMARC mechanism check due to an SPF or DKIM check that did not have a DNS error, receivers can either ignore DMARC for this message due to incomplete evaluation or they can defer the message in the hope that the temporary error will be resolved when the message is retried. Receivers MUST NOT apply DMARC policy and reject or quarantine the message because the DMARC evaluation is incomplete. When otherwise appropriate due to DMARC policy, receivers MAY send feedback reports regarding temporary errors. Handling of messages for which SPF and/or DKIM evaluation encounters a permanent DNS error is left to the discretion of the Mail Receiver. How's that? What about pointing it may be a security issue to let these messages through? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On Wed, Dec 24, 2014 at 5:48 PM, Scott Kitterman skl...@kitterman.com wrote: Messages for which SPF and/or DKIM evaluation encounters a temporary DNS error have not received a definitive result for steps 3 and/or 4 above. If the message has not passed the the DMARC mechanism check due to an SPF or DKIM check that did not have a DNS error, receivers can either ignore DMARC for this message due to incomplete evaluation or they can defer the message in the hope that the temporary error will be resolved when the message is retried. Receivers MUST NOT apply DMARC policy and reject or quarantine the message because the DMARC evaluation is incomplete. When otherwise appropriate due to DMARC policy, receivers MAY send feedback reports regarding temporary errors. Handling of messages for which SPF and/or DKIM evaluation encounters a permanent DNS error is left to the discretion of the Mail Receiver. How's that? I think it pretty much says what's there, but is a lot more clear about it. I also think the second sentence is a bit convoluted, so I reworked it into this. Does it match what you're trying to say? t Messages for which SPF and/or DKIM evaluation encounters a temporary DNS error have not received a definitive result for steps 3 and/or 4 above. When such an evaluation is done in conjunction with an aligned identifier, completion of the DMARC algorithm is not possible. In this case, receivers can either skip DMARC for this message due to incomplete evaluation, or they can arrange to defer handling of the message in the hope that the temporary error will be resolved when the message is retried. In any case, Receivers cannot apply DMARC policy and reject or quarantine the message because the DMARC evaluation is incomplete. When otherwise appropriate due to DMARC policy, receivers MAY send feedback reports regarding temporary errors. /t -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On Wed, Dec 24, 2014 at 11:23 AM, Dave Crocker d...@dcrocker.net wrote: The goal, as you state it, is at the level of seeking world peace. It is very laudable and and very, very broad. It covers vastly more than the scope of DMARC. DMARC is a specific bit of technology working towards that broader goal. That something happens to fall within this very broad scope does not automatically justify documenting it within the much narrower scope of a detailed specification, unless it is part of that specification's technology. The MX record check has no /technical/ relationship to the /technical/ details of DMARC. Please note that I'm not commenting on the efficacy of the record check, but on the need to document it in a place that makes sense for the full range of its implementers. There are, and will continue to be, plenty of operators using that check but not DMARC. That simple fact provides a very pragmatic reason for moving its specification into some document outside of DMARC. I'm surprised we're not hearing more passionate voices in favor of keeping it given the genesis of the paragraph we're discussing. At any rate, I'm going to take it out in -09, because I just discovered that it's actually directly contradicting what Appendix A.4 says. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
What about pointing it may be a security issue to let these messages through? Only if we also point out that it may be a security issue not to let them through. Seasons xmas, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On Thursday, December 25, 2014 00:02:41 Murray S. Kucherawy wrote: On Wed, Dec 24, 2014 at 5:48 PM, Scott Kitterman skl...@kitterman.com wrote: Messages for which SPF and/or DKIM evaluation encounters a temporary DNS error have not received a definitive result for steps 3 and/or 4 above. If the message has not passed the the DMARC mechanism check due to an SPF or DKIM check that did not have a DNS error, receivers can either ignore DMARC for this message due to incomplete evaluation or they can defer the message in the hope that the temporary error will be resolved when the message is retried. Receivers MUST NOT apply DMARC policy and reject or quarantine the message because the DMARC evaluation is incomplete. When otherwise appropriate due to DMARC policy, receivers MAY send feedback reports regarding temporary errors. Handling of messages for which SPF and/or DKIM evaluation encounters a permanent DNS error is left to the discretion of the Mail Receiver. How's that? I think it pretty much says what's there, but is a lot more clear about it. I also think the second sentence is a bit convoluted, so I reworked it into this. Does it match what you're trying to say? t Messages for which SPF and/or DKIM evaluation encounters a temporary DNS error have not received a definitive result for steps 3 and/or 4 above. When such an evaluation is done in conjunction with an aligned identifier, completion of the DMARC algorithm is not possible. In this case, receivers can either skip DMARC for this message due to incomplete evaluation, or they can arrange to defer handling of the message in the hope that the temporary error will be resolved when the message is retried. In any case, Receivers cannot apply DMARC policy and reject or quarantine the message because the DMARC evaluation is incomplete. When otherwise appropriate due to DMARC policy, receivers MAY send feedback reports regarding temporary errors. /t -MSK I don't think it does. What I was trying to say is that if you already got an aligned pass from one method, you're done. It doesn't matter if they other one gets a DNS error, you already have a definitive result. I don't think your text says that, but I may be wrong. Also, I don't like the change from MUST NOT to cannot. Receivers can do whatever they want, so cannot isn't correct. This bit is meant to say that receivers aren't free to use DMARC as an excuse to throw away messages every time there's a DNS hiccup. Applying policy in an inappropriate way does have an interoperability impact (messages quarantined/rejected that should not be), so I think the MUST NOT is appropriate. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
