Re: [dmarc-ietf] A-R results for DMARC

On Mon, 7 Dec 2020, Murray S. Kucherawy wrote: The original intent back in RFC 5451 was to relay only those details that an MUA might care about, such as the DKIM result (so you can display something representing a "pass" or "fail" on a message) and maybe the domain name found in a passing signat

Re: [dmarc-ietf] A-R results for DMARC

On Mon, Dec 7, 2020 at 7:16 PM John Levine wrote: > I have never understood all of the indirection involved in defining > stuff for A-R but I'm hoping Murray can help out. > What I think you're referring to is a distinction between the way we seem to want to use A-R now versus how it was origina

Re: [dmarc-ietf] Ticket #1 - SPF alignment

Is there an identifiable attack vector which can be based on using the (forward confirmed) HELO name for SPF pass? If not, why change? On Mon, Dec 7, 2020, 6:09 AM Dotzero wrote: > > > On Mon, Dec 7, 2020 at 2:13 AM Murray S. Kucherawy > wrote: > >> On Tue, Dec 1, 2020 at 2:17 PM John R Levi

Re: [dmarc-ietf] A-R results for DMARC

Please open a ticket, agreed that standardization here is a good thing. I have some further thoughts as an individual once the ticket is opened. On Mon, Dec 7, 2020 at 19:16 John Levine wrote: > I don't think there is a ticket for this, but it would be nice if > there were standard ways to put

Re: [dmarc-ietf] A-R results for DMARC

I don't think there is a ticket for this, but it would be nice if there were standard ways to put a few more items into the DMARC part of an A-R header, in particular the p= and pct= values and the location of the policy record if it's not the same as header.from. None of the existing ptypes reall

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

In article you write: >Anyways, +1 to keeping p=quarantine as a concept, but willing to go along >with the consensus on naming. I'm modestly in favor of keeping p=quarantine as a feature but utterly opposed to changing the keywords such as "p=quarantine" in the DMARC record. It's fine to improv

Re: [dmarc-ietf] not ADSP, was is DMARC informational?

On Mon, 7 Dec 2020, Jim Fenton wrote: Agree, the reporting is great. But so much of the marketing/mandates I see around DMARC doesn’t tell domain owners to turn on reporting first to see what’s broken, it tells them to publish a DMARC p=reject policy because they have a security vulnerability i

Re: [dmarc-ietf] not ADSP, was is DMARC informational?

There are a number of open issues and you open more. https://trac.ietf.org/trac/dmarc/report/1 I think it is being serialized for lack of people and also WG energy. tim On Mon, Dec 7, 2020 at 8:20 PM Michael Thomas wrote: > > On 12/7/20 5:15 PM, Tim Wicinski wrote: > > > A good section of our

Re: [dmarc-ietf] not ADSP, was is DMARC informational?

On 12/7/20 5:15 PM, Tim Wicinski wrote: A good section of our charter is collection Operational experiences. Doing an Operational BCP on DMARC based on data collected is what the WG should do after DMARC-bis. I guess I don't understand why this should be serialized. When I read over DMARC

Re: [dmarc-ietf] not ADSP, was is DMARC informational?

A good section of our charter is collection Operational experiences. Doing an Operational BCP on DMARC based on data collected is what the WG should do after DMARC-bis. tim On Mon, Dec 7, 2020 at 7:50 PM Michael Thomas wrote: > > On 12/7/20 4:44 PM, Dave Warren wrote: > > On Sun, Dec 6, 2020, a

Re: [dmarc-ietf] not ADSP, was is DMARC informational?

On 12/7/20 4:44 PM, Dave Warren wrote: On Sun, Dec 6, 2020, at 22:31, Michael Thomas wrote: there are clearly many use cases where that isn't a problem -- like bank transactional mail -- and ADSP was just fine for that. There were still surprises to be had here. I still, to this day, find mai

Re: [dmarc-ietf] not ADSP, was is DMARC informational?

On Sun, Dec 6, 2020, at 22:31, Michael Thomas wrote: > there are clearly many use cases where that isn't a problem -- like bank > transactional mail -- and ADSP was just fine for that. There were still surprises to be had here. I still, to this day, find mail direct from various senders that are

Re: [dmarc-ietf] not ADSP, was is DMARC informational?

On 6 Dec 2020, at 21:18, John Levine wrote: In article you write: As I recall, people took a run at trying ADSP and it was largely unsuccessful. I recall at least Yahoo, PayPal, and Google trying it but finding that it interfered with their employees' participation in lists, so they ea

Re: [dmarc-ietf] ARC vs reject

On Mon, Dec 7, 2020 at 2:28 PM Kurt Andersen (b) wrote: > On Sun, Dec 6, 2020 at 10:46 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> >> I ask the chairs to formally endorse development of an alternative to ARC >> as an additional approach to the mailing list problem... >>

