Hello, I do no see the point of having all the discussions here, as nobody is capable to read and understarstand all written emails in their whole quantity. I personally do not follow the discussions anymore, apart from reading the subjects…
On Mon, 2020-12-07 at 17:55 -0800, Brandon Long wrote: > > > On Wed, Dec 2, 2020 at 11:09 AM Murray S. Kucherawy > <superu...@gmail.com> wrote: > > On Wed, Dec 2, 2020 at 6:47 AM Dotzero <dotz...@gmail.com> wrote: > > > p= DID NOT mistakenly choose to use the language of receiver > > > actions. p= represents the domain-owner request to the receiver > > > as to the disposition of messages which fail to validate. Any > > > reading of "concern" is supposition on the part of yourself or > > > other self appointed interpreters of the mind of the domain-owner > > > or administrator. The vocabulary is perfectly fine as it > > > accurately describes the request being made. It makes no attempt > > > to read the underlying reasoning behind the request because, > > > surprisingly, there is likely to be a wide range of underlying > > > reasoning behind why various domains publish the policies they > > > publish. This is an interoperability standard, not a seance. > > > > > > > > > Not sure I agree. > > > > I have long held a quiet dislike for "quarantine" because that has > > a particular meaning to milter implementations. Specifically, > > milter can render one of several final results about a message, one > > of which is actually called "quarantine". It means "park this in > > the queue indefinitely until a human decides what to do with it." > > There's no indication to the operator that such a job is waiting > > for review unless one goes and looks for such things. The upshot > > of this is that quarantining in that environment can become a > > denial of service attack if I send you enough messages that end up > > getting handled that way and your queue disk fills, or the queue > > takes an inordinately long time to process because these have piled > > up and need to be inspected. > > > > Certainly not all implementers will trip on this (maybe none will) > > but it's an argument to me in favor of picking a word or set of > > words that describe what the domain owner thinks of the message, > > rather than what the domain owner thinks you should do with it. > > > > > Hmm, reading this thread, I think one missing feature in the dmarc > spec is passing the expected disposition in the authres header, since > presumably the evaluation is at smtp time, but the mailbox > delivery itself would need to know it. One could use the dmarc= > names and look up the dmarc policy itself to also figure that out > with some amount of work. … and in July 2019 there was a discussion with the subject „Reporting DMARC policy in A-R header fields“ on this mailing lists. Below is an off-list consensensus to put the applied policy in the A-R from that thread, that was not sent eventually over the mailing list: From: Scott Kitterman <skl...@kitterman.com> To: Дилян Палаузов <dilyan.palau...@aegee.org> Subject: Re: Reporting DMARC policy in A-R header fields Date: Wed, 31 Jul 2019 10:49:32 +0000 I agree with your statement. MTA does the percentage test and puts the policy to be applied in A-R for the MDA to consume. I'm working off my phone, so typing is slow. I don't mind being more verbose once I'm at my laptop, but it will have to wait. Please let me know if it's still uncertain. Scott K On July 31, 2019 10:35:15 AM UTC, "Дилян Палаузов" <dilyan.palau...@aegee.org> wrote: >Hello Scott, > >you are too spare in your words. > >My understanding of the conversation so far is that only the MTA does >the sampling for failed messages based on p= and >pct= . The A-R header is supposed to carry information, whether the >message validated or failed DMARC and for failed >validation, what the MDA shall do with the message (basically >quarantine or deliver). > >If you put the policy to be applied in the A-R, then it is not the >policy from DNS, but rather the disposition to be >applied. > >Regards > Дилян > >On Wed, 2019-07-31 at 10:28 +0000, Scott Kitterman wrote: >> I suppose you could also add something like dmarc.pct=50 too, but I >think that would add complexity to no benefit. As long as you make the >sample decision once, it works out the same. For the case where a >message wasn't selected due to sampling then I'd put the policy to be >applied in A-R so the MDA doesn't have to worry about the percentage. >> >> Scott K >> >> On July 31, 2019 5:56:26 AM UTC, "Дилян Палаузов" ><dilyan.palau...@aegee.org> wrote: >> > Hello Scott, >> > >> > for p=quarantine; pct=50 if the MTA does the sampling and decides >to >> > quarantine, and forward the email to the MDA, how can the MDA know >> > whether it shall quarantine the message or not? >> > >> > Regards >> > Dilyan >> > >> > On July 31, 2019 1:25:23 AM GMT+03:00, Scott Kitterman >> > <skl...@kitterman.com> wrote: >> > > Since the status is per message, I think the MTA should do it and >> > other >> > > than as perhaps a comment, it doesn't need to be in A-R. >> > > >> > > Scott K >> > > >> > > On July 30, 2019 2:04:28 PM UTC, "Дилян Палаузов" >> > > <dilyan.palau...@aegee.org> wrote: >> > > > OFF LIST >> > > > >> > > > Hello Scott, >> > > > >> > > > does the PCT value belong to the published policy and subject >to >> > > > inclusion in the A-R header? >> > > > >> > > > Who is supposed to apply the sampling, based on PCT parameter: >the >> > > MTA, >> > > > the MDA or both? >> > > > >> > > > If both are supposed to do it, can the A-R header be extended >in such >> > > a >> > > > way, that only the MTA does the sampling, and >> > > > carries the information to the MDA? >> > > > >> > > > Regards >> > > > Дилян >> > > > >> > > > On Tue, 2019-07-30 at 13:56 +0000, Scott Kitterman wrote: >> > > > > The published policy (that's why I suggest dmarc.policy). >I'm not >> > > > sure if disposition belongs in A-R. If it does, it'd be a >local >> > > policy >> > > > override, probably policy.dmarc as described now in RFC 8616. >> > > > > Scott K >> > > > > >> > > > > On July 30, 2019 1:34:46 PM UTC, "Дилян Палаузов" >> > > > <dilyan.palau...@aegee.org> wrote: >> > > > > > Hello Scott, >> > > > > > >> > > > > > do you want to include in the A-R header the published >policy, as >> > > > > > obtained from DNS (my first interpretation of your >> > > > > > proposal), or the disposition of the message after applying >> > > > > > DKIM/SPF/DMARC validation, pct sampling, and the ominous >> > > > > > reject→quarantine sampling conversions? >> > > > > > >> > > > > > With disposition I mean what is called at >> > > > > > https://tools.ietf.org/html/rfc6591#section-3.2.2 >> > Delivery-Result. >> > > > > > For the disposition on p=reject only the MTA can make the >> > decision >> > > > > > based on pct to reject, so it makes sense if the >> > > > > > result of disposition is included in the A-R header by the >MTA >> > and >> > > > > > consumed by the MDA. In turn, including pct and >> > > > > > published DMARC policy in the A-R header, so that the MDA >can do >> > > > the >> > > > > > sampling, does not make sense. >> > > > > > >> > > > > > If you want to call the new parameter “policy”, then it >shall be >> > > > > > articulated that it means disposition, and not >> > > > > > published policy. >> > > > > > >> > > > > > I am in favour of the proposal. >> > > > > > >> > > > > > It allows for forwarded emails/aliases to indicate in the >A-R >> > > > header, >> > > > > > that sampling was already performed by the >> > > > > > aliasing server, and the final server that accepts the >email can >> > > > skip >> > > > > > performing the sampling again. Performing the >> > > > > > sampling again has the disadvantage, that the pct= >parameter is >> > > > > > misinterpreted, as the parameter is supposed to be >> > > > > > applied only once. >> > > > > > >> > > > > > On the other side, skipping of the second sampling by >whatever >> > > > server >> > > > > > is pure theory, and has no practical impact. >> > > > > > >> > > > > > Greetings >> > > > > > Дилян >> > > > > > >> > > > > > On Tue, 2019-07-30 at 00:54 -0400, Scott Kitterman wrote: >> > > > > > > On Monday, July 29, 2019 3:37:55 PM EDT Scott Kitterman >wrote: >> > > > > > > > I'd like to add the option to record DMARC results in >an A-R >> > > > header >> > > > > > field >> > > > > > > > for consumption by a downstream processor. I think it >would >> > > be >> > > > > > something >> > > > > > > > like this: >> > > > > > > > >> > > > > > > > Authentication-Results: mail-router.example.net; >dmarc=pass >> > > > > > > > header.from=example.com policy.dmarc=none >> > > > > > > > >> > > > > > > > That would take adding an entry in the Email >Authentication >> > > > Methods >> > > > > > registry >> > > > > > > > for: >> > > > > > > > >> > > > > > > > method: dmarc >> > > > > > > > ptype: policy >> > > > > > > > value: dmarc >> > > > > > > > >> > > > > > > > Does that make sense as a way to do it? Does anyone >have >> > > > > > alternative >> > > > > > > > suggestions? >> > > > > > > >> > > > > > > I think comments should be free-form. If we want data >that can >> > > > be >> > > > > > machine >> > > > > > > parsed, we should specify it. >> > > > > > > >> > > > > > > I think the above works in ABNF terms. It's: >> > > > > > > >> > > > > > > Authentication-Results:" authserv-id; method=result >> > > > > > ptype.property=value >> > > > > > > ptype.property=value >> > > > > > > >> > > > > > > According to the ABNF, there can be more than one >propspec >> > > > > > > (ptype.property=value) per methodspec in resinfo, so I >think >> > > it's >> > > > > > legal. It >> > > > > > > would just need the new registry values for dmarc. >> > > > > > > >> > > > > > > Scott K >> > > > > > > >> > > > > > > >> > > > > > > _______________________________________________ >> > > I know that Gmail and others put that information in the comments, > but that probably shouldn't be for something explicitly part of the > spec like this. > > Anyways, +1 to keeping p=quarantine as a concept, but willing to go > along with the consensus on naming. > > Brandon > _______________________________________________ > 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
