Re: [dmarc-ietf] p=quarantine

On Tue 22/Dec/2020 16:41:43 +0100 Todd Herr wrote: On Mon, Dec 21, 2020 at 12:47 PM Alessandro Vesely wrote: On Sun 20/Dec/2020 18:10:03 +0100 Todd Herr wrote: Lists are a specific instance of the more general case of indirect mail flows. >> How many kinds of indirect mail flows do rewrite

Re: [dmarc-ietf] p=quarantine

On 12/22/20 7:41 AM, Todd Herr wrote: My conundrum here is "Do I trust A's claim that the message was correctly DKIM signed by domain D with selector S?" which is why ARC brings nothing new to the table. it's not that it was correctly signed by the originator, it's whether i trust the

Re: [dmarc-ietf] p=quarantine

On Mon, Dec 21, 2020 at 12:47 PM Alessandro Vesely wrote: > On Sun 20/Dec/2020 18:10:03 +0100 Todd Herr wrote: > > > > Lists are a specific instance of the more general case of indirect mail > flows. > > > How many kinds of indirect mail flows do rewrite From:? > > Specific methods might prove

Re: [dmarc-ietf] p=quarantine

On Sun 20/Dec/2020 18:10:03 +0100 Todd Herr wrote: Lists are a specific instance of the more general case of indirect mail flows. How many kinds of indirect mail flows do rewrite From:? Specific methods might prove more effective than general ones. [...] Since the receiver typically

Re: [dmarc-ietf] p=quarantine

Like any security problem, we need to minimize false positives (desired mail being blocked) and false negatives (unwanted or malicious mail being allowed). ARC will hopefully address the false positives, but the false negative issue remains. The situation does not seem hopeless, but the topic

Re: [dmarc-ietf] p=quarantine

On Fri, Dec 18, 2020 at 4:55 PM Michael Thomas wrote: > > On 12/15/20 8:01 AM, Todd Herr wrote: > > > I'm not sure there's anything actionable about DMARC's policy values. > > you mean p=quarantine, or p=* in general? > Depending on the level of sophistication of a receiving email system, a

Re: [dmarc-ietf] p=quarantine

On Fri 18/Dec/2020 22:54:54 +0100 Michael Thomas wrote: In my opinion, ARC has promise, because if a message reaches me as a receiver or even intermediary and fails the authentication checks I perform, ARC header sets in the message can tell me whether or not such checks passed at previous

Re: [dmarc-ietf] p=quarantine

On 12/15/20 8:01 AM, Todd Herr wrote: I'm not sure there's anything actionable about DMARC's policy values. you mean p=quarantine, or p=* in general? Obviously indirect mail flows, such as mailing lists and forwarding, complicate matters greatly here, as the handling by the intermediary

Re: [dmarc-ietf] p=quarantine

Thank you Todd. I found this very helpful because it sets appropriately low expectations but also describes a framework that I can envision integrating into my filtering process. Some version of these concepts need to be worked into the bis or BCP document, so that product developers do not

Re: [dmarc-ietf] p=quarantine

On Mon, Dec 14, 2020 at 10:36 PM Michael Thomas wrote: > > On 12/14/20 7:26 PM, Douglas Foster wrote: > > > > But what I am trying to figure out is under what circumstances a DMARC > > policy can be considered actionable. Do I conclude that > > "p=quarantine" means "domain is still collecting

Re: [dmarc-ietf] p=quarantine

On Tue 15/Dec/2020 04:26:03 +0100 Douglas Foster wrote: Sorry about the confusion caused by my typing failures. What I meant: First party - From address aligns with SMTP address.  Can be validated with SPF or DKIM. Third party - From address and SMTP address are in different domains.  Can be

Re: [dmarc-ietf] p=quarantine

On Mon, Dec 14, 2020 at 10:26 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Sorry about the confusion caused by my typing failures. > What I meant: > First party - From address aligns with SMTP address. Can be validated > with SPF or DKIM. > Third party - From address and

Re: [dmarc-ietf] p=quarantine

On 12/14/20 7:26 PM, Douglas Foster wrote: But what I am trying to figure out is under what circumstances a DMARC policy can be considered actionable.  Do I conclude that "p=quarantine" means "domain is still collecting data, so results are unpredictable"?   Or do I conclude that it means

Re: [dmarc-ietf] p=quarantine

Sorry about the confusion caused by my typing failures. What I meant: First party - From address aligns with SMTP address. Can be validated with SPF or DKIM. Third party - From address and SMTP address are in different domains. Can be validated with DKIM only. I am open to suggestions for better

