Re: [dmarc-ietf] Proposed text to close out Ticket 96
It appears that Scott Kitterman said: >I don't follow. Section 5.5 is called Domain Owner Actions. > >Also, that's the goal for some domains, but not others. We shouldn't >over-generalize. Personally, I publish DMARC records for the aggregate >reports. I find them useful. >Publishing a DMARC record with anything other than p=none is not something I'm >considering due to the associated side effects. I'm with Scott here. For some people the goal of DMARC is to stop phishing, for some to prevent BEC (not very well), for some to avoid support calls (you know who I mean), and for some of us, just to see what the statistics look like. With respect to domain owners, while they are entirely allowed to say what they want, we are equally allowed to ignore it. Early on a DMARC policy was a reasonably good indicator that a domain was a phish target and it's worth losing some of its real mail to deter the phishes, but these days as likely as not it's some consultant told us to do this so we're doing it. We all know domains where the policy implied by their DMARC record is obviously not what they actually want people to do nor what it is useful to do. I do think we can say something useful about reporting since comprehensive reports benefit everyone, even if you're not a phish target. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposed text to close out Ticket 96
On Wed, Apr 5, 2023, at 5:20 PM, Seth Blank wrote: > When we talk about DMARC and interoperability, we have to remember that there > are THREE participants within DMARC that need to interoperate, the sender, > the receiver, and the domain owner. We keep on discussing the sender and > receiver relationship, and leaving the domain owner out to dry. It's the > domain owner's authentication, and their policy, which DMARC is all about. > DMARC is nothing without domain owners. +1 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposed text to close out Ticket 96
On April 5, 2023 10:20:28 PM UTC, Seth Blank wrote: >On Wed, Apr 5, 2023 at 2:57 PM Scott Kitterman wrote: > >> My understanding is that the IETF doesn't do implementation >> specifications. I'm not sure what problem that's related to >> interoperability this is meant to address. >> >> I think the ticket should be closed without action > > >The purpose of DMARC from the point of view of a domain owner, is to stop >spoofing of their exact domain from unauthorized sources. > >The document describes certain mechanics of this relative to the Author >Domain, but never explains what doing this completely for the >Organizational Domain and its entire hierarchy looks like. As this is the >goal of many domain owners, it is worth clear definition in the document. > >When we talk about DMARC and interoperability, we have to remember that >there are THREE participants within DMARC that need to interoperate, the >sender, the receiver, and the domain owner. We keep on discussing the >sender and receiver relationship, and leaving the domain owner out to dry. >It's the domain owner's authentication, and their policy, which DMARC is >all about. DMARC is nothing without domain owners. > >This is clunky, because there's normally not a person or business in the >mix when we talk about interop. With DMARC, there is. Policy needs to work >as expected, and consistently. Therefore, we need clear definition. I can >see how this might look like implementation guidance if you're only >thinking about the bits moving between the sender and the receiver. In the >DMARC context, the domain owner's desires, and clarity on how to implement >them, are critical to be spelled out in the document. > >The text that I proposed feels like the minimum text needed to address this >clarity, without telling people what to do. I don't follow. Section 5.5 is called Domain Owner Actions. Also, that's the goal for some domains, but not others. We shouldn't over-generalize. Personally, I publish DMARC records for the aggregate reports. I find them useful. Publishing a DMARC record with anything other than p=none is not something I'm considering due to the associated side effects. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposed text to close out Ticket 96
On Wed, Apr 5, 2023 at 2:57 PM Scott Kitterman wrote: > My understanding is that the IETF doesn't do implementation > specifications. I'm not sure what problem that's related to > interoperability this is meant to address. > > I think the ticket should be closed without action The purpose of DMARC from the point of view of a domain owner, is to stop spoofing of their exact domain from unauthorized sources. The document describes certain mechanics of this relative to the Author Domain, but never explains what doing this completely for the Organizational Domain and its entire hierarchy looks like. As this is the goal of many domain owners, it is worth clear definition in the document. When we talk about DMARC and interoperability, we have to remember that there are THREE participants within DMARC that need to interoperate, the sender, the receiver, and the domain owner. We keep on discussing the sender and receiver relationship, and leaving the domain owner out to dry. It's the domain owner's authentication, and their policy, which DMARC is all about. DMARC is nothing without domain owners. This is clunky, because there's normally not a person or business in the mix when we talk about interop. With DMARC, there is. Policy needs to work as expected, and consistently. Therefore, we need clear definition. I can see how this might look like implementation guidance if you're only thinking about the bits moving between the sender and the receiver. In the DMARC context, the domain owner's desires, and clarity on how to implement them, are critical to be spelled out in the document. The text that I proposed feels like the minimum text needed to address this clarity, without telling people what to do. Seth, hatless -- *Seth Blank * | Chief Technology Officer *e:* s...@valimail.com *p:* 415.273.8818 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] Proposed text to close out Ticket 96
My understanding is that the IETF doesn't do implementation specifications. I'm not sure what problem that's related to interoperability this is meant to address. I think the ticket should be closed without action If you really think we need this, I think the Enforcement definition needs something about the domains (and subdomain) at issue either aren't affected by the interoperability issues discussed in 5.5.6 or has accepted the associated interoperability risk. It needs to be Barry's version of 5.5.6 that's the starting point for the new definitions (if we are going to have them at all, which I think we shouldn't). Scott K On April 5, 2023 9:34:51 PM UTC, Seth Blank wrote: >https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/96 > >I tried to write up an INFORMATIONAL paragraph, for ticket #96, and it kept >on coming out strangely and did not feel appropriate in the document as a >section unto itself. > >However, I think we can meet the intent of this ticket by condensing it >into two definitions for section 3.2, an added sentence to 5.5.4 and a new >paragraph in 5.5.6 (that stands regardless of the output of the other >thread in process on 5.5.6), as follows: > >3.2. > >Monitoring Mode: At p=none with a valid reporting address, the domain owner >receives reports that showcase authorized and unauthorized mail streams, as >well as gaps pertaining to authentication information pertaining to both >streams. > >Enforcement: When the Organizational Domain and all subdomains below it are >covered by a policy that is not none. This means that the domain and its >subdomains can only be used to send mail that is properly authenticated, >and mail using the domain name that is unauthenticated will not reach the >inbox of a mail receiver that validates DMARC. > >5.5.4 OLD > >Once SPF, DKIM, and the aggregate reports mailbox are all in place, it's >time to publish a DMARC record. For best results, Domain Owners usually >start with "p=none", (see Section 5.5.5) with the rua tag containing a URI >that references the mailbox created in the previous step. If the >Organizational Domain is different from the Author Domain, a record also >needs to be published for the Organizational Domain. > >5.5.4 NEW > >Once SPF, DKIM, and the aggregate reports mailbox are all in place, it's >time to publish a DMARC record. For best results, Domain Owners usually >start with "p=none", (see Section 5.5.5) with the rua tag containing a URI >that references the mailbox created in the previous step. This is commonly >referred to as putting the Author Domain into Monitoring Mode. If the >Organizational Domain is different from the Author Domain, a record also >needs to be published for the Organizational Domain. > >5.5.6 OLD > >Once the Domain Owner is satisfied that it is properly authenticating all >of its mail, then it is time to decide if it is appropriate to change the >p= value in its DMARC record to p=quarantine or p=reject. Depending on its >cadence for sending mail, it may take many months of consuming DMARC >aggregate reports before a Domain Owner reaches the point where it is sure >that it is properly authenticating all of its mail, and the decision on >which p= value to use will depend on its needs. > >5.5.6 NEW > >Once the Domain Owner is satisfied that it is properly authenticating all >of its mail, then it is time to decide if it is appropriate to change the >p= value in its DMARC record to p=quarantine or p=reject. Depending on its >cadence for sending mail, it may take many months of consuming DMARC >aggregate reports before a Domain Owner reaches the point where it is sure >that it is properly authenticating all of its mail, and the decision on >which p= value to use will depend on its needs. > >Some Domain Owners may wish to ensure a policy exists for the >Organizational Domain and all its subdomains, which is known as the >Organizational Domain being at Enforcement. This prevents the entire >Organizational domain's hierarchy from exact-domain spoofing. This is >difficult for many Domain Owners to achieve, as they must repeat the above >process to ensure mail is properly authenticated for each subdomain. Being >at Enforcement means an Organizational Domain has no recourse if Mediators >modify authentication information as outlined in section 8.5. > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Proposed text to close out Ticket 96
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/96 I tried to write up an INFORMATIONAL paragraph, for ticket #96, and it kept on coming out strangely and did not feel appropriate in the document as a section unto itself. However, I think we can meet the intent of this ticket by condensing it into two definitions for section 3.2, an added sentence to 5.5.4 and a new paragraph in 5.5.6 (that stands regardless of the output of the other thread in process on 5.5.6), as follows: 3.2. Monitoring Mode: At p=none with a valid reporting address, the domain owner receives reports that showcase authorized and unauthorized mail streams, as well as gaps pertaining to authentication information pertaining to both streams. Enforcement: When the Organizational Domain and all subdomains below it are covered by a policy that is not none. This means that the domain and its subdomains can only be used to send mail that is properly authenticated, and mail using the domain name that is unauthenticated will not reach the inbox of a mail receiver that validates DMARC. 5.5.4 OLD Once SPF, DKIM, and the aggregate reports mailbox are all in place, it's time to publish a DMARC record. For best results, Domain Owners usually start with "p=none", (see Section 5.5.5) with the rua tag containing a URI that references the mailbox created in the previous step. If the Organizational Domain is different from the Author Domain, a record also needs to be published for the Organizational Domain. 5.5.4 NEW Once SPF, DKIM, and the aggregate reports mailbox are all in place, it's time to publish a DMARC record. For best results, Domain Owners usually start with "p=none", (see Section 5.5.5) with the rua tag containing a URI that references the mailbox created in the previous step. This is commonly referred to as putting the Author Domain into Monitoring Mode. If the Organizational Domain is different from the Author Domain, a record also needs to be published for the Organizational Domain. 5.5.6 OLD Once the Domain Owner is satisfied that it is properly authenticating all of its mail, then it is time to decide if it is appropriate to change the p= value in its DMARC record to p=quarantine or p=reject. Depending on its cadence for sending mail, it may take many months of consuming DMARC aggregate reports before a Domain Owner reaches the point where it is sure that it is properly authenticating all of its mail, and the decision on which p= value to use will depend on its needs. 5.5.6 NEW Once the Domain Owner is satisfied that it is properly authenticating all of its mail, then it is time to decide if it is appropriate to change the p= value in its DMARC record to p=quarantine or p=reject. Depending on its cadence for sending mail, it may take many months of consuming DMARC aggregate reports before a Domain Owner reaches the point where it is sure that it is properly authenticating all of its mail, and the decision on which p= value to use will depend on its needs. Some Domain Owners may wish to ensure a policy exists for the Organizational Domain and all its subdomains, which is known as the Organizational Domain being at Enforcement. This prevents the entire Organizational domain's hierarchy from exact-domain spoofing. This is difficult for many Domain Owners to achieve, as they must repeat the above process to ensure mail is properly authenticated for each subdomain. Being at Enforcement means an Organizational Domain has no recourse if Mediators modify authentication information as outlined in section 8.5. -- *Seth Blank * | Chief Technology Officer *e:* s...@valimail.com *p:* 415.273.8818 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