Re: [dmarc-ietf] ARC vs reject

On Sun, Dec 6, 2020 at 10:46 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > > I ask the chairs to formally endorse development of an alternative to ARC > as an additional approach to the mailing list problem... > So you are asking the WG to go back to our second milestone and p

Re: [dmarc-ietf] Discussion: Removal of validation for external destinations (Ticket #76)

Removing this opens up the potential for abuse, I don't see the value in removing it. On Sun, 6 Dec 2020, at 11:06 PM, Alessandro Vesely wrote: > On Sat 05/Dec/2020 14:51:52 +0100 Brotman, Alex wrote: > > > > There's currently a ticket that suggests that the requirement for external > > validat

Re: [dmarc-ietf] ARC vs reject

On Sat, Dec 5, 2020 at 5:21 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > ...much of this is about AOL in particular, and the currently available > information suggests that AOL is not on board with ARC. > I would point you to https://tools.ietf.org/html/draft-ietf-dmarc-arc-p

Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)

There is value in including these in one report, especially where the extended property being reported on influences how DMARC is evaluated. Using ARC as the example, when a p=reject policy was overriden by the receiver because of an ARC evaluation, when that data is included in the report the

Re: [dmarc-ietf] Ticket #1 - SPF alignment

In article you write: >> I have a slight preference for the first option. HELO is too arbitrary in >> the protocol for me to put much value in using it in any of these systems. > >There's a bit of an implementation detail though. If one is relying on an >encapsulated ck_host() function then you

Re: [dmarc-ietf] Ticket #1 - SPF alignment

On Sun, Dec 6, 2020 at 11:13 PM Murray S. Kucherawy wrote: > On Tue, Dec 1, 2020 at 2:17 PM John R Levine wrote: > >> We would like to close this ticket by Dec 15, two weeks from now, so >> short >> trenchant comments are welcome. >> >> Ticket #1 is about SPF alignment. We need to replace refer

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

>I don't understand the security or GDPR references. Well this is amusing. I wondered if anyone had ever implemented some version of the http reporting in early DMARC drafts, so I set up a new domain with a server that will accept POST or PUT requests and added its URI to my DMARC records. I didn

Re: [dmarc-ietf] ARC vs reject

On 12/7/20 1:00 PM, Tim Wicinski wrote: On Mon, Dec 7, 2020 at 2:26 PM Michael Thomas > wrote: This is why we need actual numbers instead of anecdotes about the long tail. We know that there is no silver bullet. Mailing lists who are configured in a way

Re: [dmarc-ietf] ARC vs reject

On Mon, Dec 7, 2020 at 2:26 PM Michael Thomas wrote: > > On 12/7/20 11:19 AM, John Levine wrote: > > In article you write: > >> Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the > >> fact that footers are written in plain text ... > > They are? Some are, some are added a

Re: [dmarc-ietf] Ticket #28 - Failure report mail loops

In article <0408ae98-e1c1-71fe-fdd4-8bc7a7c15...@tana.it> you write: >We would like to close this ticket by Dec 18, two weeks from now, so please >get >on it. > >The ticket originated from John's comment, in May 2019: > > Apropos recent discussions, we could recommend that failure reports be

Re: [dmarc-ietf] Ticket #28 - Failure report mail loops

In article , Alessandro Vesely wrote: >> 4. Some explicit loop prevention specification may be added. For example: >>> 4.1. send reports from a subdomain having a DMARC record without ruf=, or >>> 4.2. never send failure reports about failed reports. >> >> The latter, which is consistent wit

Re: [dmarc-ietf] ARC vs reject

On 12/7/20 11:19 AM, John Levine wrote: In article you write: Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the fact that footers are written in plain text ... They are? Some are, some are added as MIME parts. We really need to keep in mind that there is a lot of li

Re: [dmarc-ietf] ARC vs reject

In article you write: >Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the >fact that footers are written in plain text ... They are? Some are, some are added as MIME parts. We really need to keep in mind that there is a lot of list management software with a vast array of

Re: [dmarc-ietf] ARC vs reject

On 12/7/20 10:33 AM, Murray S. Kucherawy wrote: On Mon, Dec 7, 2020 at 8:59 AM Michael Thomas > wrote: Btw, what is PSD? A working group document: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ Oh

Re: [dmarc-ietf] ARC vs reject

On Mon, Dec 7, 2020 at 10:34 AM Murray S. Kucherawy wrote: > On Mon, Dec 7, 2020 at 4:05 AM Dotzero wrote: > >> I've asked here and in other places that validators/receivers consuming >> ARC headers provide data regarding the results of such consumption. To date >> we have not seen any data prov

Re: [dmarc-ietf] ARC vs reject