Re: [dmarc-ietf] p=quarantine

On 12/14/20 12:02 PM, Tim Wicinski wrote: All Can we please stop with the non constructive discussions here? It would be helpful to just rule anything about the semantics of p=reject as out of scope. It is what hijacked my original question for which I haven't gotten an answer. Mike

Re: [dmarc-ietf] p=quarantine

All Can we please stop with the non constructive discussions here? tim On Mon, Dec 14, 2020 at 1:27 PM Michael Thomas wrote: > > On 12/14/20 10:09 AM, Dave Crocker wrote: > > On 12/14/2020 10:00 AM, Michael Thomas wrote: > >> When we tell you it's not a problem, > > > > Except that the

Re: [dmarc-ietf] p=quarantine

On 12/14/20 10:09 AM, Dave Crocker wrote: On 12/14/2020 10:00 AM, Michael Thomas wrote: When we tell you it's not a problem, Except that the telling was by you.  Alone. And you've yet to respond to the observable fact that receivers have been ignoring the directive language. Or that many

Re: [dmarc-ietf] p=quarantine

On 12/14/2020 10:00 AM, Michael Thomas wrote: When we tell you it's not a problem, Except that the telling was by you.  Alone. And you've yet to respond to the observable fact that receivers have been ignoring the directive language. Or that many folk misunderstand the semantics of DKIM,

Re: [dmarc-ietf] p=quarantine

On 12/14/20 8:12 AM, Dave Crocker wrote: On 12/12/2020 10:57 AM, Michael Thomas wrote: As a developer for 40 years, I can safely say that reject or discardable or whatever it was in ssp are all abundantly clear and that nobody writing a filter would make the error that you keep insisting

Re: [dmarc-ietf] p=quarantine

On 12/14/2020 7:31 AM, Laura Atkins wrote: I am agnostic about moving the ‘what to do’ section. I think it makes sense to keep the sender definitions and the ways receivers can interpret those declarations close together. I'm pressing for clear separation because we've got an existing

Re: [dmarc-ietf] p=quarantine

On 12/12/2020 10:57 AM, Michael Thomas wrote: As a developer for 40 years, I can safely say that reject or discardable or whatever it was in ssp are all abundantly clear and that nobody writing a filter would make the error that you keep insisting that we would. An appeal to authority?  In

Re: [dmarc-ietf] p=quarantine

> On 14 Dec 2020, at 15:11, Douglas Foster > wrote: > > I called that a third-party message, since the RFC5321.MailFrom domain is > different from the RFC5322.From domain. No, you didn’t. Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From domain ) I think ‘first party’

Re: [dmarc-ietf] p=quarantine

> On 14 Dec 2020, at 15:10, Dave Crocker wrote: > > On 12/12/2020 10:51 AM, John R Levine wrote: >> On Sat, 12 Dec 2020, Dave Crocker wrote: p=reject: all mail sent from this domain should be aligned in a DMARC compliant way. We believe that unaligned mail is from unauthorized

Re: [dmarc-ietf] p=quarantine

I called that a third-party message, since the RFC5321.MailFrom domain is different from the RFC5322.From domain. I am open to revisions of how the boundaries should be defined, but as I said in my reply just now to Michael Hammer, we need to define those boundaries in a way that both sender and

Re: [dmarc-ietf] p=quarantine

On 12/12/2020 10:51 AM, John R Levine wrote: On Sat, 12 Dec 2020, Dave Crocker wrote: p=reject: all mail sent from this domain should be aligned in a DMARC compliant way. We believe that unaligned mail is from unauthorized senders so we ask receivers to reject it, even though that might mean

Re: [dmarc-ietf] p=quarantine

On Sun, Dec 13, 2020 at 5:41 PM Dotzero wrote: > > > On Sun, Dec 13, 2020 at 4:45 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> Based on this discussion, it seems evident that p=reject should include >> language about in-transit modifications which are outside the

Re: [dmarc-ietf] p=quarantine

> On 13 Dec 2020, at 21:44, Douglas Foster > wrote: > > Based on this discussion, it seems evident that p=reject should include > language about in-transit modifications which are outside the control of the > source domain, and consequently outside the ability of DMARC to guide >

Re: [dmarc-ietf] p=quarantine

On Sun, Dec 13, 2020 at 4:45 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Based on this discussion, it seems evident that p=reject should include > language about in-transit modifications which are outside the control of > the source domain, and consequently outside the

Re: [dmarc-ietf] p=quarantine

