Re: [dmarc-ietf] SPFAuthResultType unbounded
Yes, it does matter. Because one very large DMARC reporter has read this item in the specification's XML, and actually *is* providing far more than 2 SPF results per record object. I've counted 312 blocks in one instance. I'm not clear on the logic behind that, perhaps it's an aggregation level. But I don't grok it, and I want to either understand how it makes sense, or fix the spec to be entirely clear. On 3/15/16 16:10, Franck Martin wrote: *From: *"Tomki" *To: *"dmarc" *Sent: *Tuesday, March 15, 2016 3:27:15 PM *Subject: *[dmarc-ietf] SPFAuthResultType unbounded Does it make sense that SPFAuthResultType element counts are allowed to be unbounded? I would think that it should be a maximum of 2, and then only if the scope is indicated (helo/mfrom) fromhttps://tools.ietf.org/html/rfc7489 Makes sense, does it matter? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt
It also cuts down on legitimate mail that users get sent. Probably 90% of the email I send fails DMARC even though I have SPF set up and DKIM sign everything because it tends to go via lists that have not adapted to the world of DMARC. I did publish a p=None DMARC record, so presumably I don't personally need to care about this, but typically small senders don't pay a huge amount of attention to things like new email authentication technologies. Based on your blog post, I see you're only using this for positive assertions. That's something which, as a receiver, I think you are certainly free to do, but it's not something that should be standardized. Since it's strictly an internal processing issue, there's no need to put this in an RFC and lots of reason not to. Scott K On Tuesday, March 15, 2016 08:04:52 PM Terry Zink wrote: > +1 to virtual DMARC, -1 to the arguments against it. > > Office 365 already supports something like this for our customers to cut > down on Business Email Compromise. Maybe 5% of our customers have DMARC > records, yet we treat all inbound email destined to them as having > p=quarantine and then we figure out roughly who is allowed to send email as > them even when (especially when) they don't authenticate. I talk about this > here: http://aka.ms/AntispoofingInOffice365. > > We've been doing DMARC lookups on the header.from and stamping the result > for a while now, and if it doesn't publish DMARC but would have passed if > it did, we stamp the result and call it "Best Guess Pass". However, we use > relaxed alignment, not strict. I talk about this here: > http://blogs.msdn.com/b/tzink/archive/2015/05/06/what-is-dmarc-bestguesspas > s-in-office-365.aspx > > Figuring out implicit/virtual DMARC for everyone else is a much bigger body > of water to boil, but is roughly the same problem. As a large receiver we > have overrides for DMARC failures anyway, so implicit/virtual DMARC would > have those same overrides. > > Firstly, DMARC is an opt-in protocol for good reason. > > I'm saying this tongue-in-cheek, but that "good reason" is "very limited > deployment in practice." If we would have waited for customers to publish > DMARC records we'd be at 6% adoption rate. > > In your first phase, p=none, this will have no effect. In your middle > > phase, p=quarantine, this will cause massive loss of wanted email ... In > > your final phase, p=reject, there will continue to be massive loss of > > wanted email. > If large email receivers start junking messages because of implicit/virtual > DMARC failures, senders figure it out eventually even without DMARC > reporting. There's more tools in our toolbox than just junking. For > example, we can add visual warnings to the message. We can choose not to > extract/promote content if the header.from doesn't align with the SPF/DKIM > domain (i.e., an airline sends a flight confirmation and that info is not > shown to the user in a rich manner). We can add throttling limits. And so > forth. > > -- Terry > > -Original Message- > From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Steve Atkins > Sent: Tuesday, March 15, 2016 5:33 AM > To: dmarc > Subject: Re: [dmarc-ietf] I-D Action: > draft-akagiri-dmarc-virtual-verification-00.txt > > On Mar 14, 2016, at 11:28 PM, Kouji Okada wrote: > > > > We have submitted a draft about DMARC default verification > > for domains not publishing DMARC records. > > Any comments will be appreciated. > > Summary: If a domain does not opt-in to using DMARC, treat the domain > as though it had opted-in to using DMARC with "p=none adkim=s aspf=s". > Once that's deployed, change it to "p=reject adkim=s aspf=s". Possibly > do "p=quarantine" between the two. > > There are multiple problems with this suggestion. > > Firstly, DMARC is an opt-in protocol for good reason. It's a lot of work to > clean up all the mail streams for a domain such that all email is > authenticated. In many cases it is impossible to do so. Those domains that > have not done so should not publish a DMARC record. > > Requiring DMARC-esque authentication (let alone strict alignment) from > domains that are not ready to use DMARC will cause a lot of wanted email to > be treated as having failed that test. > > In your first phase, p=none, this will have no effect. The value of using > p=none in DMARC is so that domains can take advantage of DMARC reporting > without loss of legitimate email. You have no reporting, so this provides > no value. > > In your middle phase, p=quarantine, this will cause massive loss of wanted > email while still providing no feedback to senders. > > In your final phase, p=reject, there will continue to be massive loss of > wanted email. > > In none of those phases does your draft add any value. If a receiver wants > to pay attention to whether mail is authenticated or not it can already do > so, and it can do so much more effectively than any approach that requires > strict DMARC style ali
Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt
On Tuesday, March 15, 2016 04:06:42 PM Franck Martin wrote: > - Original Message - > > > From: "Terry Zink" > > To: "dmarc" > > Sent: Tuesday, March 15, 2016 1:04:52 PM > > Subject: Re: [dmarc-ietf] I-D Action: > > draft-akagiri-dmarc-virtual-verification-00.txt > > > > +1 to virtual DMARC, -1 to the arguments against it. > > > > Office 365 already supports something like this for our customers to cut > > down on Business Email Compromise. Maybe 5% of our customers have DMARC > > records, yet we treat all inbound email destined to them as having > > p=quarantine and then we figure out roughly who is allowed to send email > > as them even when (especially when) they don't authenticate. I talk about > > this here: http://aka.ms/AntispoofingInOffice365. > > > > We've been doing DMARC lookups on the header.from and stamping the result > > for a while now, and if it doesn't publish DMARC but would have passed if > > it did, we stamp the result and call it "Best Guess Pass". However, we > > use relaxed alignment, not strict. I talk about this here: > > http://blogs.msdn.com/b/tzink/archive/2015/05/06/what-is-dmarc-bestguesspa > > ss-in-office-365.aspx > > > > Figuring out implicit/virtual DMARC for everyone else is a much bigger > > body > > of water to boil, but is roughly the same problem. As a large receiver we > > have overrides for DMARC failures anyway, so implicit/virtual DMARC would > > have those same overrides. > > > > > Firstly, DMARC is an opt-in protocol for good reason. > > > > I'm saying this tongue-in-cheek, but that "good reason" is "very limited > > deployment in practice." If we would have waited for customers to publish > > DMARC records we'd be at 6% adoption rate. > > > > > In your first phase, p=none, this will have no effect. In your middle > > > phase, > > > p=quarantine, this will cause massive loss of wanted email ... In your > > > final phase, p=reject, there will continue to be massive loss of wanted > > > email. > > > > If large email receivers start junking messages because of > > implicit/virtual > > DMARC failures, senders figure it out eventually even without DMARC > > reporting. There's more tools in our toolbox than just junking. For > > example, we can add visual warnings to the message. We can choose not to > > extract/promote content if the header.from doesn't align with the SPF/DKIM > > domain (i.e., an airline sends a flight confirmation and that info is not > > shown to the user in a rich manner). We can add throttling limits. And so > > forth. > > Yes, it may not be cool to call it Virtual DMARC, but basically it is > applying the DMARC logic, to pass information to other layers. > > Google has been doing virtual SPF (aka best guess SPF) for a while. The name > is confusing, and mixing the results of two systems may produce > non-comparable metrics. > > I think the point, is that several of us have been doing this for quite a > while and this has been useful in our own internal networks, I'm not sure > it needs to be formalized to the rest of Internet, except may be under > informational status or under a (B)CP. SPF Best Guess is a horrible idea that should never have been invented and should die as soon as possible. http://www.openspf.org/FAQ/Best_guess_record SPF (and DMARC) are opt-in protocols. Trying to infer DMARC like things about non-participants in DMARC is just wrong. It is not an accident that SPF Best Guess apperas nowhere in RFC 4408 nor RFC 7208. It shouldn't be a model for anything. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] SPFAuthResultType unbounded
- Original Message - > From: "Tomki" > To: "dmarc" > Sent: Tuesday, March 15, 2016 3:27:15 PM > Subject: [dmarc-ietf] SPFAuthResultType unbounded > Does it make sense that SPFAuthResultType element counts are allowed to be > unbounded? > I would think that it should be a maximum of 2, and then only if the scope is > indicated (helo/mfrom) > from https://tools.ietf.org/html/rfc7489 name="AuthResultType"> > > > minOccurs="0" maxOccurs="unbounded"/> > > maxOccurs="unbounded"/> > > Makes sense, does it matter? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt
- Original Message - > From: "Rolf E. Sonneveld" > To: "Franck Martin" , "Terry Zink" > > Cc: "dmarc" > Sent: Tuesday, March 15, 2016 3:10:36 PM > Subject: Re: [dmarc-ietf] I-D Action: > draft-akagiri-dmarc-virtual-verification-00.txt > On 15-03-16 22:06, Franck Martin wrote: > the fact that a number of big receivers already deploy similar techniques > doesn't mean this draft is a good idea: > * big receivers do have the resources to maintain and extend a rich toolbox > to 'balance' the results of a DMARC analysis. There are however huge numbers > of small to medium receivers who do not have this tooling and for whom a > virtual/best guess DMARC 'mechanism' might remove the nuances there can be > in the outcome of a spam analysis of real world mail; > * suppose this draft would evolve into a BCP or Informational RFC, who will > decide when to move from p=none to p=quarantine and from p=quarantine to > p=reject, and on what criteria would such a decision be based? > * like Kurt already said, associating this with the name of 'DMARC' doesn't > sound the right thing to do. 1) Small receivers use community toolboxes, like spamassassin, I don't see where is the problem. Even, often, big receivers contribute to community toolboxes... 2) you are confusing applying a policy and getting an authentication flag for other layers 3) yes, I'm not keen either to call it DMARCX to avoid confusion, but DMARC is just a block and anyone can add other blocks to this construction. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] SPFAuthResultType unbounded
Does it make sense that SPFAuthResultType element counts are allowed to be unbounded? I would think that it should be a maximum of 2, and then only if the scope is indicated (helo/mfrom) from https://tools.ietf.org/html/rfc7489 --Tomki -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt
On 15-03-16 22:06, Franck Martin wrote: - Original Message - From: "Terry Zink" To: "dmarc" Sent: Tuesday, March 15, 2016 1:04:52 PM Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt +1 to virtual DMARC, -1 to the arguments against it. Office 365 already supports something like this for our customers to cut down on Business Email Compromise. Maybe 5% of our customers have DMARC records, yet we treat all inbound email destined to them as having p=quarantine and then we figure out roughly who is allowed to send email as them even when (especially when) they don't authenticate. I talk about this here: http://aka.ms/AntispoofingInOffice365. We've been doing DMARC lookups on the header.from and stamping the result for a while now, and if it doesn't publish DMARC but would have passed if it did, we stamp the result and call it "Best Guess Pass". However, we use relaxed alignment, not strict. I talk about this here: http://blogs.msdn.com/b/tzink/archive/2015/05/06/what-is-dmarc-bestguesspass-in-office-365.aspx Figuring out implicit/virtual DMARC for everyone else is a much bigger body of water to boil, but is roughly the same problem. As a large receiver we have overrides for DMARC failures anyway, so implicit/virtual DMARC would have those same overrides. Firstly, DMARC is an opt-in protocol for good reason. I'm saying this tongue-in-cheek, but that "good reason" is "very limited deployment in practice." If we would have waited for customers to publish DMARC records we'd be at 6% adoption rate. In your first phase, p=none, this will have no effect. In your middle phase, p=quarantine, this will cause massive loss of wanted email ... In your final phase, p=reject, there will continue to be massive loss of wanted email. If large email receivers start junking messages because of implicit/virtual DMARC failures, senders figure it out eventually even without DMARC reporting. There's more tools in our toolbox than just junking. For example, we can add visual warnings to the message. We can choose not to extract/promote content if the header.from doesn't align with the SPF/DKIM domain (i.e., an airline sends a flight confirmation and that info is not shown to the user in a rich manner). We can add throttling limits. And so forth. Yes, it may not be cool to call it Virtual DMARC, but basically it is applying the DMARC logic, to pass information to other layers. Google has been doing virtual SPF (aka best guess SPF) for a while. The name is confusing, and mixing the results of two systems may produce non-comparable metrics. I think the point, is that several of us have been doing this for quite a while and this has been useful in our own internal networks, I'm not sure it needs to be formalized to the rest of Internet, except may be under informational status or under a (B)CP. the fact that a number of big receivers already deploy similar techniques doesn't mean this draft is a good idea: * big receivers do have the resources to maintain and extend a rich toolbox to 'balance' the results of a DMARC analysis. There are however huge numbers of small to medium receivers who do not have this tooling and for whom a virtual/best guess DMARC 'mechanism' might remove the nuances there can be in the outcome of a spam analysis of real world mail; * suppose this draft would evolve into a BCP or Informational RFC, who will decide when to move from p=none to p=quarantine and from p=quarantine to p=reject, and on what criteria would such a decision be based? * like Kurt already said, associating this with the name of 'DMARC' doesn't sound the right thing to do. /rolf ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt
- Original Message - > From: "Terry Zink" > To: "dmarc" > Sent: Tuesday, March 15, 2016 1:04:52 PM > Subject: Re: [dmarc-ietf] I-D Action: > draft-akagiri-dmarc-virtual-verification-00.txt > > +1 to virtual DMARC, -1 to the arguments against it. > > Office 365 already supports something like this for our customers to cut down > on Business Email Compromise. Maybe 5% of our customers have DMARC records, > yet we treat all inbound email destined to them as having p=quarantine and > then we figure out roughly who is allowed to send email as them even when > (especially when) they don't authenticate. I talk about this here: > http://aka.ms/AntispoofingInOffice365. > > We've been doing DMARC lookups on the header.from and stamping the result for > a while now, and if it doesn't publish DMARC but would have passed if it > did, we stamp the result and call it "Best Guess Pass". However, we use > relaxed alignment, not strict. I talk about this here: > http://blogs.msdn.com/b/tzink/archive/2015/05/06/what-is-dmarc-bestguesspass-in-office-365.aspx > > Figuring out implicit/virtual DMARC for everyone else is a much bigger body > of water to boil, but is roughly the same problem. As a large receiver we > have overrides for DMARC failures anyway, so implicit/virtual DMARC would > have those same overrides. > > > Firstly, DMARC is an opt-in protocol for good reason. > > I'm saying this tongue-in-cheek, but that "good reason" is "very limited > deployment in practice." If we would have waited for customers to publish > DMARC records we'd be at 6% adoption rate. > > > In your first phase, p=none, this will have no effect. In your middle > > phase, > > p=quarantine, this will cause massive loss of wanted email ... In your > > final phase, p=reject, there will continue to be massive loss of wanted > > email. > > If large email receivers start junking messages because of implicit/virtual > DMARC failures, senders figure it out eventually even without DMARC > reporting. There's more tools in our toolbox than just junking. For example, > we can add visual warnings to the message. We can choose not to > extract/promote content if the header.from doesn't align with the SPF/DKIM > domain (i.e., an airline sends a flight confirmation and that info is not > shown to the user in a rich manner). We can add throttling limits. And so > forth. > Yes, it may not be cool to call it Virtual DMARC, but basically it is applying the DMARC logic, to pass information to other layers. Google has been doing virtual SPF (aka best guess SPF) for a while. The name is confusing, and mixing the results of two systems may produce non-comparable metrics. I think the point, is that several of us have been doing this for quite a while and this has been useful in our own internal networks, I'm not sure it needs to be formalized to the rest of Internet, except may be under informational status or under a (B)CP. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt
+1 to virtual DMARC, -1 to the arguments against it. Office 365 already supports something like this for our customers to cut down on Business Email Compromise. Maybe 5% of our customers have DMARC records, yet we treat all inbound email destined to them as having p=quarantine and then we figure out roughly who is allowed to send email as them even when (especially when) they don't authenticate. I talk about this here: http://aka.ms/AntispoofingInOffice365. We've been doing DMARC lookups on the header.from and stamping the result for a while now, and if it doesn't publish DMARC but would have passed if it did, we stamp the result and call it "Best Guess Pass". However, we use relaxed alignment, not strict. I talk about this here: http://blogs.msdn.com/b/tzink/archive/2015/05/06/what-is-dmarc-bestguesspass-in-office-365.aspx Figuring out implicit/virtual DMARC for everyone else is a much bigger body of water to boil, but is roughly the same problem. As a large receiver we have overrides for DMARC failures anyway, so implicit/virtual DMARC would have those same overrides. > Firstly, DMARC is an opt-in protocol for good reason. I'm saying this tongue-in-cheek, but that "good reason" is "very limited deployment in practice." If we would have waited for customers to publish DMARC records we'd be at 6% adoption rate. > In your first phase, p=none, this will have no effect. In your middle phase, > p=quarantine, this will cause massive loss of wanted email ... In your > final phase, p=reject, there will continue to be massive loss of wanted email. If large email receivers start junking messages because of implicit/virtual DMARC failures, senders figure it out eventually even without DMARC reporting. There's more tools in our toolbox than just junking. For example, we can add visual warnings to the message. We can choose not to extract/promote content if the header.from doesn't align with the SPF/DKIM domain (i.e., an airline sends a flight confirmation and that info is not shown to the user in a rich manner). We can add throttling limits. And so forth. -- Terry -Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Steve Atkins Sent: Tuesday, March 15, 2016 5:33 AM To: dmarc Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt > On Mar 14, 2016, at 11:28 PM, Kouji Okada wrote: > > We have submitted a draft about DMARC default verification > for domains not publishing DMARC records. > Any comments will be appreciated. Summary: If a domain does not opt-in to using DMARC, treat the domain as though it had opted-in to using DMARC with "p=none adkim=s aspf=s". Once that's deployed, change it to "p=reject adkim=s aspf=s". Possibly do "p=quarantine" between the two. There are multiple problems with this suggestion. Firstly, DMARC is an opt-in protocol for good reason. It's a lot of work to clean up all the mail streams for a domain such that all email is authenticated. In many cases it is impossible to do so. Those domains that have not done so should not publish a DMARC record. Requiring DMARC-esque authentication (let alone strict alignment) from domains that are not ready to use DMARC will cause a lot of wanted email to be treated as having failed that test. In your first phase, p=none, this will have no effect. The value of using p=none in DMARC is so that domains can take advantage of DMARC reporting without loss of legitimate email. You have no reporting, so this provides no value. In your middle phase, p=quarantine, this will cause massive loss of wanted email while still providing no feedback to senders. In your final phase, p=reject, there will continue to be massive loss of wanted email. In none of those phases does your draft add any value. If a receiver wants to pay attention to whether mail is authenticated or not it can already do so, and it can do so much more effectively than any approach that requires strict DMARC style alignment. Cheers, Steve ___ 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] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt
On Tue, Mar 15, 2016 at 6:43 AM, Rolf E. Sonneveld < r.e.sonnev...@sonnection.nl> wrote: > >> On Mar 14, 2016, at 11:28 PM, Kouji Okada wrote: > >> > >> We have submitted a draft about DMARC default verification > >> for domains not publishing DMARC records. > >> Any comments will be appreciated. > > > > Summary: If a domain does not opt-in to using DMARC, treat the domain > > as though it had opted-in to using DMARC with "p=none adkim=s aspf=s". > > Once that's deployed, change it to "p=reject adkim=s aspf=s". Possibly > > do "p=quarantine" between the two. > > > > There are multiple problems with this suggestion. > > > > Firstly, DMARC is an opt-in protocol for good reason. > > > > > In none of those phases does your draft add any value. If a receiver > wants to > > pay attention to > > whether mail is authenticated or not it can already do so, and it can do > so much > > more effectively than any approach that requires strict DMARC style > alignment. > > Well said, +1. At the risk of piling on, but feeling the need to have an assertive "hum" on the topic, I think that Steve Atkin's critiques are spot on. A receiver may reject mail for any reason that they so choose (subject to whatever jurisdictional rules and regulations they operate under), but calling it DMARC or "inferred DMARC" is abusing the term to no good effect. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt
- Original Message - > From: "Kouji Okada" > To: dmarc@ietf.org > Cc: "Kouji Okada" , > draft-akagiri-dmarc-virtual-verificat...@ietf.org > Sent: Monday, March 14, 2016 11:28:23 PM > Subject: [dmarc-ietf] Fwd: I-D Action: > draft-akagiri-dmarc-virtual-verification-00.txt > > We have submitted a draft about DMARC default verification > for domains not publishing DMARC records. > Any comments will be appreciated. > I have used to some form of success where all is considered in relaxed mode and with p=none. If I get a dmarc "pass" then I know the email is really coming from the domain it claims to be coming from, so for specific use cases the higher layers don't need to challenge the sender to prove who it is. Some of this code can be found at: https://github.com/linkedin/dmarc-msys/ This is mainly for internal use. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt
On Tue 15/Mar/2016 07:28:23 +0100 Kouji Okada wrote: > We have submitted a draft about DMARC default verification > for domains not publishing DMARC records. > Any comments will be appreciated. Maybe it's me, but I'm unable to make sense of the last paragraph of Section 3: When a DKIM verification passes, the virtual DMARC verification for the same email always passes. DMARC verification compares the RFC5322.from and domains described in the d tags of DKIM-Signature field of the received email. To pass the DKIM verification those two fields must be identical. Therefore, when the DKIM verification passes, the virtual verification of DMARC also passes. The mail message I'm replying to has dkim=pass (header.i=@ietf.org), but wouldn't have passed a virtual DMARC verification. Hence the first sentence is false. The second and third sentences express lepidum.co.jp != ietf.org correctly, but the fourth sentence infers the thesis wrongly. What am I missing? Ale ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt
>> On Mar 14, 2016, at 11:28 PM, Kouji Okada wrote: >> >> We have submitted a draft about DMARC default verification >> for domains not publishing DMARC records. >> Any comments will be appreciated. > > Summary: If a domain does not opt-in to using DMARC, treat the domain > as though it had opted-in to using DMARC with "p=none adkim=s aspf=s". > Once that's deployed, change it to "p=reject adkim=s aspf=s". Possibly > do "p=quarantine" between the two. > > There are multiple problems with this suggestion. > > Firstly, DMARC is an opt-in protocol for good reason. It's a lot of work to > clean up all the mail streams for a domain such that all email is > authenticated. > In many cases it is impossible to do so. Those domains that have not done > so should not publish a DMARC record. > > Requiring DMARC-esque authentication (let alone strict alignment) from domains > that are not ready to use DMARC will cause a lot of wanted email to be treated > as > having failed that test. > > In your first phase, p=none, this will have no effect. The value of using > p=none > in DMARC is so that domains can take advantage of DMARC reporting without > loss of legitimate email. You have no reporting, so this provides no value. > > In your middle phase, p=quarantine, this will cause massive loss of wanted > email > while > still providing no feedback to senders. > > In your final phase, p=reject, there will continue to be massive loss of > wanted > email. > > In none of those phases does your draft add any value. If a receiver wants to > pay attention to > whether mail is authenticated or not it can already do so, and it can do so > much > more effectively than any approach that requires strict DMARC style alignment. Well said, +1. /rolf ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt
> On Mar 14, 2016, at 11:28 PM, Kouji Okada wrote: > > We have submitted a draft about DMARC default verification > for domains not publishing DMARC records. > Any comments will be appreciated. Summary: If a domain does not opt-in to using DMARC, treat the domain as though it had opted-in to using DMARC with "p=none adkim=s aspf=s". Once that's deployed, change it to "p=reject adkim=s aspf=s". Possibly do "p=quarantine" between the two. There are multiple problems with this suggestion. Firstly, DMARC is an opt-in protocol for good reason. It's a lot of work to clean up all the mail streams for a domain such that all email is authenticated. In many cases it is impossible to do so. Those domains that have not done so should not publish a DMARC record. Requiring DMARC-esque authentication (let alone strict alignment) from domains that are not ready to use DMARC will cause a lot of wanted email to be treated as having failed that test. In your first phase, p=none, this will have no effect. The value of using p=none in DMARC is so that domains can take advantage of DMARC reporting without loss of legitimate email. You have no reporting, so this provides no value. In your middle phase, p=quarantine, this will cause massive loss of wanted email while still providing no feedback to senders. In your final phase, p=reject, there will continue to be massive loss of wanted email. In none of those phases does your draft add any value. If a receiver wants to pay attention to whether mail is authenticated or not it can already do so, and it can do so much more effectively than any approach that requires strict DMARC style alignment. Cheers, Steve ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