On 12/7/20 10:32 AM, Murray S. Kucherawy wrote: On Mon, Dec 7, 2020 at 4:05 AM Dotzero > wrote: I've asked here and in other places that validators/receivers consuming ARC headers provide data regarding the results of such consumption. To date we have not s

Re: [dmarc-ietf] ARC vs reject

On Mon, Dec 7, 2020 at 8:59 AM Michael Thomas wrote: > Btw, what is PSD? > A working group document: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

On Mon, Dec 7, 2020 at 4:05 AM Dotzero wrote: > I've asked here and in other places that validators/receivers consuming > ARC headers provide data regarding the results of such consumption. To date > we have not seen any data provided by participants in the ARC experiment. > It may be that ARC is

Re: [dmarc-ietf] ARC vs reject

On 12/6/20 9:30 PM, Murray S. Kucherawy wrote: On Sun, Dec 6, 2020 at 9:24 PM Michael Thomas > wrote: An idea that i've been rolling around in my head is that the MLM could give a sed-like script to rollback the changes. since they know their modifications, the

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

poorly defined http report which we took out. I propose we add back https reporting similar to that for mta-sts, with a POST of the gzipped report to the HTTPS URI. Was this requested by someone? I don't recall a strong security and privacy concerns discussion around HTTP(S) reporting. Presum

Re: [dmarc-ietf] ARC vs reject

On 12/7/20 1:35 AM, Alessandro Vesely wrote: On Sun 06/Dec/2020 19:47:24 +0100 Michael Thomas wrote: It seems a lot simpler for the originating domain to just be explicit about how they feel about transformations by intermediaries. It's not like another short ascii string is going to break th

Re: [dmarc-ietf] DMARC and ARC

Thanks for engaging Murray. On the usefulness of source blacklisting: I have been using the model I described for about a year.I have two categories of mailers that account for nearly all of my spam: spamer-owned infrastructure which sends direct, and email service providers that accept all

Re: [dmarc-ietf] ARC vs reject

On Mon, Dec 7, 2020 at 12:30 AM Murray S. Kucherawy wrote: > On Sun, Dec 6, 2020 at 9:24 PM Michael Thomas wrote: > >> An idea that i've been rolling around in my head is that the MLM could >> give a sed-like script to rollback the changes. since they know their >> modifications, they can obviou

Re: [dmarc-ietf] DMARC and ARC

On Mon, Dec 7, 2020 at 12:15 AM Murray S. Kucherawy wrote: > On Fri, Dec 4, 2020 at 7:58 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> First, lets begin with the obvious: malicious messages come from >> enterprises that are in the malicious message business. They rare

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

On Mon, Dec 7, 2020 at 2:18 AM Murray S. Kucherawy wrote: > On Tue, Dec 1, 2020 at 2:22 PM John R Levine wrote: > >> We would like to close this ticket by Dec 15, two weeks from now, so >> short >> trenchant comments are welcome. >> >> Ticket #1 is about https reporting. Early drafts of the DMA

Re: [dmarc-ietf] Ticket #28 - Failure report mail loops

On Mon 07/Dec/2020 08:15:57 +0100 Murray S. Kucherawy wrote: On Fri, Dec 4, 2020 at 3:10 AM Alessandro Vesely wrote: We would like to close this ticket by Dec 18, two weeks from now, so please get on it. The ticket originated from John's comment, in May 2019: Apropos recent discussions,

Re: [dmarc-ietf] Ticket #1 - SPF alignment

On Mon, Dec 7, 2020 at 2:13 AM Murray S. Kucherawy wrote: > On Tue, Dec 1, 2020 at 2:17 PM John R Levine wrote: > >> We would like to close this ticket by Dec 15, two weeks from now, so >> short >> trenchant comments are welcome. >> >> Ticket #1 is about SPF alignment. We need to replace refere

Re: [dmarc-ietf] ARC vs reject

On Mon 07/Dec/2020 06:05:29 +0100 Murray S. Kucherawy wrote: A counter-argument I've heard often to the idea of reversible transformations is that it can become a spam vector, no different than the argument against "l=". Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the

Re: [dmarc-ietf] ARC vs reject

On Sun 06/Dec/2020 05:14:18 +0100 John R Levine wrote: On Sat, 5 Dec 2020, Jim Fenton wrote: ... If the recipient domain accepts modifications by zero-reputation intermediaries (because there are so many of them, after all) I wouldn't call that a reasonable implementation of ARC.  The set of

Re: [dmarc-ietf] ARC vs reject

On Sun 06/Dec/2020 19:47:24 +0100 Michael Thomas wrote: On 12/6/20 10:31 AM, Alessandro Vesely wrote: On Sun 06/Dec/2020 18:01:04 +0100 Michael Thomas wrote: This actually highlights why my observation is correct. If the intermediary showed how to reverse their changes perfectly to be able to