Based on this discussion, it seems evident that p=reject should include language about in-transit modifications which are outside the control of the source domain, and consequently outside the ability of DMARC to guide recipients.Extending from that, I thought it would be helpful to specify

Re: [dmarc-ietf] p=quarantine

On 12/12/20 10:42 AM, Dave Crocker wrote: As soon as this specification text, here, contains language about how this information is to be used, should be used, or could be used, it crosses over into creating confusion about expectations of receiver handling. As a developer for 40

Re: [dmarc-ietf] p=quarantine

On Sat, 12 Dec 2020, Dave Crocker wrote: p=reject: all mail sent from this domain should be aligned in a DMARC compliant way. We believe that unaligned mail is from unauthorized senders so we ask receivers to reject it, even though that might mean some of our authorized senders' mail is rejected

Re: [dmarc-ietf] p=quarantine

On 12/11/2020 9:37 AM, John Levine wrote: In article <1ac986ff-507b-4917-9c6d-d84e9337f...@wordtothewise.com> you write: aligned is not authorized by the domain owner and may be discarded or rejected by the recipient. Naah. p=reject: all mail sent from this domain should be aligned in a DMARC

Re: [dmarc-ietf] p=quarantine

On 12/11/2020 11:19 AM, Dotzero wrote:> On Fri, Dec 11, 2020 at 11:11 AM Hector Santos We are not doing reporting at this time. Not the main focus. That can come later as an augmented feature, in fact, we might consider it as a paid service to be sending thousands report out to domains.

Re: [dmarc-ietf] p=quarantine

In article <1ac986ff-507b-4917-9c6d-d84e9337f...@wordtothewise.com> you write: >p=none: mail sent by authorized users of this domain may or may not be aligned >in a DMARC compliant way. > >p=quarantine: mail sent by authorized users of this domain should be aligned >in a DMARC compliant >way.

Re: [dmarc-ietf] p=quarantine

> On 11 Dec 2020, at 17:07, Dave Crocker wrote: > > On 12/11/2020 8:32 AM, Kurt Andersen (b) wrote: >> Perhaps: >> none: not certain at all >> quarantine: I believe I've got control of all my sending, but am >> not 100% positive >> reject: I have control of all my sending; if

Re: [dmarc-ietf] p=quarantine

On 12/11/2020 8:32 AM, Kurt Andersen (b) wrote: Perhaps: none: not certain at all quarantine: I believe I've got control of all my sending, but am not 100% positive reject: I have control of all my sending; if it doesn't pass DMARC, it's use of the

Re: [dmarc-ietf] p=quarantine

On Thu, Dec 10, 2020 at 6:26 PM Dave Crocker wrote: > On 12/10/2020 6:01 PM, Kurt Andersen (b) wrote: > > I think that is much closer to the right semantic but highlights a > > problem that the mail coming from a particular domain probably doesn't > > rate a single broad-brush characterization

Re: [dmarc-ietf] p=quarantine

On 12/11/2020 11:10 AM, Hector Santos wrote: * SPF -ALL, REJECT - Receiver rejects at MAIL FROM state with a 550 response. Correction: * SPF -ALL, REJECT - Receiver rejects at RCPT TO state with a 550 response. SPF is only tested once a valid (existing) RCPT TO is provided. This was the

Re: [dmarc-ietf] p=quarantine

On Fri, Dec 11, 2020 at 11:11 AM Hector Santos wrote: > We are not doing reporting at this > time. Not the main focus. That can come later as an augmented > feature, in fact, we might consider it as a paid service to be sending > thousands report out to domains. > That's good community

Re: [dmarc-ietf] p=quarantine

On 12/10/2020 9:26 PM, Dave Crocker wrote: On 12/10/2020 6:01 PM, Kurt Andersen (b) wrote: I think that is much closer to the right semantic but highlights a problem that the mail coming from a particular domain probably doesn't rate a single broad-brush characterization of seriousness. I've

Re: [dmarc-ietf] p=quarantine

On 12/10/20 6:44 PM, Dave Crocker wrote: On 12/10/2020 6:32 PM, Michael Thomas wrote: Semantic nit picking at best. Because semantics do not matter in a specification? It's ok, I guess but I wouldn't want to make a career of nit picking. It's a lot more useful to get intent across of

Re: [dmarc-ietf] p=quarantine

On 12/10/2020 6:32 PM, Michael Thomas wrote: Semantic nit picking at best. Because semantics do not matter in a specification? d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org

Re: [dmarc-ietf] p=quarantine

On 12/10/2020 6:25 PM, Michael Thomas wrote: I think this all should be driven by "what are you asking me to do?" The domain owner has no business asking the receiver to do anything.  The receiver has no relationship with the domain owner. However, the receiver might like to hear the domain

