Re: [dmarc-ietf] Experiments
On Monday, December 6, 2021 1:53:13 PM EST Murray S. Kucherawy wrote: > To those who said they're collecting data and hope to have some stuff to > share soon, is there anything interesting to report? > > The topic of ARC's efficacy came up in another IETF context today (tools) > and I'm wondering if we have anything new here. Nothing new to report on PSD. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Experiments
To those who said they're collecting data and hope to have some stuff to share soon, is there anything interesting to report? The topic of ARC's efficacy came up in another IETF context today (tools) and I'm wondering if we have anything new here. -MSK On Thu, Sep 23, 2021 at 2:08 PM Brotman, Alex wrote: > Murray, > > > > We’ve started (relatively recently, in volume) logging ARC data so we can > try to make some informed decisions going forward. We’re not yet acting on > anything as a result, nor writing into the message. We’re also not doing > anything when mail is being forwarded. We’ll hopefully have more > information/data available to share in the future (may not be the very near > future given other projects going on). This isn’t a guarantee that we’ll > fully adopt ARC in the future, but enough to say we’re logging/analyzing > things. > > Random thing while looking at some data just now .. At least one message > apparently came through with seven ARC sets. > > > > Let me know if there’s anything I can answer at this point. > > > > -- > > Alex Brotman > > Sr. Engineer, Anti-Abuse & Messaging Policy > > Comcast > > > > *From:* dmarc *On Behalf Of * Murray S. Kucherawy > *Sent:* Wednesday, September 22, 2021 4:30 PM > *To:* IETF DMARC WG > *Subject:* [dmarc-ietf] Experiments > > > > Is anyone in a position to comment on the ARC and PSD experiments and how > they're progressing? Deployment status? Data acquired thus far? > > > > -MSK > > > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Experiments
On September 24, 2021 1:43:25 AM UTC, Scott Kitterman wrote: >On Thursday, September 23, 2021 3:03:39 AM EDT Murray S. Kucherawy wrote: >> On Wed, Sep 22, 2021 at 1:59 PM Scott Kitterman >> >> wrote: >> > I can comment on the status of PSD. >> >> Please do! > >There is progress, but it is still early to expect much in the way of >information. Keep in mind that RFC 9091 is less than two months old. > >As most of you will probably recall from the discussion around PSD DMARC, the >ICANN managed TLDs (essentially everything except ccTLDs and a few special >cases like .mil and .gov) require permission to publish via non-IETF >processes. > >I'm aware of three PSDs which currently publish records. Both .gov.uk and >.mil have had records published for some time. Additionally, .police.uk >published a record in July of this year. I understand that .gov plans to >publish their record this month. > >Until we see publication from an ICANN managed TLD, I don't think we'll have >enough variety to seriously begin the assessments contemplated in the >experiment section of RFC 9091, so it's difficult to predict how soon we will >have conclusions. This isn't the right place to go into details on non-IETF >processes. > >Based on what I've heard so far, the PSD records are being queried and there >is some feedback reporting, so I'm confident we'll get data once we get a >little further on deployment. > >If anyone is aware of others, please let me know. Small update, earlier this month .gov published their PSD record. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Experiments
On Tue 28/Sep/2021 13:04:19 +0200 Douglas Foster wrote: Stated another way, the problem with ARC is that it requires the evaluator to attribute a positive reputation to the forwarder, in a context where even identifying the forwarder can be difficult. Exactly. To use ARC you need to be a global mailbox provider; that is, have a perfect knowledge of mail servers worldwide. Note that you don't need ARC or DMARC to stop phishing if you are in such position. Most email is accepted on a much weaker criteria - the absence of negative reputation. That's not so reliable, because 0-day debutantes would escape that filter. Mailing lists actually deserve an above-average reputation, because their messages are pre-filtered based on identity and content before being forwarded. But because they preserve the author address, list messages appear to be a random mail stream containing normal threat risks. From-rewriting of all list messages would allow the list to be evaluated based on the list reputation, rather than the random reputations of the list members. I don't think so. In fact, at the time being, global providers are the only ones who are able to maintain a reliable reputation database. Using ARC, they could ascribe to the list the reputation it deserves, irrespective of From: rewriting. Besides lists, many forwarders do some filtering on what they forward. With 20/20 global sight, ARC users can accurately reckon the reputation of the forwarder as well as that of the author's domain. IMHO, maintaining reputation databases that way is the only good use one can make of ARC. You can ARC-sign a message to enforce authentication without claiming "some responsibility" (or claiming less responsibility) for it. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Experiments
The simple solution if From: rewriting. I think you misspelled "ugly kludge" there. https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Replace_address_with_a_generic_one Yes, I know about that list of ugly kludges, since I wrote it. Note that forwarders should always rewrite the bounce address, for SPF. Mailing lists put on their own bounce addresses so they can do bounce >> handling. They've been doing that for about 40 years. That's not a kludge, that's >> how mailing lists work. I agree that replacing the bounce address has a VERP logic which predates SPF. Mailing lists were changing the bounce address long before VERP was invented. It's how they work. From: rewriting is a kludge, and it's how mailing lists work. No maiing list rewrote From: until AOL and Yahoo abused DMARC and people invented the kludge to sort of work around it. The whole point of ARC is so that lists and other forwarders *don't* have to do ugly kludges so I don't understand the point of this discussion. With ARC you have to distinguish cases (a), (b), (c), and (d). Well, you can hope, but as you know, there's no guarantees when you're sending mail. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Experiments
Stated another way, the problem with ARC is that it requires the evaluator to attribute a positive reputation to the forwarder, in a context where even identifying the forwarder can be difficult. Most email is accepted on a much weaker criteria - the absence of negative reputation. Mailing lists actually deserve an above-average reputation, because their messages are pre-filtered based on identity and content before being forwarded. But because they preserve the author address, list messages appear to be a random mail stream containing normal threat risks. From-rewriting of all list messages would allow the list to be evaluated based on the list reputation, rather than the random reputations of the list members. The existing approach to From rewrite is a mess, but it is not the only one possible.A DMARC-compliant list would solve a lot of problems, and is feasible, with the right type of rewrite. Doug On Tue, Sep 28, 2021 at 5:14 AM Alessandro Vesely wrote: > On Mon 27/Sep/2021 21:42:48 +0200 John Levine wrote: > > It appears that Alessandro Vesely said: > >> There is a case (d) final receiver enforcea DMARC and ARC, but the > >> forwarder is not among its ARC-trusted senders. > >> > >> The simple solution if From: rewriting. > > > > I think you misspelled "ugly kludge" there. > > > > https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Replace_address_with_a_generic_one > > > >> Note that forwarders should always rewrite the bounce address, for SPF. > > > > Mailing lists put on their own bounce addresses so they can do bounce > handling. > > They've been doing that for about 40 years. That's not a kludge, that's > how > > mailing lists work. > > > I agree that replacing the bounce address has a VERP logic which predates > SPF. In addition, it doesn't interfere with MUA displaying. So, yes, it's > less ugly, but it's still a kind of kludge. > > By design, DMARC forced the semantics of From:. It traded purism for > efficacy. Some ugliness has to be in the bargain too. > > From: rewriting is a kludge, and it's how mailing lists work. > > > > The whole point of ARC is so that lists and other forwarders *don't* > have to do ugly kludges > > so I don't understand the point of this discussion. > > > With ARC you have to distinguish cases (a), (b), (c), and (d). There is > no method (yet) to tell beforehand whether it's going to work at a given > receiver. Even if there was one, you should still consider the case that > the subscribed address will be forwarded to yet another receiver. > > > Best > Ale > -- > > > > > > > > > > > > > > ___ > 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] Experiments
On Mon 27/Sep/2021 21:42:48 +0200 John Levine wrote: It appears that Alessandro Vesely said: There is a case (d) final receiver enforcea DMARC and ARC, but the forwarder is not among its ARC-trusted senders. The simple solution if From: rewriting. I think you misspelled "ugly kludge" there. https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Replace_address_with_a_generic_one Note that forwarders should always rewrite the bounce address, for SPF. Mailing lists put on their own bounce addresses so they can do bounce handling. They've been doing that for about 40 years. That's not a kludge, that's how mailing lists work. I agree that replacing the bounce address has a VERP logic which predates SPF. In addition, it doesn't interfere with MUA displaying. So, yes, it's less ugly, but it's still a kind of kludge. By design, DMARC forced the semantics of From:. It traded purism for efficacy. Some ugliness has to be in the bargain too. From: rewriting is a kludge, and it's how mailing lists work. The whole point of ARC is so that lists and other forwarders *don't* have to do ugly kludges so I don't understand the point of this discussion. With ARC you have to distinguish cases (a), (b), (c), and (d). There is no method (yet) to tell beforehand whether it's going to work at a given receiver. Even if there was one, you should still consider the case that the subscribed address will be forwarded to yet another receiver. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Experiments
It appears that Alessandro Vesely said: >There is a case (d) final receiver enforcea DMARC and ARC, but the >forwarder is not among its ARC-trusted senders. > >The simple solution if From: rewriting. I think you misspelled "ugly kludge" there. > Note that forwarders should always rewrite the bounce address, for SPF. Mailing lists put on their own bounce addresses so they can do bounce handling. They've been doing that for about 40 years. That's not a kludge, that's how mailing lists work. The whole point of ARC is so that lists and other forwarders *don't* have to do ugly kludges so I don't understand the point of this discussion. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Experiments
On Mon, Sep 27, 2021 at 6:29 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > If a domain has an enforceable DMARC policy, and the message has no > signature, then the policy interpretation would be equivalent to a "DO NOT > FORWARD" order on postal mail. > > We expect that this action is probably not what the actual sender intends > or what the final recipient wants, just what the policy recommends. The > forwarding mediator has incentives to please the final recipient, so he is > unlikely to enforce a "Do Not Forward" request even if it is > legitimately made. > DMARC deals with signals from domains, not individual users (except for the edge case of personal domains). IETF standards deal with interoperability, not crystal balls or psychic readings attempting to interpret the wishes of individual users. If a Sending Domain publishes a policy, the Validator, whether an Intermediary or a Receiving Domain, has the choice of respecting the policy expressed by the Sending Domain or alternatively, exercising a local policy choice contrary to the Sending Domain policy request. It really is that simple. Trying to enshrine the basis for a multitude of potential reasons for local policy choices in an IETF standard is a guaranteed fail. > > Since this situation happens with some regularity, does it warrant some > commentary in the specification? > The only appropriate commentary is a warning to Sending Domains which choose to publish DMRC policy: "Be careful what you ask for. You might just get what you ask". When people publish broken DNS records (A, MX, etc.) do we tell others to guess the intent of the publishing domain? No, if one sees a broken record and feels like it, they tell the domain registrant (assuming the veil of opacity created by GDPR can be pierced) to fix their DNS record. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Experiments
If a domain has an enforceable DMARC policy, and the message has no signature, then the policy interpretation would be equivalent to a "DO NOT FORWARD" order on postal mail. We expect that this action is probably not what the actual sender intends or what the final recipient wants, just what the policy recommends. The forwarding mediator has incentives to please the final recipient, so he is unlikely to enforce a "Do Not Forward" request even if it is legitimately made. Since this situation happens with some regularity, does it warrant some commentary in the specification? On Fri, Sep 24, 2021 at 2:59 PM John Levine wrote: > It appears that Douglas Foster > said: > >-=-=-=-=-=- > > > >The Zoho situation is an interesting application of ARC. The forwarders > >are not altering the messages, so if the DMARC-enforcing domain was > >configured with signatures, their messages would have passed DMARC at the > >final destination. Without the signature, they should have been blocked > >already. > > There are plenty of senders who only use SPF and publish a DMARC policy > anyway. > > We all know why that's a bad idea, but that's what they do. > > R's, > John > -- > Regards, > John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. https://jl.ly > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Experiments
On Fri 24/Sep/2021 14:57:59 +0200 Douglas Foster wrote: It also highlights the difficulty of being a forwarder. What to do if a message from a DMARC-enforcing domain sends you a message, does not sign it, and it needs to be forwarded? If you forward anyway, the final recipient may block the message, with or without notification, and blame you. You could apply the Zoho defense, and add your own ARC set, which may or may not be recognized and trusted. The forwarder is in a quandary, because the final recipient (a) may ignore DMARC and want the message even without DMARC PASS, (b) may enforce DMARC and ignore ARC, still blocking the message and blaming you, or (c) may enforce DMARC but honor your ARC set and allow the message because of ARC. Without knowledge of the final evaluator behavior, there is no correct answer. There is a case (d) final receiver enforcea DMARC and ARC, but the forwarder is not among its ARC-trusted senders. The simple solution if From: rewriting. Note that forwarders should always rewrite the bounce address, for SPF. Instead, rewriting From: can be restricted to unsigned messages from hard-policy domains. It works regardless of ARC implementations. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Experiments
It appears that Douglas Foster said: >-=-=-=-=-=- > >The Zoho situation is an interesting application of ARC. The forwarders >are not altering the messages, so if the DMARC-enforcing domain was >configured with signatures, their messages would have passed DMARC at the >final destination. Without the signature, they should have been blocked >already. There are plenty of senders who only use SPF and publish a DMARC policy anyway. We all know why that's a bad idea, but that's what they do. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Experiments
We've deployed ARC validation on our cloud infrastructure for a few months now, and while I can't disclose absolute numbers, I can give some percentages: The failure rate with DMARC is about 7.5% of the mails which have a DMARC policy associated. And with ARC we can compensate the failure in about 9.75% of these cases. Our service has mostly German customers and we're seeing an increasing number of ARC intermediaries, but most have very little volume. The only significant intermediaries are (in descending order of mail volume): Microsoft.com, Strato.com, google.com, then a couple of domains related to zohomail. Kind regards, Henning > -Original Message- > From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Douglas Foster > Sent: Freitag, 24. September 2021 14:58 > To: IETF DMARC WG > Subject: Re: [dmarc-ietf] Experiments > > The Zoho situation is an interesting application of ARC. The forwarders are > not altering the messages, so if the DMARC-enforcing domain was > configured with signatures, their messages would have passed DMARC at the > final destination. Without the signature, they should have been blocked > already. Apparently Zoho had encountered a lot of domains which were > DMARC-enforcing but not signing, so they were not enforcing DMARC at all. > Then they implemented ARC, so that they could trust SPF alignment if the > message was aligned before forwarding, and began enforcing DMARC at > reception. But without ARC support at the forwarder, the sender > configuration problem persists. > > It also highlights the difficulty of being a forwarder.What to do if a > message > from a DMARC-enforcing domain sends you a message, does not sign it, and > it needs to be forwarded? If you forward anyway, the final recipient may > block the message, with or without notification, and blame you. You could > apply the Zoho defense, and add your own ARC set, which may or may not > be recognized and trusted. The forwarder is in a quandary, because the final > recipient (a) may ignore DMARC and want the message even without > DMARC PASS, (b) may enforce DMARC and ignore ARC, still blocking the > message and blaming you, or (c) may enforce DMARC but honor your ARC > set and allow the message because of ARC. Without knowledge of the final > evaluator behavior, there is no correct answer. > > > On Fri, Sep 24, 2021 at 6:56 AM Ken O'Driscoll > <mailto:40wemonitoremail@dmarc.ietf.org> > wrote: > > > > > Well, I have had a deliverability related encounter with ARC in the > wild, and can report that ARC is actively being used by Zoho. > > > > A client was using Zoho for their service desk and messages started > going missing. The way these service desks work is that you forward say > supp...@example.com <mailto:supp...@example.com> to a unique Zoho > supplied email address which goes to your service desk queue. > > > > On investigation, it was determined that the only messages going > missing were those originating from domains with an enforcing DMARC policy > and non-aligned/non-existent/broken DKIM. > > > > Correspondence with Zoho’s customer service revealed that they a) > have implemented ARC, b) expect every mailbox provider to also have > implemented ARC, and c) are making filtering decisions on that belief. They > appear to be maintaining their own internal trust db. And yes, I know that > this is ideally how we want ARC to work; Zoho are just eager and early to the > party. They were not receptive to my opinion on the flaw with their strategy. > > > > In my client’s case, their ISP has no plans to implement ARC, so Zoho > grudgingly disabled the filtering for their account. > > > > This incident made me wonder how much stealth ARC is out there, > i.e. it’s not evident that it’s being used at all, or indeed for filtering > decisions, > until you poke the organisation. > > > > Ken. > > > > From: dmarc mailto:dmarc- > boun...@ietf.org> > On Behalf Of Murray S. Kucherawy > Sent: Wednesday 22 September 2021 21:30 > To: IETF DMARC WG mailto:dmarc@ietf.org> > > Subject: [dmarc-ietf] Experiments > > > > Is anyone in a position to comment on the ARC and PSD experiments > and how they're progressing? Deployment status? Data acquired thus far? > > > > -MSK > > > > ___ > dmarc mailing list > dmarc@ietf.org <mailto: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] Experiments
The Zoho situation is an interesting application of ARC. The forwarders are not altering the messages, so if the DMARC-enforcing domain was configured with signatures, their messages would have passed DMARC at the final destination. Without the signature, they should have been blocked already. Apparently Zoho had encountered a lot of domains which were DMARC-enforcing but not signing, so they were not enforcing DMARC at all. Then they implemented ARC, so that they could trust SPF alignment if the message was aligned before forwarding, and began enforcing DMARC at reception. But without ARC support at the forwarder, the sender configuration problem persists. It also highlights the difficulty of being a forwarder.What to do if a message from a DMARC-enforcing domain sends you a message, does not sign it, and it needs to be forwarded? If you forward anyway, the final recipient may block the message, with or without notification, and blame you. You could apply the Zoho defense, and add your own ARC set, which may or may not be recognized and trusted. The forwarder is in a quandary, because the final recipient (a) may ignore DMARC and want the message even without DMARC PASS, (b) may enforce DMARC and ignore ARC, still blocking the message and blaming you, or (c) may enforce DMARC but honor your ARC set and allow the message because of ARC. Without knowledge of the final evaluator behavior, there is no correct answer. On Fri, Sep 24, 2021 at 6:56 AM Ken O'Driscoll wrote: > > > Well, I have had a deliverability related encounter with ARC in the wild, > and can report that ARC is actively being used by Zoho. > > > > A client was using Zoho for their service desk and messages started going > missing. The way these service desks work is that you forward say > supp...@example.com to a unique Zoho supplied email address which goes to > your service desk queue. > > > > On investigation, it was determined that the only messages going missing > were those originating from domains with an enforcing DMARC policy and > non-aligned/non-existent/broken DKIM. > > > > Correspondence with Zoho’s customer service revealed that they a) have > implemented ARC, b) expect every mailbox provider to also have implemented > ARC, and c) are making filtering decisions on that belief. They appear to > be maintaining their own internal trust db. And yes, I know that this is > ideally how we want ARC to work; Zoho are just eager and early to the > party. They were not receptive to my opinion on the flaw with their > strategy. > > > > In my client’s case, their ISP has no plans to implement ARC, so Zoho > grudgingly disabled the filtering for their account. > > > > This incident made me wonder how much stealth ARC is out there, i.e. it’s > not evident that it’s being used at all, or indeed for filtering decisions, > until you poke the organisation. > > > > Ken. > > > > *From:* dmarc *On Behalf Of *Murray S. Kucherawy > *Sent:* Wednesday 22 September 2021 21:30 > *To:* IETF DMARC WG > *Subject:* [dmarc-ietf] Experiments > > > > Is anyone in a position to comment on the ARC and PSD experiments and how > they're progressing? Deployment status? Data acquired thus far? > > > > -MSK > > > ___ > 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] Experiments
Chiming in only to mention that there is a recently created IETF mailing list dedicated to ARC - https://www.ietf.org/mailman/listinfo/arc Discussion of ARC data and such might be appropriate there, too. On Thu, Sep 23, 2021 at 5:30 PM Trent Adams wrote: > > > Piling onto Alex's response... we have some ARC functionality deployed and > servicing customers. I'm currently looking into what useful data we can > extract and share what we've learned from the implementation (which may > lead to some useful topics to discuss in more depth). > > > > In a related note... an early examination seems to underscore the need to > more guidance about how to interpret ARC sets. As Alex pointed out... > there are some messages with way more sets than can be used to make a > reasonable determination about the provenance of the message. So, at the > very least, I think we may need to develop some ancillary documents to > support broader adoption. > > > > More as it develops, > > Trent > > > > > > *From: *dmarc on behalf of "Brotman, Alex" > > *Date: *Thursday, September 23, 2021 at 3:08 PM > *To: *"Murray S. Kucherawy" , IETF DMARC WG < > dmarc@ietf.org> > *Subject: *Re: [dmarc-ietf] Experiments > > > > Murray, > > > > We’ve started (relatively recently, in volume) logging ARC data so we can > try to make some informed decisions going forward. We’re not yet acting on > anything as a result, nor writing into the message. We’re also not doing > anything when mail is being forwarded. We’ll hopefully have more > information/data available to share in the future (may not be the very near > future given other projects going on). This isn’t a guarantee that we’ll > fully adopt ARC in the future, but enough to say we’re logging/analyzing > things. > > Random thing while looking at some data just now .. At least one message > apparently came through with seven ARC sets. > > > > Let me know if there’s anything I can answer at this point. > > > > -- > > Alex Brotman > > Sr. Engineer, Anti-Abuse & Messaging Policy > > Comcast > > > > *From:* dmarc *On Behalf Of * Murray S. Kucherawy > *Sent:* Wednesday, September 22, 2021 4:30 PM > *To:* IETF DMARC WG > *Subject:* [dmarc-ietf] Experiments > > > > Is anyone in a position to comment on the ARC and PSD experiments and how > they're progressing? Deployment status? Data acquired thus far? > > > > -MSK > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Experiments
Well, I have had a deliverability related encounter with ARC in the wild, and can report that ARC is actively being used by Zoho. A client was using Zoho for their service desk and messages started going missing. The way these service desks work is that you forward say supp...@example.com to a unique Zoho supplied email address which goes to your service desk queue. On investigation, it was determined that the only messages going missing were those originating from domains with an enforcing DMARC policy and non-aligned/non-existent/broken DKIM. Correspondence with Zoho’s customer service revealed that they a) have implemented ARC, b) expect every mailbox provider to also have implemented ARC, and c) are making filtering decisions on that belief. They appear to be maintaining their own internal trust db. And yes, I know that this is ideally how we want ARC to work; Zoho are just eager and early to the party. They were not receptive to my opinion on the flaw with their strategy. In my client’s case, their ISP has no plans to implement ARC, so Zoho grudgingly disabled the filtering for their account. This incident made me wonder how much stealth ARC is out there, i.e. it’s not evident that it’s being used at all, or indeed for filtering decisions, until you poke the organisation. Ken. From: dmarc On Behalf Of Murray S. Kucherawy Sent: Wednesday 22 September 2021 21:30 To: IETF DMARC WG Subject: [dmarc-ietf] Experiments Is anyone in a position to comment on the ARC and PSD experiments and how they're progressing? Deployment status? Data acquired thus far? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Experiments
On Thursday, September 23, 2021 3:03:39 AM EDT Murray S. Kucherawy wrote: > On Wed, Sep 22, 2021 at 1:59 PM Scott Kitterman > > wrote: > > I can comment on the status of PSD. > > Please do! There is progress, but it is still early to expect much in the way of information. Keep in mind that RFC 9091 is less than two months old. As most of you will probably recall from the discussion around PSD DMARC, the ICANN managed TLDs (essentially everything except ccTLDs and a few special cases like .mil and .gov) require permission to publish via non-IETF processes. I'm aware of three PSDs which currently publish records. Both .gov.uk and .mil have had records published for some time. Additionally, .police.uk published a record in July of this year. I understand that .gov plans to publish their record this month. Until we see publication from an ICANN managed TLD, I don't think we'll have enough variety to seriously begin the assessments contemplated in the experiment section of RFC 9091, so it's difficult to predict how soon we will have conclusions. This isn't the right place to go into details on non-IETF processes. Based on what I've heard so far, the PSD records are being queried and there is some feedback reporting, so I'm confident we'll get data once we get a little further on deployment. If anyone is aware of others, please let me know. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Experiments
For messages sent from Office365, Microsoft applies an initial ARC set, and declares the message to be DMARC-compliant.I do not think Microsoft should be passing judgement on messages that it is originating, or attributing an SPF result to a message that was only just submitted with SMTP AUTH. But this situation does point to the complexity of trusting and interpreting the ARC chain, which is unfortunate. On Thu, Sep 23, 2021 at 5:08 PM Brotman, Alex wrote: > Murray, > > > > We’ve started (relatively recently, in volume) logging ARC data so we can > try to make some informed decisions going forward. We’re not yet acting on > anything as a result, nor writing into the message. We’re also not doing > anything when mail is being forwarded. We’ll hopefully have more > information/data available to share in the future (may not be the very near > future given other projects going on). This isn’t a guarantee that we’ll > fully adopt ARC in the future, but enough to say we’re logging/analyzing > things. > > Random thing while looking at some data just now .. At least one message > apparently came through with seven ARC sets. > > > > Let me know if there’s anything I can answer at this point. > > > > -- > > Alex Brotman > > Sr. Engineer, Anti-Abuse & Messaging Policy > > Comcast > > > > *From:* dmarc *On Behalf Of * Murray S. Kucherawy > *Sent:* Wednesday, September 22, 2021 4:30 PM > *To:* IETF DMARC WG > *Subject:* [dmarc-ietf] Experiments > > > > Is anyone in a position to comment on the ARC and PSD experiments and how > they're progressing? Deployment status? Data acquired thus far? > > > > -MSK > > > ___ > 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] Experiments
Piling onto Alex's response... we have some ARC functionality deployed and servicing customers. I'm currently looking into what useful data we can extract and share what we've learned from the implementation (which may lead to some useful topics to discuss in more depth). In a related note... an early examination seems to underscore the need to more guidance about how to interpret ARC sets. As Alex pointed out... there are some messages with way more sets than can be used to make a reasonable determination about the provenance of the message. So, at the very least, I think we may need to develop some ancillary documents to support broader adoption. More as it develops, Trent From: dmarc on behalf of "Brotman, Alex" Date: Thursday, September 23, 2021 at 3:08 PM To: "Murray S. Kucherawy" , IETF DMARC WG Subject: Re: [dmarc-ietf] Experiments Murray, We’ve started (relatively recently, in volume) logging ARC data so we can try to make some informed decisions going forward. We’re not yet acting on anything as a result, nor writing into the message. We’re also not doing anything when mail is being forwarded. We’ll hopefully have more information/data available to share in the future (may not be the very near future given other projects going on). This isn’t a guarantee that we’ll fully adopt ARC in the future, but enough to say we’re logging/analyzing things. Random thing while looking at some data just now .. At least one message apparently came through with seven ARC sets. Let me know if there’s anything I can answer at this point. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: dmarc On Behalf Of Murray S. Kucherawy Sent: Wednesday, September 22, 2021 4:30 PM To: IETF DMARC WG Subject: [dmarc-ietf] Experiments Is anyone in a position to comment on the ARC and PSD experiments and how they're progressing? Deployment status? Data acquired thus far? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Experiments
Murray, We’ve started (relatively recently, in volume) logging ARC data so we can try to make some informed decisions going forward. We’re not yet acting on anything as a result, nor writing into the message. We’re also not doing anything when mail is being forwarded. We’ll hopefully have more information/data available to share in the future (may not be the very near future given other projects going on). This isn’t a guarantee that we’ll fully adopt ARC in the future, but enough to say we’re logging/analyzing things. Random thing while looking at some data just now .. At least one message apparently came through with seven ARC sets. Let me know if there’s anything I can answer at this point. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: dmarc On Behalf Of Murray S. Kucherawy Sent: Wednesday, September 22, 2021 4:30 PM To: IETF DMARC WG Subject: [dmarc-ietf] Experiments Is anyone in a position to comment on the ARC and PSD experiments and how they're progressing? Deployment status? Data acquired thus far? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Experiments
On Wed, Sep 22, 2021 at 1:59 PM Scott Kitterman wrote: > I can comment on the status of PSD. > Please do! ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Experiments
I can comment on the status of PSD. Scott K On September 22, 2021 8:30:29 PM UTC, "Murray S. Kucherawy" wrote: >Is anyone in a position to comment on the ARC and PSD experiments and how >they're progressing? Deployment status? Data acquired thus far? > >-MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Experiments
Is anyone in a position to comment on the ARC and PSD experiments and how they're progressing? Deployment status? Data acquired thus far? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