Re: [dmarc-ietf] p=quarantine

On 12/10/2020 6:01 PM, Kurt Andersen (b) wrote: I think that is much closer to the right semantic but highlights a problem that the mail coming from a particular domain probably doesn't rate a single broad-brush characterization of seriousness. I've assumed the none, quarantine, reject

Re: [dmarc-ietf] p=quarantine

On 12/10/20 6:01 PM, Kurt Andersen (b) wrote: On Thu, Dec 10, 2020 at 5:03 PM Dave Crocker > wrote: On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote: to quibble with the "*unauthorized use*"  situation. This situation devolves into use-as-imagined vs.

Re: [dmarc-ietf] p=quarantine

On Thu, Dec 10, 2020 at 5:03 PM Dave Crocker wrote: > On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote: > > to quibble with the "*unauthorized use*" situation. This situation > devolves into use-as-imagined vs. use-as-really-used when one considers > various intermediary scenarios. > > (to

Re: [dmarc-ietf] p=quarantine

On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote: to quibble with the "*unauthorized use*"  situation. This situation devolves into use-as-imagined vs. use-as-really-used when one considers various intermediary scenarios. (to respond to the content...) So, the driving issue is that it's

Re: [dmarc-ietf] p=quarantine

On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote: but I'd have to quibble with the "*unauthorized use*"  situation. please do quibble. or more. I intended the text to prime the pump, and don't have any expectation is is already perfect. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791

Re: [dmarc-ietf] p=quarantine

On Wed, Dec 9, 2020 at 10:09 AM Dave Crocker wrote: > It might be worth a bit of thinking about what, exactly, DMARC can > reasonably do and how it should be summarized, for popular consumption: > > *Alignment - *DMARC defines a basis for authenticating use of the domain > name in the

Re: [dmarc-ietf] p=quarantine

On 12/9/2020 9:52 AM, tjw ietf wrote: Obviously the domain owner has no 'authority' over those using the domain without authorization.  For this latter set of folk, the most the domain owner can do is provide information to receivers of unauthorized use. It might be worth a bit of thinking

Re: [dmarc-ietf] p=quarantine

I agree strongly with Dave on creating boring and precise terminology/references, and they are used over and over. Tim Sent from my iPhone > On Dec 9, 2020, at 12:40, Dave Crocker wrote: >  > On 12/8/2020 12:11 PM, Dotzero wrote: >> Note that I asked Two questions. Your answer appears

Re: [dmarc-ietf] p=quarantine

On 12/8/2020 12:11 PM, Dotzero wrote: Note that I asked Two questions. Your answer appears directed to the second question. The answer to the first question appears fairly clear to me. Administrators of a system can restrict or delete a user account. It really is as simple as that. So in that

Re: [dmarc-ietf] p=quarantine

In article you write: >-=-=-=-=-=- > >Note that I asked Two questions. Your answer appears directed to the second >question. The answer to the first question appears fairly clear to me. >Administrators of a system can restrict or delete a user account. It depends what agreements they might have

Re: [dmarc-ietf] p=quarantine

Dotzero skrev den 2020-12-08 19:50: And here we get to some of the crucial unresolved questions involving email: "Does the wishes of a user of an account at a domain supercede the policies of the domain owner/administrator of a domain?" "Does a domain owner/administrator have the right to

Re: [dmarc-ietf] p=quarantine

Note that I asked Two questions. Your answer appears directed to the second question. The answer to the first question appears fairly clear to me. Administrators of a system can restrict or delete a user account. It really is as simple as that. So in that respect the answer is that ultimately an

Re: [dmarc-ietf] p=quarantine

On 12/8/2020 10:50 AM, Dotzero wrote: And here we get to some of the crucial unresolved questions involving email: "Does the wishes of a user of an account at a domain supercede the policies of the domain owner/administrator of a domain?" It's not only not crucial, it's entirely resolved, and

Re: [dmarc-ietf] p=quarantine

On Tue, Dec 8, 2020 at 12:42 PM Michael Thomas wrote: > > If you take the literal meaning of quarantine, that means that every > piece of email from this and every other mailing list would end up in a > quarantine folder, or some such. I'm fairly certain that is not what > people want, and I'm

[dmarc-ietf] p=quarantine

If you take the literal meaning of quarantine, that means that every piece of email from this and every other mailing list would end up in a quarantine folder, or some such. I'm fairly certain that is not what people want, and I'm doubtful that many receivers implement that. The question to