Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

[Tim Wicinski]

Alex

It is in charter, so it would be worth discussing.  It could also be
Informational and not Standards Track, which could be useful.

tim


On Mon, Apr 1, 2024 at 1:52 PM Brotman, Alex  wrote:

> To Tim’s note below, should the group create an operational guidance
> document for DMARCbis? This could allow for more lengthy discussions around
> policy decisions, and move that discussion out of the technical document.
>
>
>
> --
>
> Alex Brotman
>
> Sr. Engineer, Anti-Abuse & Messaging Policy
>
> Comcast
>
>
>
> *From:* dmarc  *On Behalf Of * Tim Wicinski
> *Sent:* Monday, April 1, 2024 12:17 PM
> *To:* Dotzero 
> *Cc:* Brotman, Alex ;
> dmarc@ietf.org
> *Subject:* Re: [dmarc-ietf] SPF follies, WGLC editorial review of
> draft-ietf-dmarc-dmarcbis-30
>
>
>
> I have to agree with Seth's comments that "security teams believe an SPF
> hard fail is more secure".
>
> I've been on the receiving end of that discussion more than once.
>
>
>
> Also, can we reference those two M3AAWG documents ?  That seems like
> operational guidance.
>
>
>
> tim
>
>
>
>
>
> On Mon, Apr 1, 2024 at 8:55 AM Dotzero  wrote:
>
>
>
>
>
> On Mon, Apr 1, 2024 at 8:18 AM Brotman, Alex  40comcast@dmarc.ietf.org> wrote:
>
> One item left out of Seth’s text is that due to MBPs who act in this
> fashion, these SPF evaluation failures will (understandably) not show up in
> DMARC reports, and the domain owner may not have visibility for these
> failures.  However, the text also puts the onus on the domain owner instead
> of the MBP.  The text could be altered to instead suggest that MBPs who
> deploy DMARC should not utilize the outcome of SPF in this fashion.  If the
> domain owner wants to protect their domain, and has no idea if the MBP
> supports DMARC properly (presuming they also have an enforcing policy), is
> it more or less advisable to use “-all” with your SPF record?
>
>
>
> I’d be curious to see the Venn diagram of MBPs who implement SPF in this
> fashion, and also fully support DMARC.  I feel like the MBPs who I’ve
> encountered deploying an SPF check in this way had not at the time
> supported DMARC.
>
>
>
> --
>
> Alex Brotman
>
> Sr. Engineer, Anti-Abuse & Messaging Policy
>
> Comcast
>
>
>
> I was just thinking along these lines and was going to post but you beat
> me to the punch.
>
>
>
> +1
>
>
>
> Michael Hammer
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!Fb-J3cXtCi-g9GrtAS4dOqVZX7mqGuHPpsx_WiInM3oaf51dbfoNWfZ8G67ACgtN7VjFXXC2eIvT794GNh4R$>
>
> ___
> 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] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

[Tim Wicinski]

On Mon, Apr 1, 2024 at 12:27 PM Todd Herr  wrote:

> On Mon, Apr 1, 2024 at 12:17 PM Tim Wicinski  wrote:
>
>> I have to agree with Seth's comments that "security teams believe an SPF
>> hard fail is more secure".
>> I've been on the receiving end of that discussion more than once.
>>
>> Also, can we reference those two M3AAWG documents ?  That seems like
>> operational guidance.
>>
>>
> I'm digesting the threads for the purpose of preparing tickets to track
> the work, and I suspect one of the tickets will include, "Add reference
> to the following two M3AAWG documents":
>
>1.
>
> https://www.m3aawg.org/sites/default/files/m3aawg_managing-spf_records-2017-08.pdf
>2.
>
> https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf
>
>
>

Todd,

Yes, those seem like the documents I found on the m3aawg site.

I had recently read the "Past and Future of the PSL" document to use as a
possible reference, but it did not seem to make sense to me.

tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

[Tim Wicinski]

I have to agree with Seth's comments that "security teams believe an SPF
hard fail is more secure".
I've been on the receiving end of that discussion more than once.

Also, can we reference those two M3AAWG documents ?  That seems like
operational guidance.

tim


On Mon, Apr 1, 2024 at 8:55 AM Dotzero  wrote:

>
>
> On Mon, Apr 1, 2024 at 8:18 AM Brotman, Alex  40comcast@dmarc.ietf.org> wrote:
>
>> One item left out of Seth’s text is that due to MBPs who act in this
>> fashion, these SPF evaluation failures will (understandably) not show up in
>> DMARC reports, and the domain owner may not have visibility for these
>> failures.  However, the text also puts the onus on the domain owner instead
>> of the MBP.  The text could be altered to instead suggest that MBPs who
>> deploy DMARC should not utilize the outcome of SPF in this fashion.  If the
>> domain owner wants to protect their domain, and has no idea if the MBP
>> supports DMARC properly (presuming they also have an enforcing policy), is
>> it more or less advisable to use “-all” with your SPF record?
>>
>>
>>
>> I’d be curious to see the Venn diagram of MBPs who implement SPF in this
>> fashion, and also fully support DMARC.  I feel like the MBPs who I’ve
>> encountered deploying an SPF check in this way had not at the time
>> supported DMARC.
>>
>>
>>
>> --
>>
>> Alex Brotman
>>
>> Sr. Engineer, Anti-Abuse & Messaging Policy
>>
>> Comcast
>>
>>
> I was just thinking along these lines and was going to post but you beat
> me to the punch.
>
> +1
>
> Michael Hammer
> ___
> 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] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

[Tim Wicinski]

"Explaining how DNS works is out of scope."

Scott is right.

Also, some folks point use something other than CNAME

$  dig +noall +answer _dmarc.valimail.com ns
_dmarc.valimail.com. 300 IN NS ns.vali.email.

tjw@m2[1098]:  dig +noall +answer _dmarc.valimail.com txt
_dmarc.valimail.com. 595 IN TXT "v=DMARC1; p=reject; rua=mailto:
dmarc_agg@vali.email,mailto:dmarc.repo...@valimail.com;

On Thu, Mar 14, 2024 at 5:12 PM Todd Herr  wrote:

> On Thu, Mar 14, 2024 at 5:05 PM Mark Alley  40tekmarc@dmarc.ietf.org> wrote:
>
>> On 3/14/2024 3:49 PM, Todd Herr wrote:
>>
>> On Thu, Mar 14, 2024 at 4:43 PM Mark Alley > 40tekmarc@dmarc.ietf.org> wrote:
>>
>>> On 3/14/2024 3:38 PM, Todd Herr wrote:
>>>
>>> On Thu, Mar 14, 2024 at 4:34 PM Scott Kitterman 
>>> wrote:
>>>

 I think this is correct.  I think it's obviously enough correct that
 I'm surprised anyone was confused.

 Do we know what the theory was that led people to think otherwise?

 Seems to me we don't really need this, but maybe there's a reason.


>>> The reasons given were:
>>>
>>>1. https://www.rfc-editor.org/rfc/rfc5863#section-4.1
>>>2. https://datatracker.ietf.org/doc/html/rfc6376#section-7.5
>>>3. Neither RFC 7489 nor DMARCbis contain the phrase "CNAME", so if
>>>it's not explicitly mentioned...
>>>
>>> Granted, the first two citations are in regards to DKIM records, not
>>> DMARC records, but those were the reasons given.
>>>
>>> Couldn't hurt to clarify explicitly, I'm for it. Domain owners have been
>>> using CNAMEs with DMARC TXT RRs pretty much since its inception.
>>>
>> I agree that clarifying it can't hurt, obviously, but I was quite
>> surprised to hear that CNAMEs were being published for DMARC records, as
>> I'd never seen one. On the other hand, I've seen *lots* of DKIM public keys
>> published as CNAMEs, which I'm sure just wrecks the person citing DKIM RFCs
>> as a reason that DMARC records can't be CNAMEs.
>>
>>
>> Domain owner use cases with DMARC CNAMEs boils down to really either of 2
>> things:
>>
>>- Single point of policy management for orgs with dozens, hundreds,
>>or thousands of domains to manage DMARC on, and also applicable to RUA/RUF
>>addresses.
>>- Delegation to a third-party for management, similar to DKIM CNAMEs
>>as you noted that are popularly in use by many ESPs for vendor-managed key
>>rotation.
>>
>>
> Yup, I grok the use cases. I just hadn't thought of them prior to this
> discussion.
>
> --
>
> Todd Herr | Technical Director, Standards & Ecosystem
> Email: todd.h...@valimail.com
> Phone: 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

[Tim Wicinski]

There are folks who publish NS records at _dmarc.example.com that point to
some super fancy DNS service that return DMARC TXT records.

tim


On Thu, Mar 14, 2024 at 4:19 PM Todd Herr  wrote:

> Colleagues,
>
> There was a discussion among M3AAWG members on March 13 that centered on
> the question of whether DMARC records can be published in DNS as CNAMEs,
> e.g.,
>
> _dmarc.example.com IN CNAME _dmarc.example.org
>
> _dmarc.example.org IN TXT "v=DMARC1; p=reject; rua=
> mailto:dmarc-repo...@example.org ;"
>
> Section 3.6.2 of RFC 1034 seems to indicate that it is permissible to
> publish DMARC records in this fashion, and describes the following scenario
> using an CNAME record and an A record:
>
> For example, suppose a name server was processing a query with for USC-
>
> ISIC.ARPA, asking for type A information, and had the following resource
>
> records:
>
> USC-ISIC.ARPA   IN  CNAME   C.ISI.EDU
>
> C.ISI.EDU   IN  A   10.0.0.52
>
> Both of these RRs would be returned in the response to the type A query,
>
> while a type CNAME or * query should return just the CNAME.
>
> I recommend adding a paragraph to DMARCbis, section 5.1 DMARC Policy
> Record at the end of that section that reads:
>
> Per RFC 1034 section 3.6.2, a DMARC record MAY be published as a CNAME
> record, so long as the corresponding canonical name ultimately resolves to
> a TXT record so as to ensure that queries of type TXT return a DNS RR in
> the expected format.
>
> Issue 136 has been opened for this.
>
> --
>
> Todd Herr | Technical Director, Standards & Ecosystem
> Email: todd.h...@valimail.com
> Phone: 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] picking nits with the ABNF

[Tim Wicinski]

On Sat, Mar 9, 2024 at 10:33 PM OLIVIER HUREAU <
olivier.hur...@univ-grenoble-alpes.fr> wrote:

> >> dmarc-version = "v" equals %s"DMARC1
> > I believe the "%s" should be dropped
>
> 'DMARC1' is case-sensitive in 7489.
> Either we keep the "%s" or we go back to 7489 version : "%x44 %x4d %x41
> %x52 %x43 %x31"
>
> Oh yes you are right - thanks


> I think it should be %x20-3A /  %x3C-7E
> Agreed.
>
> I would also add comment about the dmarc-fo ABNF :
>
> dmarc-fo  = "0" / "1" / "d" / "s" / "d:s" / "s:d"
>
> The FO paragraph (
> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-30.html#name-general-record-format)
> explicitly states that there exist 3 kinds of failure reports :
> - DMARC failure report.
> - DKIM failure report.
> - SPF failure report.
>
>
You got me going back to 7489 and the mail archives.  First it appears we
did have some discussion about this part of the ABNF
https://mailarchive.ietf.org/arch/msg/dmarc/2TT-2WiNVwCXozBz0JYRI1F1qME/

However, with the current ABNF, we could only ask for "DMARC failure
> report" or ("DKIM failure report" and/or "SPF failure report")
>
>
Shouldn't we have an ANBF rule with all the possible permutations or a more
> generic one such as :
>
> dmarc-fo = dmarc-fo-value *(":" dmarc-fo-value)
> dmarc-fo-value = "0" / "1" / "d" / "s"
>
>
The wording for FO has changed to say "0", "1" OR a colon-separated list.
Looking at the 7489 ABNF I
am wondering if someone could say "fo=0:1:d:s"

thanks
tim



> Olivier
>
> --
> *De: *"Tim Wicinski" 
> *À: *"IETF DMARC WG" 
> *Envoyé: *Dimanche 10 Mars 2024 01:00:33
> *Objet: *[dmarc-ietf] picking nits with the ABNF
>
> Just picking over the ABNF with my checks, some Qs
>
>
> dmarc-version = "v" equals %s"DMARC1
>
>
> I believe the "%s" should be dropped
>
>   dmarc-value   = %x20-3A |  %x3C-7E
>
>
> I think it should be %x20-3A /  %x3C-7E
>
> and now just something suggested.  The comments for URI read like this
>
> ; "URI" is imported from [RFC3986]; commas
> ; (ASCII 0x2C) and exclamation points
> ; (ASCII 0x21) MUST be encoded
>
> Could they be rewritten for readability
>
> ; "URI" is imported from [RFC3986];
> ; (ASCII 0x2C) commas and
> ; (ASCII 0x21) exclamation points
> ; MUST be encoded
>
> gladly tell me i'm too obsessive
>
>
> thanks
> tim
>
>
>
> ___
> 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] Section 9.5 DMARC Report Format Registry

[Tim Wicinski]

Re-reading section 9.5, I think we should rewrite this to mention the
registry being deprecated.

I open an issue on this

tim


On Fri, Mar 8, 2024 at 12:00 PM Tim Wicinski  wrote:

>
> Generally they will leave it and mark Obsolete.  This should be called out
> in the RFC.
> (I have not looked right now).
>
> tim
>
>
> On Fri, Mar 8, 2024 at 11:42 AM Murray S. Kucherawy 
> wrote:
>
>> On Fri, Mar 8, 2024 at 6:49 AM Alessandro Vesely  wrote:
>>
>>> since we removed the rf= tag (format of failure reports), do we still
>>> need to tackle the IANA registry?  Since we only use one format, it
>>> makes little sense.  However, the registry actually exists.  Is it
>>> possible to delete or obsolete it, or does it have to stay there as a
>>> relict for ever?
>>>
>>
>> I'm guessing it's possible for us to direct IANA to destroy a registry,
>> or (more likely) leave a tombstone page in its place.  I'll ask.
>>
>> -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

[dmarc-ietf] picking nits with the ABNF

[Tim Wicinski]

Just picking over the ABNF with my checks, some Qs


dmarc-version = "v" equals %s"DMARC1


I believe the "%s" should be dropped

  dmarc-value   = %x20-3A |  %x3C-7E


I think it should be %x20-3A /  %x3C-7E

and now just something suggested.  The comments for URI read like this

; "URI" is imported from [RFC3986]; commas
; (ASCII 0x2C) and exclamation points
; (ASCII 0x21) MUST be encoded

Could they be rewritten for readability

; "URI" is imported from [RFC3986];
; (ASCII 0x2C) commas and
; (ASCII 0x21) exclamation points
; MUST be encoded

gladly tell me i'm too obsessive


thanks
tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] A.5 Issues with ADSP in Operation

[Tim Wicinski]

I agree with Ale here - ADSP was moved to Historic in 2013.  Appendix A.5
should be dropped, and some text in the document should mention ADSP is
historic

On Sat, Mar 9, 2024 at 10:05 AM Alessandro Vesely  wrote:

> Hi,
>
> as ADSP is historical, perhaps we can strike A5 entirely.  If not, we
> should at least eliminate bullet 5:
>
> 5.  ADSP has no support for a slow rollout, i.e., no way to configure
> a percentage of email on which the Mail Receiver should apply the
> policy.  This is important for large-volume senders.
>
> (Alternatively, we could think back about pct=...?)
>
> 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] Section 9.5 DMARC Report Format Registry

[Tim Wicinski]

Generally they will leave it and mark Obsolete.  This should be called out
in the RFC.
(I have not looked right now).

tim


On Fri, Mar 8, 2024 at 11:42 AM Murray S. Kucherawy 
wrote:

> On Fri, Mar 8, 2024 at 6:49 AM Alessandro Vesely  wrote:
>
>> since we removed the rf= tag (format of failure reports), do we still
>> need to tackle the IANA registry?  Since we only use one format, it
>> makes little sense.  However, the registry actually exists.  Is it
>> possible to delete or obsolete it, or does it have to stay there as a
>> relict for ever?
>>
>
> I'm guessing it's possible for us to direct IANA to destroy a registry, or
> (more likely) leave a tombstone page in its place.  I'll ask.
>
> -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] Working Group Last Call on draft-ietf-dmarc-dmarcbis-30

[Tim Wicinski]

Sorry all, I submitted
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/125 with
some spelling nits,
Not realizing all the work Todd put into Issue 121.

tim


On Thu, Feb 29, 2024 at 4:27 PM Todd Herr  wrote:

> On Thu, Feb 29, 2024 at 10:10 AM Todd Herr  wrote:
>
>> On Thu, Feb 29, 2024 at 9:58 AM OLIVIER HUREAU <
>> olivier.hur...@univ-grenoble-alpes.fr> wrote:
>>
>>> Would you prefer one comment/issue or in batch?
>>>
>>
>> I would prefer that Barry's request be honored from his original post in
>> this thread, to wit:
>>
>> If you have significant issues to raise that have not already been
>> discussed and closed, please post each of those as a separate thread.
>> Minor issues and editorial comments can just be posted here, to this
>> thread, and we can split them off if necessary.
>>
>>
>> As I wrote:
>>
>> I'll be tracking minor issues and editorial comments in Github Issue 121,
>>> which I've cleverly titled "WGLC Minor Issues and Editorial Comments".
>>>
>>
>> so I can pull the minor issues and comments from this thread into that
>> Github Issue.
>>
>
> Just completed a full reading of the DMARCbis document, and here are the
> minor nits I've collected in Github Issue 121:
>
>
>- Kurt Andersen's name is spelled incorrectly (Anderson) in the
>section titled "Acknowledgements - RFC 7489"
>- Introduction section: Move the word 'in' to outside the quotes in
>the phrases: "in strict alignment" and "in relaxed alignment"
>- 2.1 High-Level Goals: Perhaps flip-flop the first two bullet points
>- 2.2 Anti-Phishing: Change "" to "display-name" and
>make it link to RFC 5322 Section 3.4
>- 2.3 Scalability: Change first sentence to read "Scalability is a
>significant issue for systems that need to operate in *an environment* as
>widely deployed as current SMTP email.
>- 3.2.4 Enforcement: Change "mail using the domain name that is
>unauthenticated" to "unauthenticated mail using the domain name"
>- 4.7 DMARC Policy Discovery: In the following paragraph:
>
> "Handling of DNS errors when querying for the DMARC policy record is left
> to the discretion of the Mail Receiver. For example, to ensure minimal
> disruption of mail flow, transient errors could result in delivery of the
> message ("fail open"), or they could result in the message being
> temporarily rejected (i.e., an SMTP 4yx reply), which invites the sending
> MTA to try again after the condition has possibly cleared, allowing a
> definite DMARC conclusion to be reached ("fail closed")."
>
> should the word 'or' be inserted before the last clause 'allowing a
> definite DMARC conclusion to be reached ("fail closed")'?
>
>- 5.3 General Record Format - The definitions of the rua and ruf tags
>are a bit messy; they should be worded essentially identically, i.e.,
>Here's what the tag means, receivers must support mailto:,
>$OTHER_DOCUMENT discusses third party receiver considerations and the
>format of these reports. (I may break this out into its own ticket/issue
>with proposed text.)
>- 5.3 General Record Format - Add link to Appendix A.7 in description
>of the 't' tag.
>- 5.7.1 Extract Author Domain - Change MAY to may
>- 7.6 Expansion of Domain Owner Actions Section - Change "domain
>owner" to "Domain Owner"
>
>
>
> --
>
> *Todd Herr * | Technical Director, Standards & Ecosystem
> *e:* todd.h...@valimail.com
> *p:* 703-220-4153
> *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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Codifying "Apex Domain"?

[Tim Wicinski]

Todd

I hate to get all DNS-y on you but the DNS terminology draft discusses Apex
and Origin in regards to Zones/Domains:

https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc8499bis-10.html#name-zones

(DNSOP spent 6 months trying to clean up the definition of "Glue Records"
to some success)

tim


On Thu, Nov 9, 2023 at 9:40 AM Todd Herr  wrote:

> Colleagues,
>
> I note that lately in various email fora that the term "apex domain" has
> found some favor, said term being used interchangeably with "organizational
> domain", and having the same contextual meaning as "organizational domain".
>
> DMARCbis does not contain the word "apex", nor did RFC 7489 before it.
>
> My question here is, should DMARCbis at least mention the term "apex
> domain", perhaps in section 3.2.9, Organizational Domain. The entirety of
> that section currently reads:
>
> The Organizational Domain for any domain is determined by applying the
> algorithm found in Section 4.8
> 
> .
>
>
> Does it make sense to change that to
>
> The Organizational Domain for any domain is determined by applying the
> algorithm found in Section 4.8
> .
> The Organizational Domain is also sometimes referred to as the Apex Domain.
>
>
> Discuss...
>
> --
>
> *Todd Herr * | Technical Director, Standards & Ecosystem
> *e:* todd.h...@valimail.com
> *p:* 703-220-4153
> *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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

[Tim Wicinski]

On Sun, Aug 6, 2023 at 7:14 AM Alessandro Vesely  wrote:

> On Sat 05/Aug/2023 22:24:28 +0000 Tim Wicinski wrote:
> >
> > [...]
> >
> > 5.3.  General Record Format
> >
> >
> > auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
> default is "spf,dkim")
> >
> >  Indicates the supported authentication methods.  The order of the
> list is not significant and
> >  unknown methods are ignored.  Possible values are as follows:
> >
> >  dkim: Authenticate with DKIM
> >
> >  spf: Authenticate with SPF
> >
> >
> >  An empty list indicates the tag is ignored.
>
>
> According to the grammar below, an empty list is a syntax error.  I'd keep
> the syntax as is and remove the line mentioning an empty list.
>
>
Ale

Good catch - but why not say "an empty list is a syntax error".  That is
useful (to me, others may see it otherwise)

tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

[Tim Wicinski]

On Sat, Aug 5, 2023 at 7:38 PM Dave Crocker  wrote:

> On 8/5/2023 4:23 PM, Neil wrote:
>
>  Also, we understand who our audiences are in reality. Sometimes it’ll be
> a harried admin skimming the RFC, and others will take the time to do a
> deep dive. Even the harried admin scanning today might want to dive deep
> when he has more time. So out of respect for those who want to get things
> done and solve problems quickly and those who wish to grok the new DMARC
> spec, I think the optimal solution would be to follow E.B. White, making
> every word count, having empathy for the reader, and avoiding distractions
> that could bog the stressed reader down.
>
> When writing specifications, yes, it is good to consider the casual or
> harried reader.  To that end, vocabulary should not mislead.  'Policy'
> misleads about the effect of choosing a particular value.
>

The other thing I've found that has proven useful in DNS RFCs, and that
I've received positive feedback outside of IETF is when we can summarize
definitions or guidance with tables.  Two stand out - the table at the
bottom of page 25 in RFC8499 showing examples of zone delegation types:

https://datatracker.ietf.org/doc/html/rfc8499#page-25

and the table in RFC8624 listing implementation recommendations for DNSSEC
algorithms

https://datatracker.ietf.org/doc/html/rfc8624#section-3.1

The former resonates with harried admins, while the later is useful
to implementers.

I am not saying we must do this, or we can, but it's something to
consider.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

[Tim Wicinski]

That is more accurate Scott.

Also I removed an extra sentence on comma-separated.

Updated https://gist.github.com/moonshiner/70377e69d482e7bf3a927d5ac468babb


5.3.  General Record Format


auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL; default
is "spf,dkim")

Indicates the supported authentication methods.  The order of the list
is not significant and

unknown methods are ignored.  Possible values are as follows:

dkim: Authenticate with DKIM

spf: Authenticate with SPF


An empty list indicates the tag is ignored.


If any listed method passes and is aligned, then DMARC passes.



5.4.  Formal Definition



dmarc-method = "dkim" / "spf"


dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method)



I did not word smith Wei's 4.3 text.

On Sat, Aug 5, 2023 at 6:17 PM Scott Kitterman  wrote:

> On Saturday, August 5, 2023 6:11:03 PM EDT Tim Wicinski wrote:
> > On Sat, Aug 5, 2023 at 6:00 PM Scott Kitterman 
> wrote:
> > > On August 5, 2023 9:51:54 PM UTC, Tim Wicinski 
> wrote:
> > > >On Sat, Aug 5, 2023 at 5:35 PM John Levine  wrote:
> > > >> According to Tim Wicinski  :
> > > >> >-=-=-=-=-=-
> > > >> >
> > > >> >Based on the ABNF in -28, how about something like this:
> > > >> >
> > > >> >
> > > >> >dmarc-method = "dkim" / "spf"
> > > >> >
> > > >> >dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP
> dmarc-method)
> > > >
> > > >1) I realize we may need someway to update the dmarc-method if a new
> one
> > >
> > > is
> > >
> > > >added (okay okay)
> > > >
> > > >> That looks OK, with large clear text saying that if any of the
> listed
> > > >> methods pass, it's aligned.
> > > >
> > > >2) I missed Scott's comment the default should be "spf,dkim"
> > > >
> > > >I wordsmithed Wei's definition  above for Section 5.3
> > > >
> > > >  auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
> > > >
> > > >default is "spf,dkim")
> > > >
> > > >Indicates the supported authentication methods. If more than one
> > >
> > > method
> > >
> > > >is specified,
> > > >
> > > >they are comma ',' separated without whitespace.  The order of the
> > >
> > > list
> > >
> > > >is not significant and
> > > >
> > > >unknown methods are ignored.  Possible values are as follows:
> > > >dkim: Authenticate with DKIM
> > > >spf: Authenticate with SPF
> > > >
> > > >An empty list indicates no authentication method is specified and
> > >
> > > DMARC
> > >
> > > >is disabled.
> > > >
> > > >If any listed method passes, then DMARC is aligned.
> > > >
> > > >Should I do a pull request etc, etc?
> >
> > Scott
> >
> > I'd prefer an empty list means the tag is ignored.  I don't see a use
> case
> >
> > > for publishing a record that means DMARC is disabled.  Also, I think
> it's
> > > confusing.  I would find it more natural to mean no auth methods are
> used
> > > (i.e. everything fails), not DMARC is disabled.  The canonical method
> for
> > > disabiling DMARC is to not publish a record.  I don't think we need
> > > another
> > > way to express the same thing in a less clear way.
> >
> > Agreed.
> >
> >   auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
> > default is "spf,dkim")
> > Indicates the supported authentication methods. If more than one
> method
> > is specified,
> > they are comma ',' separated without whitespace.  The order of the
> list
> > is not significant and
> > unknown methods are ignored.  Possible values are as follows:
> > dkim: Authenticate with DKIM
> > spf: Authenticate with SPF
> >
> > An empty list indicates the tag is ignored.
> >
> > If any listed method passes, then DMARC is aligned.
> >
> > https://gist.github.com/moonshiner/70377e69d482e7bf3a927d5ac468babb
> >
> >
> > also " I don't think we need another way to express the same thing in a
> > less clear way."
> >
> > +eleventy billion
>
> I missed this before ...
>
> Shouldn't "If any listed method passes, then DMARC is aligned." be "If any
> listed method passes and is aligned, then DMARC passes."?
>
> Scott K
>
>
> ___
> 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] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

[Tim Wicinski]

On Sat, Aug 5, 2023 at 6:00 PM Scott Kitterman  wrote:

>
>
> On August 5, 2023 9:51:54 PM UTC, Tim Wicinski  wrote:
> >On Sat, Aug 5, 2023 at 5:35 PM John Levine  wrote:
> >
> >> According to Tim Wicinski  :
> >> >-=-=-=-=-=-
> >> >
> >> >Based on the ABNF in -28, how about something like this:
> >> >
> >> >
> >> >dmarc-method = "dkim" / "spf"
> >> >
> >> >dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method)
> >>
> >>
> >1) I realize we may need someway to update the dmarc-method if a new one
> is
> >added (okay okay)
> >
> >
> >
> >
> >> That looks OK, with large clear text saying that if any of the listed
> >> methods pass, it's aligned.
> >>
> >
> >2) I missed Scott's comment the default should be "spf,dkim"
> >
> >I wordsmithed Wei's definition  above for Section 5.3
> >
> >  auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
> >default is "spf,dkim")
> >Indicates the supported authentication methods. If more than one
> method
> >is specified,
> >they are comma ',' separated without whitespace.  The order of the
> list
> >is not significant and
> >unknown methods are ignored.  Possible values are as follows:
> >dkim: Authenticate with DKIM
> >spf: Authenticate with SPF
> >
> >An empty list indicates no authentication method is specified and
> DMARC
> >is disabled.
> >
> >If any listed method passes, then DMARC is aligned.
> >
> >Should I do a pull request etc, etc?
>
>
Scott

I'd prefer an empty list means the tag is ignored.  I don't see a use case
> for publishing a record that means DMARC is disabled.  Also, I think it's
> confusing.  I would find it more natural to mean no auth methods are used
> (i.e. everything fails), not DMARC is disabled.  The canonical method for
> disabiling DMARC is to not publish a record.  I don't think we need another
> way to express the same thing in a less clear way.
>
>
Agreed.

  auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
default is "spf,dkim")
Indicates the supported authentication methods. If more than one method
is specified,
they are comma ',' separated without whitespace.  The order of the list
is not significant and
unknown methods are ignored.  Possible values are as follows:
dkim: Authenticate with DKIM
spf: Authenticate with SPF

An empty list indicates the tag is ignored.

If any listed method passes, then DMARC is aligned.

https://gist.github.com/moonshiner/70377e69d482e7bf3a927d5ac468babb


also " I don't think we need another way to express the same thing in a
less clear way."

+eleventy billion

tim



> Scott K
>
> ___
> 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] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

[Tim Wicinski]

On Sat, Aug 5, 2023 at 5:35 PM John Levine  wrote:

> According to Tim Wicinski  :
> >-=-=-=-=-=-
> >
> >Based on the ABNF in -28, how about something like this:
> >
> >
> >dmarc-method = "dkim" / "spf"
> >
> >dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method)
>
>
1) I realize we may need someway to update the dmarc-method if a new one is
added (okay okay)




> That looks OK, with large clear text saying that if any of the listed
> methods pass, it's aligned.
>

2) I missed Scott's comment the default should be "spf,dkim"

I wordsmithed Wei's definition  above for Section 5.3

  auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
default is "spf,dkim")
Indicates the supported authentication methods. If more than one method
is specified,
they are comma ',' separated without whitespace.  The order of the list
is not significant and
unknown methods are ignored.  Possible values are as follows:
dkim: Authenticate with DKIM
spf: Authenticate with SPF

An empty list indicates no authentication method is specified and DMARC
is disabled.

If any listed method passes, then DMARC is aligned.

Should I do a pull request etc, etc?

tim



> 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

[Tim Wicinski]

Based on the ABNF in -28, how about something like this:


dmarc-method = "dkim" / "spf"

dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method)


I think this "should"(*)  allow for all permutations but also simplifies
it, and I agree with Barry it should be simpler.

tim

* no doubt I missed something and looked to be schooled

On Sat, Aug 5, 2023 at 12:06 PM Barry Leiba  wrote:

> Two things:
>
> > If unspecified with a policy tag "auth=",  this indicates that both DKIM
> and SPF are supported.
>
> I don’t like this approach.  I think that the absence of auth= means what
> it has always meant: the sending domain is not specifying what
> authentication methods it is using and the receiving domain should check
> both SPF and DKIM.
>
> This is significantly different to the sending domain explicitly
> specifying that it uses DKIM in that in the latter case the receiving
> domain can treat the absence of a DKIM signature with suspicion.
>
> And the ABNF is needlessly complex and does not allow for extension.  It’s
> easy to rework it in the manner of many other specifications that do
> similar things.
>
> Barry
>
>
> On Fri, Aug 4, 2023 at 12:17 PM Wei Chuang  40google@dmarc.ietf.org> wrote:
>
>> At IETF-117, I restarted the proposal for a policy "auth=" tag based on
>> the proposal here
>> .
>> The "auth=" policy allows for restriction of SPF in scenarios where it
>> might be problematic but still retains its availability in DMARC by
>> default.  I didn't hear objections at 117, so below is some proposed
>> language for "auth=" for dmarc-ietf-dmarc-dmarcbis.
>>
>> -Wei
>>
>> =
>>
>> 1. Introduction, 3rd paragraph insert after first sentence:
>>
>> In addition, the choice of permitted authentication methods, SPF or DKIM,
>> method MAY be explicitly specified, potentially to restrict the supported
>> authentication methods.
>>
>> 4.3 Authentication Mechanisms append:
>>
>> Domain Owners and PSOs MAY explicitly specify the supported
>> authentication methods via the "auth=" tag.  The value is a colon ':'
>> separated list of supported authentication methods without whitespace.  The
>> order of the list isn't any significant,  and unknown methods are ignored.
>> An aligned passing result for any listed method indicates a DMARC pass.  An
>> empty list indicates no authentication method is specified and DMARC is
>> disabled.  If unspecified with a policy tag "auth=",  this indicates that
>> both DKIM and SPF are supported.
>>
>> 5.3 General Record Format insert:
>>
>> auth: Indicates the supported authentication methods.  If more than one
>> method is specified, they are colon ':' separated without whitespace.  The
>> order of the list is not significant and unknown methods are ignored.  An
>> empty list indicates no authentication method is specified and DMARC is
>> disabled.
>>   dkim: Authenticate with DKIM
>>   spf: Authenticate with SPF
>>
>> 5.4. Formal Definition insert:
>>
>> dmarc-auth =  / "dkim" / "spf" / "dkim:spf" / "spf:dkim"
>>
>> Table:
>> Tag Name   Value Rule
>> auth dmarc-auth
>>
>>
>> ___
>> 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposal for additional Security Considerations for SPF Upgrade in draft-ietf-dmarc-dmarcbis

[Tim Wicinski]

On Fri, Aug 4, 2023 at 5:11 PM Scott Kitterman  wrote:

>
>
> On August 4, 2023 4:15:35 PM UTC, Wei Chuang  40google@dmarc.ietf.org> wrote:
> >I noted at the DMARC session -117, that with the p=reject downgrade to
> >quarantine language, this increases the risk of SPF upgrade attacks due to
> >forwarding.  The reply was to propose language for this and below is the
> >suggested text for the proposed "11.9 Quarantined Forwarded Mail Security
> >Risk"
> >
> >=
> >
> >11.9 Quarantined Forwarded Mail Security Risk
> >
> >When receivers apply the "MUST NOT reject" in Section 8.6 to accept
> >unauthenticated messages as quarantined messages, receivers SHOULD
> >carefully review how they forward mail traffic to prevent additional
> >security risk.  That is, this downgrade can enable spoofed messages that
> >are SPF DMARC authenticated with a fraudulent From identity despite having
> >an associated strong DMARC policy of "p=reject".  A malicious sender needs
> >two properties to perform such a SPF upgrade attack: 1) a receiver that
> >will forward quarantined messages, and 2) the spammer finds a SPF policy
> >that covers the forwarding IPs.  Such a sender crafts a message with From
> >header assuming the identity of the domain with the SPF policy and
> matching
> >MAIL FROM.  Consequently the receiver evaluates message authentication and
> >finds that the MAIL FROM does not authenticate but does not reject the
> >message and instead quarantines it.  Vulnerable receivers then forward the
> >message to some subsequent receiver with the message taking the
> >authenticated identity of the From header.  That forwarding may be under
> >control of the malicious sender perhaps via auto-forwarding or enterprise
> >policy.  Receivers SHOULD consider restricting forwarding when the message
> >is SPF unauthenticated.  SPF upgrade attack and other considerations are
> >discussed further in Liu et. al. [1].
> >
> >[1] Liu, Enze et al. "Forward Pass: On the Security Implications of Email
> >Forwarding Mechanism and Policy", Proceedings of the 8th IEEE European
> >Symposium on Security and Privacy, 2023.
>
> I think I understand what you are saying here and I agree it's worth
> documenting, but I have a few suggestions:
>
> 1.  I would reword it not to have RFC 2119 keywords in it.  As I
> understand it, these keywords are supposed to be for technical protocol
> elements, not things people do like "SHOULD consider".
>
>
Agreed. I would also suggest breaking up the paragraph to perhaps spell
these out more clearly:


A malicious sender needs two properties to perform such a SPF upgrade
attack:

1) a receiver that will forward quarantined messages, and

2) the spammer finds a SPF policy that covers the forwarding IPs.


2.  I would rewrite it not to use the terms upgrade and downgrade.  I think
> the usage is confusing here.
>

I don't see upgrade and downgrade elsewhere in the -28 version, so I would
agree


> Finally, I don't think this is particularly unique to SPF.  If you replace
> "finds a SPF policy that covers the forwarding IPs" with something like
> finds a third party willing to sign the message, I expect I could construct
> a similar (if not quite as easy) DKIM based scenario.
>
> Scott K
>
> ___
> 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] Version bump: was DMARC2 & SPF Dependency Removal

[Tim Wicinski]

I'd rather add an option to flag some behavior rather than do a version
bump.

Have to agree with Scott that version bumps take forever.
(I had a network engineer recently tell me that DNS packets *MUST* be no
larger than 512 bytes - and EDNS0 was 1999?)

tim

On Sat, Jun 10, 2023 at 3:03 PM Scott Kitterman 
wrote:

>
>
> On June 8, 2023 12:58:51 PM UTC, Tobias Herkula  401und1...@dmarc.ietf.org> wrote:
> ...
> >
> >However, such a fundamental shift in the protocol's architecture warrants
> a clear signifier. I suggest we upgrade our DMARC version string from the
> current state to 'DMARC2.' This upgrade would not only denote the change of
> SPF removal, but also the switch from the Public Suffix List (PSL) to the
> Tree-Walk algorithm.
> >
> >By moving towards DMARC2, we not only update our standard to better
> reflect our present requirements, but we also make a clear commitment to
> the ongoing evolution and improvement of the protocol.
>
>
> There's been a fair amount of discussion of the drop SPF part of this
> proposal, but I think less about the question of version bumps.  I'm going
> back to the top of the thread to focus on that.
>
> I don't think there's much precedent for version bumps being successful in
> any reasonable time frame.  How long did it take to transition from SMTP to
> ESMTP?  Is it done yet?  Absent IPv4 address exhaustion, how many more
> decades would it have taken for IPv6 deployment to take off?  SSL/TLS is
> the best example I can think of, but even that, where there are very strong
> security and privacy incentives, has been too slow and very painful.  We
> have nothing like that level incentive for people to support an
> incompatible break between non-IETF DMARC and IETF DMARC.
>
> Technically, it's a new protocol.  There's no technical difference between
> saying records now have to start with v=DMARC2 and they have to start with
> v=NOTDMARC.  It's a decision to abandon all existing deployments and start
> over.
>
> What's the incentive that any existing DMARC users (senders or receivers)
> would have to invest additional resources in another email authentication
> protocol?  My expectation is that if the IETF decides to bump the version,
> very little deployment of the IETF variant.  "The IETF says this one is
> better" doesn't move budgets in any meaningful way.
>
> My suggestion is that if we determine that a change requires a version
> bump, out response should be to not make that change instead.
>
> For clarity, I don't think the tree walk should drive a version bump (and
> we already went over that, let's resist the temptation to do it again), but
> if it did, then I would rather stay with the PSL.
>
> Please, no version bumps.
>
> Scott K
>
> ___
> 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] I-D Action: draft-ietf-dmarc-dmarcbis-27.txt

[Tim Wicinski]

Fantastic Whitespace Engineering Mr Levine.

Looks Good.

tim


On Tue, Feb 28, 2023 at 11:17 AM Todd Herr  wrote:

> This draft is a merge of the pull request that Mr. Levine mentioned in the
> "Question on RFC7489: trailing whitespaces" thread.
>
> It also automagically updated references to the two associated reporting
> documents to their current versions.
>
> On Tue, Feb 28, 2023 at 11:14 AM  wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This Internet-Draft is a work item of the Domain-based Message
>> Authentication, Reporting & Conformance WG of the IETF.
>>
>> Title   : Domain-based Message Authentication, Reporting,
>> and Conformance (DMARC)
>> Authors : Todd M. Herr
>>   John Levine
>>   Filename: draft-ietf-dmarc-dmarcbis-27.txt
>>   Pages   : 71
>>   Date: 2023-02-28
>>
>> Abstract:
>>This document describes the Domain-based Message Authentication,
>>Reporting, and Conformance (DMARC) protocol.
>>
>>DMARC permits the owner of an email author's domain name to enable
>>verification of the domain's use, to indicate the Domain Owner's or
>>Public Suffix Operator's message handling preference regarding failed
>>verification, and to request reports about the use of the domain
>>name.  Mail receiving organizations can use this information when
>>evaluating handling choices for incoming mail.
>>
>>This document obsoletes RFCs 7489 and 9091.
>>
>>
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-27.html
>>
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmarc-dmarcbis-27
>>
>>
>> Internet-Drafts are also available by rsync at rsync.ietf.org:
>> :internet-drafts
>>
>>
>> ___
>> 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Tim Wicinski]

I can not agree more than 100 percent on this.  The PSL has issues. We need
to stop depending on it.

If anything, the PSD work has shown the W3C folks that there is a path
forward for folks who need to
do PSL-like things without boiling the ocean.

tim
(who has spent a bit too much time recently attempting to work out a
success path for DBOUND2)

On Mon, Feb 27, 2023 at 10:08 AM Scott Kitterman 
wrote:

>
>
> On February 27, 2023 3:04:11 PM UTC, "Murray S. Kucherawy" <
> superu...@gmail.com> wrote:
> >On Mon, Feb 27, 2023 at 4:29 AM Douglas Foster <
> >dougfoster.emailstanda...@gmail.com> wrote:
> >
> >> The current text has an incentive problem.   For an evaluator, the PSL
> >> works fine.   Unless an evaluator is Google-class, receiving mail from
> >> everywhere in the world, most of the PSL entries will never be examined
> and
> >> most of the PSL errors will never be exposed.   When an error is
> detected
> >> by an evaluator, it is a trivial effort to add or remove a record from
> the
> >> local copy of PSL.  For evaluators, the PSL works fine.
> >>
> >
> >The notion that different operators are using slightly different versions
> >of the PSL is one of the reasons we want to stop depending on the PSL.  I
> >don't think we should offer this as an option.
> >
> >
> >> Domain owners / message senders are the ones who should be powerfully
> >> motivated to replace the PSL.   If so, they should be willing to add a
> tag
> >> that invokes MUST USE TREE WALK because it eliminates ambiguity and
> >> protects them from the PSL.   With that elimination of ambiguity
> >> and corresponding MUSRT, evaluators have a reason to change.   Without
> >> that, evaluators have every reason to ignore this new, unproven, and
> >> imperfect algorithm;
> >>
> >
> >I'm worried about leaving operators with a choice here, for a number of
> >reasons:
> >
> >1) "pct" also presented a choice, and the consensus appears to be that
> this
> >didn't work out at all, for the reasons previously given (mostly related
> to
> >variance in implementations).
> >
> >2) "Stop using the PSL" as a goal is delayed or even thwarted if we add
> >such a tag.  It creates an undefined, possibly infinite, period of
> >migration during which operators can opt out.  If we're going to do this,
> >we should discuss including some kind of firm sunset period for the PSL.
> >But now we're walking in the direction of having a flag day, and everybody
> >hates those.
> >
> >3) Since the goal is to wind down dependence on the PSL, I suggest that an
> >implementation might choose to make the algorithm selectable, but I don't
> >think the specification should.
> >
> >-MSK
>
> 100 percent agree.  The only way to stop doing something is to stop doing
> it.  The specification is all we control.  Implementers will adjust and
> transition to the IETF design based on their own business timelines.
>
> Scott K
>
> ___
> 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] Question on RFC7489: trailing whitespaces

[Tim Wicinski]

I agree that we should fix this tolerance in the bis document.

tim
with no hat on


On Mon, Feb 27, 2023 at 9:48 AM Murray S. Kucherawy 
wrote:

> On Mon, Feb 27, 2023 at 2:29 AM Tõnu Tammer 
> wrote:
>
>> I am curious to know what the stance is on trailing whitespace within
>> DMARC records.
>>
>> Strictly following the RFC 7489 and the formal specification in section
>> 6.4, if there is no trailing dmarc-sep with the associated semicolon,
>> trailing whitespace is not allowed.
>>
>>
>>
>> For example a record like: "v=DMARC1; p=reject; pct=100 " would be
>> invalid,
>> whereas "v=DMARC1; p=reject; pct=100 ; " would be valid.
>>
>
> I think your interpretation is correct, that's what the specification
> says.  A parser would be right to reject it.
>
> As an implementer, I would probably tolerate this.  Trailing whitespace
> has almost never been something worth failing on in my experience.
>
> I would also suggest that the working group discuss making such tolerance
> explicit in the bis document if it's not too late to add a small issue for
> consideration.
>
> -MSK, no hat on
> ___
> 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] Treewalk causing changes

[Tim Wicinski]

Ale,

On Sat, Feb 25, 2023 at 5:29 AM Alessandro Vesely  wrote:

> On Fri 24/Feb/2023 21:21:15 +0100 Brotman, Alex wrote:
> > While discussing this with someone at the conference yesterday, we
> thought perhaps we could introduce something of a referral.
> >
> > Currently:
> > _dmarc.ret.bmcc.cuny.edu NULL
> > _dmarc.bmcc.cuny.edu "v=DMARC1; p=quarantine; fo=1; rua=mailto:
> dmarc_...@emaildefense.proofpoint.com; ruf=mailto:
> dmarc_...@emaildefense.proofpoint.com"
> > _dmarc.cuny.edu  "v=DMARC1;p=none;rua=mailto:
> dmarc_...@emaildefense.proofpoint.com,mailto:post.mas...@cuny.edu
> ;ruf=mailto:dmarc_...@emaildefense.proofpoint.com,mailto:
> post.mas...@cuny.edu;fo=1"
> >
> > Proposed:
> > _dmarc.bmcc.cuny.edu "v=DMARC1;sp=refer:cuny.edu; p=quarantine; fo=1;
> rua=mailto:dmarc_...@emaildefense.proofpoint.com; ruf=mailto:
> dmarc_...@emaildefense.proofpoint.com"
> >
> > Adding the "sp=refer:cuny.edu" would allow the existing policy to be
> used for undeclared subdomains under the third-level domain.  This could be
> useful in the situation where an OrgDomain would like to still maintain
> some control over policy for the undeclared domains.
>
>
> I like the ability of allowing a subdomain to publish its own policy
> without
> affecting further subdomains.  Indeed, bmcc.cuny.edu features a list of
> NSes
> different from cuny.edu.  Now, ret.bmcc.cuny.edu has no NS record, but
> has an
> MX different from bmcc.  Clearly its mail management is independent.
>
>
Are you sure?

# dig  cuny.edu NS +noall +answer
cuny.edu. 3600 IN NS ext-ns1.columbia.edu.
cuny.edu. 3600 IN NS ns10.customer.level3.net.
cuny.edu. 3600 IN NS ns15.customer.level3.net.
cuny.edu. 3600 IN NS acme.ucc.cuny.edu.
cuny.edu. 3600 IN NS lavinia.cis.cuny.edu.
#
dig  bmcc.cuny.edu NS +noall +answer
bmcc.cuny.edu. 300 IN NS ns10.customer.level3.net.
bmcc.cuny.edu. 300 IN NS ext-ns1.columbia.edu.
bmcc.cuny.edu. 300 IN NS ns15.customer.level3.net.
bmcc.cuny.edu. 300 IN NS acme.ucc.cuny.edu.
bmcc.cuny.edu. 300 IN NS lavinia.cis.cuny.edu.
they look the same to me


tim


OTOH, we cannot force bmcc to monitor the p= and sp= tags of their parent
> domain and change their own sp= tag accordingly.
>
> However, I dislike refer:cuny.edu.  What if they published refer:
> outlook.com?
>
> Rather I'd propose sp=inherit.  A receiver has to navigate to cuny.edu
> anyway
> if it needs to establish the organizational domain, so it can retrieve the
> policy as well.
>
>
> 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] Treewalk causing changes

[Tim Wicinski]

Elizabeth,

(speaking as a DNS person).  I think this is "OK" - at my last job we set
up DMARC records which stricter in certain subdomains than
the parent domain. (Now I need to go find the machine where I left my code
which did all this validation).


(As a DNS person I want to find the folks who put in the TXT record for _
dmarc.cuny.edu and ask them to quote their string.  But that's
my OCD).

tim


On Thu, Feb 23, 2023 at 5:30 PM Elizabeth Zwicky  wrote:

>
> I haven’t done extensive research but here is a live example where
> treewalk will cause a result change.
>
> From: is in the domain Ret.bmcc.cuny.edu which has no DMARC record.
>
> _dmarc.bmcc.cuny.edu.300INTXT"v=DMARC1; p=quarantine;
> fo=1; rua=mailto:dmarc_...@emaildefense.proofpoint.com; ruf=mailto:
> dmarc_...@emaildefense.proofpoint.com"
>
> _dmarc.cuny.edu.3325INTXT"v=DMARC1;" "p=none;"
> "rua=mailto:dmarc_...@emaildefense.proofpoint.com,mailto:
> post.mas...@cuny.edu;" "ruf=mailto:dmarc_...@emaildefense.proofpoint.com
> ,mailto:post.mas...@cuny.edu;; "fo=1"
>
> Elizabeth Zwicky
> ___
> 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] DMARCbis Privacy Considerations was: Re: I-D Action: draft-ietf-dmarc-dmarcbis-17.txt

[Tim Wicinski]

On Thu, Sep 1, 2022 at 7:08 PM Scott Kitterman  wrote:

>
>
> On September 1, 2022 6:05:29 PM UTC, Barry Leiba 
> wrote:
> >> As we may have mentioned a few times before. PSDs that send their own
> >> mail are extremely rare. You can probably count them all on your
> fingers.
> >>
> >> I cannot understand why someone would want to introduce this giant
> >> security risk to benefit a tiny exotic set of domains that is almost
> >> too small to measure.
> >
> >Indeed: this *has* come up many times and continues to, in various
> >versions.  I think we need to settle this point clearly, so let's be
> >clear about that now:
> >
> >The sense I get from discussions is that we *do* have rough consensus
> >that we prefer not to cater to truly small edge cases, and that when
> >we're proposing things that address them and try to close them we're
> >doing it by way of being engineers and looking for that perfection.
> >
> >So the question: Does anyone *really* think we *do* have to close out
> >these edge cases at the risk of complexity, incompatibility, or other
> >down-sides?  If you do, please explain why it's worth it and give a
> >*real world* not theoretical example that shows the importance of
> >doing so.
>
> To this specific question, the reason I'm taking on the new proposed text
> is that currently we have a reference to RFC 9091, which is a document the
> DMARCbis will obsolete, if approved.  As a result, I think we need to bring
> the text into the new documents and drop the reference.
>
> Due to the current way the documents are split, it's not just a simple
> copy/paste.  Everything about publishing DMARC records is in DMARCbis and
> everything about sending aggregate and failure reports is in the respective
> drafts for each.
>
> As I get into it, I see that the current Privacy Considerations are very
> incomplete (non-existent in DMARCbis), so not everything I'm proposing is
> straight from RFC 9091.
>
> Given the current emphasis on privacy in the IETF (and because it's the
> right thing to do), we need to put some effort in towards getting that part
> of the draft to be at least substantially complete and correct).
>
>
+1 with Scott on improving the Privacy Considerations, which means I'll
need to suggest some text.

tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] IANA registration for psd tag, please

[Tim Wicinski]

+1



On Thu, Jul 21, 2022 at 2:32 PM John Levine  wrote:

> Now that we've gone around the barn a few more times and nothing has
> changed with the psd=u/n/y tag, can we please ask for a tentative IANA
> registration?
>
> R's,
> John
>
> ___
> 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] Updating ABNF for Next Rev?

[Tim Wicinski]

I am all about simpler ABNF

+1

Simple Tim


On Mon, Jun 6, 2022 at 10:03 PM John Levine  wrote:

> Here's my alternate take: make the ABNF a lot simpler to
> reflect the actual loose syntax.
>
> dmarc-record= dmarc-version *(*WSP ";" *WSP dmarc-tag) *WSP *%x3b
>
> dmarc-tag   = 1*ALPHA %WSP '=' *WSP 1*dmarc-value
>
> dmarc-value = %x20-3a | %x3c-7e ; any printing chars but semicolon
>
> dmarc-version   = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31
>
> Don't waste ABNF defining the tag names. Just define the values for
> the various tags:
>
> > dmarc-request   = ( "none" / "quarantine" / "reject" )
> >
> > dmarc-test  = ( "y" / "n" )
> >
> > dmarc-psd   = ( "y" / "n" )
> >
> > dmarc-sprequest = ( "none" / "quarantine" / "reject" )
> >
> > dmarc-nprequest  = ( "none" / "quarantine" / "reject" )
> >
> > dmarc-adkim = ( "r" / "s" )
> >
> > dmarc-aspf  = ( "r" / "s" )
> >
> dmarc-uri   = URI
>   ; "URI" is imported from [RFC3986]; commas (ASCII
>   ; 0x2C) and exclamation points (ASCII 0x21)
>   ; MUST be encoded
>
> > dmarc-auri  = dmarc-uri *(*WSP "," *WSP dmarc-uri)
> >
> > dmarc-furi  = dmarc-uri *(*WSP "," *WSP dmarc-uri)
> >
> > dmarc-fo= ( "0" / "1" / ( "d" / "s" / "d:s" / "s:d" ) )
> >
> > dmarc-rfmt  = Keyword *(*WSP ":" Keyword)
> >   ; registered reporting formats only
> >
> >   "Keyword" is imported from Section 4.1.2 of [RFC5321].
> >
> >   dmarc-test  = ( "y" / "n" )
>
> ___
> 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] Tree Walk + CNAME

[Tim Wicinski]

On Wed, Mar 30, 2022 at 8:50 AM Brotman, Alex  wrote:

> >From section 4.6:
>
> To illustrate, for a message with the arbitrary RFC5322.From domain
>of "a.b.c.d.e.mail.example.com", a full DNS Tree Walk would require
>the following five queries, in order to locate the policy or
>Organizational Domain:
>
>*  _dmarc.a.b.c.d.e.mail.example.com
>
>*  _dmarc.e.mail.example.com
>
>*  _dmarc.mail.example.com
>
>*  _dmarc.example.com
>
>*  _dmarc.com
>
>
> What should the evaluator do if one of these results in a CNAME that
> either:
>
> a) points outside of the tree
>

I would say "Follow the CNAME" - consider LargeCo which points many DMARC
records
of domains in their portfolio to a record in their main domain.  Or
outsourced DMARC
to third party.

b) results in a loop pointing at a previously evaluated record
>

CNAME loops are usually detected in resolvers, but loops should return no
record found

tim



>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
>
> ___
> 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] 3.2.6 The meaning of non-existence

[Tim Wicinski]

On Fri, Dec 17, 2021 at 9:06 PM Scott Kitterman 
wrote:

> On Friday, December 17, 2021 8:43:17 PM EST Tim Wicinski wrote:
> > On Fri, Dec 17, 2021 at 6:56 PM Douglas Foster <
> >
> > dougfoster.emailstanda...@gmail.com> wrote:
> > > That is not my position, and I don't know how you drew that
> > > conclusion from those words.
> >
> > Then my mistake.
> >
> > > I do take the position that DMARC PASS means "This name correctly
> > > represents the stated domain", and NP=TRUE means "This name cannot
> > > represent the stated domain because the domain owner never uses that
> > > name".   I am willing to say that if NP=TRUE produces an accurate
> result,
> > > I
> > > will block the message and I can see no reason why anyone else would do
> > > otherwise.
> > >
> > > DMARC FAIL is an ambiguous result, which was your point.  DMARC PASS is
> > > not ambiguous.   NP=TRUE should be ambiguous if at all possible,
> otherwise
> > > it adds no value.
> > >
> > > But back to the actual topic:
> > > - Do you believe the NP test can be useful?  If so, for what purpose?
> > > - What is the optimal test to evaluate NP?  How did you reach that
> > > conclusion?
> >
> > I see the NP tag being useful for mid to large organizations that have a
> > regular amount of organizational change (mergers, acquisitions, etc).
> > A large mostly static organization will not deploy the np tag, because "p
> > == sp", where the domain tag = the subdomain tag.
> > Larger organizations deploying DMARC usually run into the problem of not
> > knowing all the mail flows from all the change, and they end up
> > with "p != sp" for some period of time.  In these cases, np is really
> > useful in preventing attack vectors using subdomains (log4j.example.com)
> > from
> > being used.
> >
> > I am sure there are folks who track DMARC record changes over time, but
> > back in mid 2020 I pulled a bunch of DMARC records of some alexa top 10K,
> > and noticed the number of domains where "p != sp".  Doing a quick pull of
> > those domains and checking now I see a number of them now show "p == sp",
> > which means they feel they have a better understanding of their mail
> > flows.
> >
> > I worked for a large organization which had to set "p != sp" for a period
> > of time as they understood things better. They are now a "p == sp"
> > organization now, which is good. But having the added bonus of blocking
> > invalid subdomains during that migration period I am sure would have
> > made folks feel better.
> >
> > (the other use case for the np tag is around TLDs and also the SLDs like
> > co.uk, and Scott is all over that).
>
> Actually .gov.uk.  I'd expect that .co.uk has similar challenges to what
> we'd
> expect with .com.


I knew I'd get something wrong.


>
> What you describe is something that was in my mind when we defined np=,
> despite
> the focus on PSD at the time.  I think that np= has potentially broad
> utility
> as a gap filler during the deployment process for large organizations.
>

As an operations person who has worked with a lot of technical debt, when I
saw your idea
for np=, *all* I could think of was large organizational issues.

>
> I think p=reject will be a problem of a lot of organizations for a long
> time,
> so I think anything we can do to make it easier to have some set of mail
> covered by a reject policy is a good thing.
>

Here is a data point on this.  Sometime back in Fall 2020, I was collecting
some DMARC DNS records.
I was using the alexa-top* lists, which are horrible datasets, because
web domains don't always send email
and email domains don't have web properties etc.

Using the top-1000 domains:

1000 domains
 562 domains with DMARC record
 318 domains with DMARC record where p != sp

Rechecking that same list of domains last night:

  371 domains with DMARC record where p != sp

53 domains from this list updated their policies.  I did not dive into the
specifics, but they mostly appear
to have the 'p=' move forward (none->quarantine->reject) while 'sp='
appeared to stay the same.
(I see a few where 'p=' moves to reject and 'sp=' moves to none. I can
figure this out if interested)

To Scotts' point on organizations moving to p=reject will take time, I
would agree.  But allowing a large organization
allow sp=none but np=reject is a huge help.  (This also means organizations
need to cull the DNS data, but some of us
are a bit too obsessive about this)

tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Tim Wicinski]

On Fri, Dec 17, 2021 at 6:56 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> That is not my position, and I don't know how you drew that
> conclusion from those words.
>

Then my mistake.

>
> I do take the position that DMARC PASS means "This name correctly
> represents the stated domain", and NP=TRUE means "This name cannot
> represent the stated domain because the domain owner never uses that
> name".   I am willing to say that if NP=TRUE produces an accurate result, I
> will block the message and I can see no reason why anyone else would do
> otherwise.
>
> DMARC FAIL is an ambiguous result, which was your point.  DMARC PASS is
> not ambiguous.   NP=TRUE should be ambiguous if at all possible, otherwise
> it adds no value.
>
> But back to the actual topic:
> - Do you believe the NP test can be useful?  If so, for what purpose?
> - What is the optimal test to evaluate NP?  How did you reach that
> conclusion?
>
>
I see the NP tag being useful for mid to large organizations that have a
regular amount of organizational change (mergers, acquisitions, etc).
A large mostly static organization will not deploy the np tag, because "p
== sp", where the domain tag = the subdomain tag.
Larger organizations deploying DMARC usually run into the problem of not
knowing all the mail flows from all the change, and they end up
with "p != sp" for some period of time.  In these cases, np is really
useful in preventing attack vectors using subdomains (log4j.example.com)
from
being used.

I am sure there are folks who track DMARC record changes over time, but
back in mid 2020 I pulled a bunch of DMARC records of some alexa top 10K,
and noticed the number of domains where "p != sp".  Doing a quick pull of
those domains and checking now I see a number of them now show "p == sp",
which means they feel they have a better understanding of their mail
flows.

I worked for a large organization which had to set "p != sp" for a period
of time as they understood things better. They are now a "p == sp"
organization now, which is good. But having the added bonus of blocking
invalid subdomains during that migration period I am sure would have
made folks feel better.

(the other use case for the np tag is around TLDs and also the SLDs like
co.uk, and Scott is all over that).


tim



>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Tim Wicinski]

On Fri, Dec 17, 2021 at 6:27 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> The way I evaluate a design is to first look for logical consistency or
> inconsistency.If there is obvious inconsistency, then the design needs
> to be re-evaluated to correct the problem.Once a design appears to be
> logically consistent, we do data analysis to validate our design.   The
> criteria for DMARC PASS (the identity is authentic) and NP (the identity
> cannot be authentic) should be aligned so that they produce results that
> are not in direct conflict.   We seem to have an obvious design hole, with
> an obvious solution, which is what I proposed.
>
>
DMARC PASS != "this email is legit"

You are looking for a specific test that an email can go through which will
turn a crank and at the end of it says "Yes" or "no".

The text in -04 version is pretty clear:

   A DMARC pass indicates *only* that the RFC5322
.From domain has been
   authenticated for that message.  *Authentication does not carry an
   explicit or implicit value assertion about that message or about the
   Domain Owner. *


You read "PASS" as "legit email" while I have always read it as "this
variable is true".


What the vendors like Agari, Valimail, Proofpoint, et al, is to
collect all the variables (SPF, DKIM, DMARC, plus organization
specific info) and allow the

organization to tweak as needed.


You are looking to solve the problem of legitimate email. DMARC is not
trying to solve that.


tim

> As to examples, my data set is large enough to be informative but not
> large enough to be determinative.   I see very little forwarded mail, so my
> data set is not expected to answer your specific question.   I do see
> legitimate messages using From domains that are not in DNS.  The existence
> of legitimate non-DNS names, and the lack of a suitable compliance
> mechanism for those names, is what got me concerned about this test
> definition.I have provided the group with examples, as has someone
> else.   Yet, the test specification has not been modified to address that
> concern.   How do you think that makes me feel?
>
> A year after raising my concerns, I am still trying to get a collaborative
> discussion started about what the optimal test looks like.  In a
> collaborative discussion, those who are happy with the status quo convince
> the skeptics to come on board, listen to their concerns, acknowledge them,
> and do what they can to accommodate those concerns so that consensus can be
> achieved.I am willing to be convinced, but I am skeptical and I am
> looking for some collaboration.
>
> Doug
>
> On Fri, Dec 17, 2021 at 11:00 AM Murray S. Kucherawy 
> wrote:
>
>> On Thu, Dec 16, 2021 at 3:52 PM Douglas Foster <
>> dougfoster.emailstanda...@gmail.com> wrote:
>>
>>> We both know exactly what causes messages to lose credentials:
>>> - A record that is only SMTP validated, which is then forwarded without
>>> SMTP rewrite
>>> - A message which is forwarded after modifications, such as the
>>> ubiquitous "this message received from an external source".   Of course, it
>>> could be a mailing list modification also.
>>>
>>
>> Yes, I'm aware of this aspect of message authentication.  That wasn't my
>> question.
>>
>> The point of an NP test was, in my understanding, to identify names that
>>> were never valid in any circumstance, like 'junk.junk.ietf.com",
>>> without any dependencies on message path.Why would we want to create a
>>> duplicate of the mailing list problem?
>>>
>>
>> I understand the first sentence.  I do not see how the second follows.
>>
>> However, if MX/A/ is really the right test for fraudulent
>>> identifiers, then we need to open a CVE against all implementations of
>>> RFC7489, because implementations based on that spec have been confidently
>>> asserting honest identifiers without checking the MX/A/ condition.
>>>
>>
>> I don't follow this either.
>>
>> Why do I need to provide case studies?Isn't the burden of proof on
>>> the team that told us that MX/A/AAA was absolutely the best possible test
>>> to use?
>>>
>>
>> Because I'm trying to understand your concern.  Sure, it's reasonable for
>> us to question our assumptions.  But if I don't understand how you get your
>> premises, or how your premises lead to your conclusions, am I being
>> unreasonable when I ask for clarification or concrete examples?
>>
>> -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] 3.2.6 The meaning of non-existence

[Tim Wicinski]

On Fri, Dec 17, 2021 at 12:30 PM Dotzero  wrote:

>
>
> 
>
> DMARC does not assess "honesty" nor does it assess "fraudulence". It only
> determines whether something passes or fails the validation check. You are
> apparently trying to overload your value interpretations in a manner that
> does not exist in the standard.
>
>
Thank you Michael, for reminding me of this.DMARC provides a result
based on a collection of tests, and it is up to the receiver of the email
whether they choose to accept the email or to reject it.

tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Tim Wicinski]

On Thu, Dec 16, 2021 at 12:58 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Yes, this is important stuff.
>
> This is one of my problem scenarios:
>
> A record arrives at the first hop and obtains DMARC PASS, based on SPF
> and/or DKIM interpreted by a DMARC policy.  Based on DMARC PASS, the
> RFC5322.From address is confidently judged to be "Honestly identified"
>  DMARC checks SPF and DKIM, but not MX or A/.
>
> But then it is forwarded and loses its credentials during forwarding.
>

It sounds like you're rewriting the message header and sending it back out,
like a mailing list would do.
It's two different mail sessions.

This problem space is what ARC attempts to solve.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Tim Wicinski]

Thanks Scott.  _dmarc.police.uk doesn't seem to have the 'np' tag.

There are a number of domains with policies that have 'p=quarantine|reject
sp=none' - it would be good to see if 'np=reject' is added to any.

tim



On Wed, Dec 15, 2021 at 6:50 PM Scott Kitterman 
wrote:

> On Wednesday, December 15, 2021 5:44:46 PM EST Barry Leiba wrote:
> > > Scott,  I have many problems with your response.   Was it intended as
> an
> > > ad hominem? It certainly came across that way.
> >
> > It doesn't seem even remotely so to me.  Please be careful with
> > attributing intent.  No one tried to say that we shouldn't listen to
> > you.
> >
> > > If the NP objective can be stated in a sentence or two, you should have
> > > done so, instead of telling me to read years of archive.  An objective
> > > that cannot be explained tersely is not sufficiently defined.
> >
> > It *is* reasonable to expect you to review earlier discussions, rather
> > than to ask the working group to revisit them without a sense of how
> > you're adding new information.
>
> Thanks.  Yes, that was my intent.
>
> To give a short summary, in the interests of moving forward:
>
> The domain owner publishing the DMARC record knows and controls what
> exists
> and what doesn't.  They don't have to guess.  The question was,
> particularly
> in the context of PSD, but not exclusively, would record publishers find
> it
> useful to be able to publish a different (and presumably more strict)
> policy
> for non-existent domains.  More p=reject equals more bad stuff not getting
> delivered.
>
> I think we can say it's an pretty unqualified yes in the PSD realm:
>
> $ dig +short txt _dmarc.gov
> "v=DMARC1; p=reject; sp=none; np=reject; rua=mailto:
> dotgov_dm...@cisa.dhs.gov"
>
> $ dig +short txt _dmarc.mil
> "v=DMARC1; p=reject; sp=none; np=reject; rua=mailto:dmarc_repo...@mail.mil
> "
>
> $ dig +short txt _dmarc.gov.uk
> "v=DMARC1;p=reject;sp=none;np=reject;adkim=s;aspf=s;fo=1;rua=mailto:dmarc-
> r...@dmarc.service.gov.uk"
>
> $ dig +short txt _dmarc.police.uk
> "v=DMARC1;p=none;sp=none;adkim=s;aspf=s;fo=1;rua=mailto:dmarc-
> r...@dmarc.service.gov.uk;ruf=mailto:dmarc-...@dmarc.service.gov.uk;
>
> All of the current PSDs that have published records with any policy other
> than
> none have different sp= and np= policies.
>
> Scott K
>
>
> ___
> 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] PSD Flag

[Tim Wicinski]

On Mon, Dec 6, 2021 at 8:57 AM Scott Kitterman  wrote:

>
>
> Unless there's a valid reason for someone to publish PSD=no, I don't think
> it should exist and I can't think of a reason.  If you give people a knob,
> someone will turn it [if we leave it in, I guarantee you there will be
> things written about how essential it is to have psd=no in your DMARC
> record].
>
>
What Scott says here. It can not be said enough.  People will attempt
anything and everything.  Make it simple, and precise.

>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6. Non-existent Domains

[Tim Wicinski]

On Sat, Dec 4, 2021 at 11:14 PM Scott Kitterman 
wrote:

> Should we modify the definition of non-existent domains so that a domain
> that
> only has an RFC 7505 null mx record is still considered non-existent?
>
> I'll propose text if it's agreed this would be a useful change?
>
> Scott K
>
>
This is a useful addition.

3.2.6 also says:

This is a broader definition than that in [RFC8020].


But RFC8020 only defines "Denied name".  I suggest

This is a broader definition than what is defined as "Denied name" in
[RFC8020].
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Additions to introduction

[Tim Wicinski]

I am Ok with adding text of this nature, and I think it's helpful in
explaining to folks approaching
DMARC for the first time. But I start to lose focus on reading long
introductions (okay boomer).

Maybe the Intro could get a section or two to help focus it.

I am glad to assist wordsmithing Doug's comments if that is useful.

tim




On Sat, Dec 4, 2021 at 4:25 PM Murray S. Kucherawy 
wrote:

> On Sat, Dec 4, 2021 at 9:55 AM John Levine  wrote:
>
>> The point of a spec is to tell people how to interpoerate.  I don't see
>> how this
>> contributes to that.
>>
>
> Lots of specifications include informative guidance or best practices
> advice as well as normative specification.  DKIM has loads of it.
>
> -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] dmarcbis-04, 5.3. General Record Format 5/5

[Tim Wicinski]

On Sat, Dec 4, 2021 at 6:20 AM Alessandro Vesely  wrote:

> On Fri 03/Dec/2021 19:38:26 +0100 Todd Herr wrote:
> > On Fri, Dec 3, 2021 at 12:40 PM Alessandro Vesely 
> wrote:
> >>
> >> last message for today:  the "t" tag instead of "pct".
> >>
> >> That's the only part which breaks existing records.  According to the
> last
> >> paragraph of this section, doing so requires v=DMARC2.
> >>
> >
> > I'm not sure I agree with your assertion here. I'm assuming you're
> > referring to this paragraph:
> >
> > Note that given the rules of the previous paragraph, addition of a
> > new tag into the registered list of tags does not itself require a
> > new version of DMARC to be generated (with a corresponding change to
> > the "v" tag's value), but a change to any existing tags does require
> > a new version of DMARC.
>
>
> Exactly.
>
>
> > I contend that introducing 't' to replace 'pct' is not a change to an
> > existing tag but rather an addition of a new tag.
>
>
> In that case, the definition of pct= must still appear in the spec.  As
> rfc7489
> is obsoleted, referencing it makes little sense.
>

Ale,

While RFC7489 will be obsoleted, it did document several tags which are no
longer considered valid.

If the concern is that we will be forcing readers of the new RFC to chase
through
old documents to understand what 'pct' tag was defined, Appendix A.7
explains
the pct tag, and its removal.  I think that is the right place to place
this info.

tim



>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (6729)

[Tim Wicinski]

I must agree with Mr Levine on this.

tim


On Sat, Dec 4, 2021 at 1:00 PM John Levine  wrote:

> It appears that Murray S. Kucherawy   said:
> >-=-=-=-=-=-
> >
> >This was reported but not sent to the WG.  I believe the right disposition
> >is "Hold for Document Update".  Does anyone want to argue for "Rejected"
> or
> >"Verified"?
>
> Reject it.  Whether you choose to believe the non-ICANN part of the PSL is
> local policy.
>
> I also think that Scott's example in the notes is wrong.  It is perfectly
> plasuble for an operator's customers to have their own DMARC policy,
> although most
> of the subdomains are less exotic than this one.  Try Centralic's us.com
> where I think you would not want foo.us.com and bar.us.com to share the
> same default policy.
>
> R's,
> John
>
> >-- Forwarded message -
> >From: RFC Errata System 
> >Date: Mon, Nov 1, 2021 at 4:31 PM
> >Subject: [Technical Errata Reported] RFC7489 (6729)
> >To: , , <
> rfc-...@rfc-editor.org>
> >Cc: , 
> >
> >
> >The following errata report has been submitted for RFC7489,
> >"Domain-based Message Authentication, Reporting, and Conformance (DMARC)".
> >
> >--
> >You may review the report below and at:
> >https://www.rfc-editor.org/errata/eid6729
> >
> >--
> >Type: Technical
> >Reported by: Scott Kitterman 
> >
> >Section: 3.2
> >
> >Original Text
> >-
> >   3.  Search the public suffix list for the name that matches the
> >   largest number of labels found in the subject DNS domain.  Let
> >   that number be "x".
> >
> >Corrected Text
> >--
> >   3.  Search the ICANN DOMAINS section of the public suffix list for
> >   the name that matches the largest number of labels found in the
> >   subject DNS domain.  Let that number be "x".
> >
> >Notes
> >-
> >The PSL includes both public and private domains.  RFC 7489 should have
> >limited name matching to the public, ICANN DOMAINS section of the PSL.  As
> >an example, using the current PSL, the organizational domain for
> >example.s3.dualstack.ap-northeast-1.amazonaws.com is
> >example.s3.dualstack.ap-northeast-1.amazonaws.com, not amazonaws.com
> since
> >it is listed in the private section of the PSL.  This is clearly the wrong
> >result.
> >
> >Instructions:
> >-
> >This erratum is currently posted as "Reported". If necessary, please
> >use "Reply All" to discuss whether it should be verified or
> >rejected. When a decision is reached, the verifying party
> >can log in to change the status and edit the report, if necessary.
> >
> >--
> >RFC7489 (draft-kucherawy-dmarc-base-12)
> >--
> >Title   : Domain-based Message Authentication, Reporting, and
> >Conformance (DMARC)
> >Publication Date: March 2015
> >Author(s)   : M. Kucherawy, Ed., E. Zwicky, Ed.
> >Category: INFORMATIONAL
> >Source  : INDEPENDENT
> >Area: N/A
> >Stream  : INDEPENDENT
> >Verifying Party : ISE & Editorial Board
> >
> >-=-=-=-=-=-
> >[Alternative: text/html]
> >-=-=-=-=-=-
>
>
> ___
> 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] Organizational Alignment Options

[Tim Wicinski]

On Thu, Nov 4, 2021 at 6:54 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> It would be helpful to understand why people want to climb into the
> publicsuffix.org list.My guess:   An ISP, such as "ISP.TLD" allows
> customers to create websites under their parent.   They need to be able to
> indicate that website JohnSmith.ISP.TLD is independent of website
> IvanWatson.ISP.TLD, and therefore cross-site scripting defenses should
> treat them as two organizations rather than one.This scenario needs a
> flag that says "No alignment for XSS purposes", and the set of names that
> need that flag may be very different from the set of names that need a
> DMARC non-alignment flag.So a set of feature-specific DNS flags will
> indeed be a better long-term design than a simple "I'm a PSL" flag.
>
> I can't answer whether PSLs will cooperate by publishing DNS entries.   My
> original suggestion was to specify the flag syntax in the RFC, so that
> deployment negotiations can begin, while recommending that implementers use
> both.   For the same reason that I did not see a threat risk, I would place
> greater trust in the DNS entry when it is present, so I would check DNS
> first.  But I would also check the publicsuffix.org list to handle the
> problem of DNS non-participation.
>
>
As a DNS Person, I always prefer a DNS answer, especially if that answer is
signed with DNSSEC.

But DNSSEC deployment is still not as straightforward and non-dns folks
still argue about deploying it.


>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Round Two: Ticket #66 (Define What It Means to Have Implemented DMARC) and #62 (Reporting a MUST)

[Tim Wicinski]

Thanks for pointing this out Scott, I've been sidetracked.

Section 8 gives me issues also. Many of these topics I've always felt would
go into a BCP on operation practices.

I am not well ensconced in the Mail community, but are this disagreements
between
vendors, software, etc over if one is "implementing DMARC"?



On Thu, Sep 9, 2021 at 11:56 PM Scott Kitterman 
wrote:

> On Tuesday, September 7, 2021 3:16:18 PM EDT Todd Herr wrote:
> > Greetings.
> >
> > Previous discussion of this issue a couple of weeks ago seemed to land on
> > the idea that the text in Section 8 of the current rev of the draft,
> titled
> > "Minimum Implementations", was problematic in its content and there was a
> > suggestion that perhaps the text could be softened and moved to a summary
> > section.
> >
> > I'm writing today to seek guidance from the working group as to what
> such a
> > summary section might be.
> >
> > At first blush, it might seem that the current Section 9, "Other Topics",
> > might be a place for a summary discussion of "Minimum Implementations";
> > however, the introductory text for Section 9 currently reads "This
> section
> > discusses some topics regarding choices made in the development of DMARC,
> > largely to commit the history to record." and so "Minimum
> Implementations"
> > might not fit.
> >
> > Another choice might be to leave "Minimum Implementations" as a
> standalone
> > section, but soften the language, particularly in regards to removing
> > reporting as a MUST and addressing John and Ale's concerns about
> requiring
> > the p= value to be other than none, along with other concerns raised.
> >
> > A third option might come from consensus from the group, rejecting either
> > of the two options I've proposed above but instead landing on a new one.
> >
> > Thank you for your time, and I look forward to your input.
>
> I've just reviewed section 8 and I find it an odd thing for an IETF
> document.
> I also find the notion that since my domain has a p=None policy due to the
> fact
> that an extremely large fraction of the email I send fails DMARC due it
> being
> sent to email lists translating to "I'm not doing DMARC" to be extremely
> problematic.
>
> As I understand it, it is not typical IETF practice to do conformance
> specifications.  The IETF practice is to define requirements for
> interoperability.
>
> I think that the whole section should just go.  It's not the IETF's job to
> specify contractual requirements for DMARC implementation.  The
> requirements
> for this should be defined by the entity levying the requirements.  Here's
> an
> example excerpted from a publicly available source:
>
> > For a domain used to send email: Registrants must publish a DMARC record
> > with a reject mail receiver policy (p=reject), except during the
> > implementation phase of email as described below*.
>
> ...
>
> > *When deploying DMARC during the implementation phase of email
> capabilities,
> > Registrants may temporarily use a “none” (p=none) or “quarantine”
> > (p=quarantine) mail receiver policy, but must change the policy to reject
> > for ongoing operations within 90 days of deployment.
>
> I know that contracts are routinely written that just say "Implement RFC
> ", but that is not really what RFCs are for and I don't think we
> should go
> down this path.
>
> Scott K
>
>
> ___
> 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] ABNF update to dmarc-psd

[Tim Wicinski]

Dave,

I agree but was scrabbling with the wording. How about


   The "dmarc-record" definition is also updated to include the
   following:

 [dmarc-sep dmarc-nprequest]

which will go in the next to last line of the definition, as so:

[dmarc-sep dmarc-percent]

[dmarc-sep dmarc-nprequest]

[dmarc-sep]


My first instinct is some sort of diff type output, but that isn't right.

tim


On Mon, Jun 7, 2021 at 6:26 PM Dave Crocker  wrote:

> On 6/7/2021 3:10 PM, Tim Wicinski wrote:
>
>dmarc-nprequest =  "np" *WSP "=" *WSP
>( "none" / "quarantine" / "reject" )
>
> I suggest adding a comment that makes the linkage of 'nprequest' to the
> prose text explicit.
>
> d/
>
> --
> Dave crockerdcroc...@gmail.com
> 408.329.0791
>
> Volunteer, Silicon Valley Chapter
> Information & Planning Coordinator
> American Red crossdave.crock...@redcross.org
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] ABNF update to dmarc-psd

[Tim Wicinski]

All

When I raised the point for dmarc-bis making sure that new tags define
their ABNF, I realized that the PSD document does no such thing.
It does describe the definition, as it's the same as the "sp" tag.


I added the following section to dmarc-psd updating 7489 as such:

3.3.  Changes in Section 6.4 "Formal Definition"

   The ABNF for DMARC shall updated to include a new definition "dmarc-
   nprequest" which is defined as:

   dmarc-nprequest =  "np" *WSP "=" *WSP
   ( "none" / "quarantine" / "reject" )


   The "dmarc-record" definition is also updated to include the
   following:

 [dmarc-sep dmarc-nprequest]



I am well aware that the dmarc-bis draft has much cleaner ABNF, but this
document still updates 7489, so
we must follow what is there.


I've pushed a new version -15 into my own repo:
https://github.com/moonshiner/draft-ietf-dmarc-psd

I'd like the WG to double check what is here, making sure this will be
enough.  I'll push out -15 by the
end of the week.

thanks
tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Consensus Sought - Ticket #47 (Removal of "pct" tag) - With Interim Notes

[Tim Wicinski]

+1 With Mr Levine's line of thinking.

I also agree with keeping pct= tag.

tim


On Thu, Jun 3, 2021 at 7:16 PM Dotzero  wrote:

>
>
> On Thu, Jun 3, 2021 at 6:17 PM John Levine  wrote:
>
>> It appears that Alessandro Vesely   said:
>> >On Thu 03/Jun/2021 05:45:33 +0200 Murray S. Kucherawy wrote:
>> >> I don't understand what "demeaning a domain's policy" means.
>> >
>> >I meant to say that p=quarantine; pct=0 is to be considered a strict
>> policy to
>> >all effects.  Saying so should prevent reasoning something like "Oh,
>> they said
>> >quarantine, but since pct=0 it is somewhat faked, so I'll skip X", where
>> X
>> >could be rewriting From:, displaying a BIMI image, record aggregate
>> data, or
>> >any other action that might depend on the policy.  That is to say pct=0
>> does
>> >not alter the value of p=, otherwise testing becomes a nightmare.
>>
>> If we agree that's what we mean, that's what we should say, e.g., add
>> something
>> like this:
>>
>>  Senders may use pct=0 to signal an intention to apply a stricter
>>  DMARC policy in the future, and to request receivers that do special
>>  processing based on DMARC policy to do that processing. Examples of
>>  special processing might include mailing list software rewriting
>>  addresses in From headers.
>>
>
> As long as we get the wording right, I agree with your line of thinking
> John. Again, we don't have insight as to the extent that receivers will
> honor the request.
>
> Michael Hammer
> ___
> 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] Question on ABNF

[Tim Wicinski]

Seth

Done.  https://trac.ietf.org/trac/dmarc/ticket/116

I realize now in pulling this string that the PSD draft should include the
ABNF details for the "np" tag.
I'll work on some proposed text and have it ready for the RFC Editor.

tim


On Fri, May 28, 2021 at 6:26 PM Seth Blank  wrote:

> Tim, please add a ticket for this
>
> On Fri, May 28, 2021 at 13:54 Dave Crocker  wrote:
>
>> On 5/28/2021 12:10 PM, Tim Wicinski wrote:
>>
>> So in looking at removing the "ri" tag from the document, I realized that
>> the ABNF reference needed to be removed also.
>> Thinking about that, I realized that when one adds a new tag to the
>> registry there should be a formalized way that it is represented in the
>> ABNF.   Perhaps the IANA Consideration section should also spell out that
>> for new tags, the specification should also include the incorporating ABNF.
>>
>> +1
>>
>> d/
>>
>> --
>> Dave Crocker
>> Brandenburg InternetWorkingbbiw.net
>>
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> --
>
> *Seth Blank* | VP, Product
> *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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Question on ABNF

[Tim Wicinski]

So in looking at removing the "ri" tag from the document, I realized that
the ABNF reference needed to be removed also.
Thinking about that, I realized that when one adds a new tag to the
registry there should be a formalized way that it is represented in the
ABNF.   Perhaps the IANA Consideration section should also spell out that
for new tags, the specification should also include the incorporating ABNF.


tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Consensus Sought - Ticket #50 (Remove ri= tag) - With Interim Notes

[Tim Wicinski]

Editors,

I sent y'all a pull request.

Tim

On Fri, May 28, 2021 at 2:35 PM Dotzero  wrote:

>
>
> On Fri, May 28, 2021 at 1:59 PM John Levine  wrote:
>
>> It appears that Tim Wicinski   said:
>> >-=-=-=-=-=-
>> >
>> >All,
>> >
>> >This is the current text in Section 10.4 of dmarc-bis
>> >
>> >   Names of DMARC tags must be registered with IANA in this new sub-
>> >   registry.  New entries are assigned only for values that have been
>> >   documented in a manner that satisfies the terms of Specification
>> >   Required, per [RFC8126].  Each registration must include the tag
>> >   name; the specification that defines it; a brief description; and its
>> >   status, which must be one of "current", "experimental", or
>> >   "historic".  The Designated Expert needs to confirm that the provided
>> >   specification adequately describes the new tag and clearly presents
>> >   how it would be used within the DMARC context by Domain Owners and
>> >   Mail Receivers.
>> >
>> >I don't believe we can actually remove said tag from the IANA registry,
>> >but we can mark them as "historic", and remove the text from the
>> >new document.
>>
>> Marking it "historic" seems appropriate, since that'll keep future
>> versions
>> of DMARC from using it for something else.
>>
>> --
>> 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
>>
>
> +1
>
> Michael Hammer
>
> ___
> 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] Consensus Sought - Ticket #50 (Remove ri= tag) - With Interim Notes

[Tim Wicinski]

All,

This is the current text in Section 10.4 of dmarc-bis

   Names of DMARC tags must be registered with IANA in this new sub-
   registry.  New entries are assigned only for values that have been
   documented in a manner that satisfies the terms of Specification
   Required, per [RFC8126].  Each registration must include the tag
   name; the specification that defines it; a brief description; and its
   status, which must be one of "current", "experimental", or
   "historic".  The Designated Expert needs to confirm that the provided
   specification adequately describes the new tag and clearly presents
   how it would be used within the DMARC context by Domain Owners and
   Mail Receivers.

I don't believe we can actually remove said tag from the IANA registry,
but we can mark them as "historic", and remove the text from the
new document.

Someone should consult with the IANA folks for specifics.
I'll volunteer to take point if so desired.

tim



On Fri, May 28, 2021 at 11:44 AM Todd Herr  wrote:

> Greetings.
>
> Consensus on Ticket #50 
> (Remove ri= tag) was reached during the May 27 DMARC Interim to remove the
> tag and update the IANA registry to reflect its removal.
>
> I seek consensus from the working group at large on this ticket, and
> request that a decision be made by Friday, June 11. Discussions about this
> issue should be contained in this thread.
>
> Thank you.
>
> --
>
> *Todd Herr* | Sr. Technical Program Manager
> *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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Notes from DMARC interim teleconference, 27 May 2021

[Tim Wicinski]

t refer to the known extensions?
> * Barry: just refer to them informationally (non normative)
> * Dave: question of directionality - having the core spec refer to
> extensions is not a good approach; the extensions should refer back to
> the core for referential integrity
> * Seth: the generic reporting mechanism in the core spec should define
> the framework for the information, the extensions provide the details
> on how said framework gets filled in for the details of the protocol
> * Ale: makes sense, can do a generic extension
> * Alex: wants to be clear - other auth methods should be entirely part
> of the extensions
> [Seth had to leave]
> * Kurt: would like to see details
> * Alex: trying to avoid breaking the base part of the report
> * Michael: as long as we provide for extensions, then it is just
> defined within the XML
> * Alex: any XSD definition could be OK for an extension
> * Kurt: seems like some data might fit better at the row level, some
> separate
> * Ale: can we have a registry of extensions?
> * Alex: would like to be able to give receivers a chance to provide other
> data
> * Michael: creating a general reporting tool seems like it is too large in
> scope
> * Alex: is there value in making this super general
> * Michael: various providers have various other data available, narrow
> is better, keep close ties to auth
> * Kurt: seems like a repeat of the general/overly complex/hypothetical
> discussion
> * Laura: if you give people a chance to do this, then they probably
> will - even if it isn't useful
> * problems with standards "semi-compliance" by big providers will
> probably lead to complications handling the reports
> * Alex: if we limit this to official IETF extensions, does that help?
> * Laura: these reports are about auth failures, not general email
> stuff; for that, maybe abuse X-ARF
> * Laura: don't give them free-form extension capabilites
> * Laura: most senders rely on report processors to consume the reports
> and make them meaningful; the extra details will probably not get back
> to the senders
> * Alex: will start a new thread to the list (Next week)
> * Steve: seems like there are deeper existential issues to be resolved
>
> ## Failure reporting (Steve)
> * [Ticket 55] - may have been addressed
> * [Ticket 28] - report driven mail loops - thought it was closed, but
> then looked like Murray re-opened it
> * Ale: liked the proposal from John L (on the list)
> * Steve: will review the mail thread
> * John L: mail loop thing was deep in the "don't do that" category -
> out of scope to solve in the spec
>
> ## What would we have to do in order to bring this project (DMARCbis)
> to closure? and possible timeline
> Barry: was this productive? Should we do more?
> Generally: yes
> Dave: need to beware of having sync meetings become primary - only use
> interims for complicated/intractable issues
> Barry: the chairs are aware and things will be kept in line
> Michael: this does keep things moving forward
> Barry: need to make sure that we are actually having discussions on
> the mailing list and using the teleconferences to follow up on that,
> not just using the mailing list to rubber-stamp the teleconferences
>
> ## AOB
> * Next steps - Todd will open individual threads on the ML about each
> item for general consensus
> * Murray - congratulations on getting PSD published
> * Is anyone tracking the progress of the "experiments"?
> * Having data will really help down the road
>
>
> -
> Attendees (name, affiliation):
> 1. Barry Leiba, Futurewei Technologies, chair
> 2. Seth Blank, Valimail, chair
> 3. Murray Kucherawy, Facebook, AD
> 4. Todd Herr, Valimail, DMARCbis editor
> 5. Autumn Tyr-Salvia, Agari
> 6. Kurt Andersen, Blameless
> 7. Tim Wicinski
> 8. Alex Brotman, Comcast
> 9. Laura Atkins, Word to the Wise
> 10. John Levine, Taughannock
> 11. Michael Hammer, AugTagger, Inc.
> 12. Alessandro Vesely, tana
> 13. Dave Crocker, Brandenberg InternetWorking
> 14. Matthäus Wander, bsi.bund.de
> 15. Doug Foster
> 16. Michael Richardson, Sandelman Software Works Inc
> 17. Steve Jones, DMARC.org
> -
>
> ___
> 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

[dmarc-ietf] Fwd: New Version Notification for draft-ietf-dmarc-psd-13.txt

[Tim Wicinski]

All

This version incorporates all comments from the IESG reviews.
There were a number of clarifying comments and editorial edits in here.

Thanks
tim


-- Forwarded message -
From: 
Date: Tue, May 25, 2021 at 4:14 PM
Subject: New Version Notification for draft-ietf-dmarc-psd-13.txt
To: Scott Kitterman , Tim Wicinski 



A new version of I-D, draft-ietf-dmarc-psd-13.txt
has been successfully submitted by Tim Wicinski and posted to the
IETF repository.

Name:   draft-ietf-dmarc-psd
Revision:   13
Title:  Experimental DMARC Extension For Public Suffix Domains
Document date:  2021-05-25
Group:  dmarc
Pages:  15
URL:https://www.ietf.org/archive/id/draft-ietf-dmarc-psd-13.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-13

Abstract:
   Domain-based Message Authentication, Reporting, and Conformance
   (DMARC) permits a domain-controlling organization to express domain-
   level policies and preferences for message validation, disposition,
   and reporting, which a mail-receiving organization can use to improve
   mail handling.

   DMARC distinguishes the portion of a name that is a Public Suffix
   Domain (PSD), below which organizational domain names are created.
   The basic DMARC capability allows organizational domains to specify
   policies that apply to their subdomains, but it does not give that
   capability to PSDs.  This document describes an extension to DMARC to
   fully enable DMARC functionality for PSDs.

   Some implementations of DMARC consider a PSD to be ineligible for
   DMARC enforcement.  This specification addresses that case.




The IETF Secretariat
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-psd-12: (with DISCUSS and COMMENT)

[Tim Wicinski]

On Tue, May 11, 2021 at 12:24 AM Benjamin Kaduk  wrote:

> Hi Tim,
>
>
> > >
> > > --
> > > COMMENT:
> > > --
> > >
> > > This document is generally in pretty good shape; my comments (and,
> > > to some extent, my discuss as well) are pretty minor points.
> > >
> > > Thanks to Sandra Murphy for the secdir review.  I think there were some
> > > questions in there that are worth a response and possibly
> clarifications
> > > in the document.
> > >
> > >
> > Sandra did a strong review and I believe we worked through the issues
> > raised.
>
> I'm happy to hear it; I may have just been misled by the mailarchive entry
> for the secdir list.
>

There was a Large GENART review that had us rework several sections
which were ones that Sandra had also mentioned.  I will go back and
read her email again just to make sure.


> >
> > > Section 1.2
> > >
> > > It seems like the "branded PSD" and "multi-organization PSD" cases
> would
> > > benefit from a protocol-level indication and separate handling by
> > > message recipients.  It seems likely that the newly defined np (in
> > > combination with the preexisting sp) provides the flexibility to
> > > describe the different cases, but it seems like it would be helpful to
> > > have some discussion in this document that relates these two cases to
> > > the actual protocol mechanisms used to achieve them.
> > >
> > >
> > There is no different handling of between a "Branded PSD" and a
> > "multi-organization PSD".  The difference is highlighting the types.
>
> I think I agree that the actual mechanics of handling the protocol
> elements, if they exist, shouldn't really differ for the two cases.  It
> seems that there may be some subjective differences, though, in that it
> would be really surprising if the "multi-organizational PSD" decided to
> publish policy for existant subdomains, whereas for branded PSDs that is
> normal and expected, since in some sense they really ought not be PSDs at
> all.
>

Consider the case of the bad actor attempting to publish
a "multi-organizational PSD" policy for purposes of
pervasive monitoring.   One of the reasons for the registry
is to prevent such actions.


>
> >
> > > Section 4.1
> > >
> > >o  Multi-organization PSDs (e.g., ".com") that do not mandate DMARC
> > >   usage: Privacy risks for Organizational Domains that have not
> > >   deployed DMARC within such PSDs are significant.  For non-DMARC
> > >   Organizational Domains, all DMARC feedback will be directed to
> the
> > >   PSO.  PSD DMARC is opt-out (by publishing a DMARC record at the
> > >   Organizational Domain level) vice opt-in, which would be the more
> > >   desirable characteristic.  This means that any non-DMARC
> > >   organizational domain would have its feedback reports redirected
> > >   to the PSO.  The content of such reports, particularly for
> > >   existing domains, is privacy sensitive.
> > >
> > > It might be worth making some statement about the applicability of PSD
> > > DMARC for such PSDs that do not mandate DMARC usage.  (I guess the
> > > following paragraphs mostly play that role, though perhaps editorially
> > > tying them together more clearly is possible.)
> > >
> >
> > I'm not sure where you're going on this, but the following paragraphs do
> > try to pull it together.  I've been trying to wordsmith these with little
> > luck.
> >
> > Also, it appears that the word "vice" above should be "versus".
>
> I suspected it might :)
>
> Maybe the following is useful input to your wordsmithing attempts:
>
> By definition the new mechanisms in this document result in PSDs receiving
> feedback on non-existent domains.  However, these non-existent domains may
> be similar to existing Organizational Domains, and as mentioned above,
> feedback on existing organizational domains is privacy-sensitive.  To
> minimize the risk of privacy-sensitive information relating to existing
> organizational domains being sent to the parent as feedback on a similar
> non-existent domain, PSD DMARC feedback MUST be limited to Aggregate
> Reports.  Feedback Reports carry more detailed information and present a
> greater risk.
>


Thanks.  I'm want to also see what the working group thinks/feels
on the current text and your suggestions.


> >
> >
> > > Or, in the vein of my comment on section 1.2, an explicit protocol
> > > mechanism could be introduced that limits the reporting to just the
> > > indicated (public suffix) domain and does not apply to subdomains.
> > >
> > >organizational PSDs MUST be limited to non-existent domains except
> in
> > >cases where the reporter knows that PSO requires use of DMARC.
> > >
> > > Do we have examples of how the reporter might come to know this?
> > > Say ... Appendix B.2?
> > >
> > >
> > Roman raised a similiar point.   I was thinking of adding
> > 

Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-psd-12: (with DISCUSS and COMMENT)

[Tim Wicinski]

Ben

On Wed, Apr 21, 2021 at 1:04 AM Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dmarc-psd-12: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/
>
>
>
> --
> DISCUSS:
> --
>
> There seems to be a bit of internal inconsistency in Appendix B.2:
>
>Names of PSDs participating in PSD DMARC must be registered this new
>registry.  New entries are assigned only for PSDs that require use of
>DMARC.  [...]
>
> These two sentences seem to be in conflict, since a PSD can participate
> in PSD DMARC without requiring use of DMARC for all its subdomains.  The
> rest of the section is clear that the registry is only intended to be
> for PSDs that do require the use of DMARC for subdomains, so I expect
> that a minor tweak to the wording of "PSDs participating in PSD DMARC"
> would be an appropriate fix.
>
>
I reworded these two sentences to say:

PSDs that are deploying DMARC and are participating in PSD DMARC
must register their public suffix domain in this
new registry.


Does this sound better ?


>
> --
> COMMENT:
> --
>
> This document is generally in pretty good shape; my comments (and,
> to some extent, my discuss as well) are pretty minor points.
>
> Thanks to Sandra Murphy for the secdir review.  I think there were some
> questions in there that are worth a response and possibly clarifications
> in the document.
>
>
Sandra did a strong review and I believe we worked through the issues
raised.


> Section 1.2
>
> It seems like the "branded PSD" and "multi-organization PSD" cases would
> benefit from a protocol-level indication and separate handling by
> message recipients.  It seems likely that the newly defined np (in
> combination with the preexisting sp) provides the flexibility to
> describe the different cases, but it seems like it would be helpful to
> have some discussion in this document that relates these two cases to
> the actual protocol mechanisms used to achieve them.
>
>
There is no different handling of between a "Branded PSD" and a
"multi-organization PSD".  The difference is highlighting the types.


> Section 3
>
> As Lars and Éric already commented, I suggest using a phrasing that
> includes something like "this experiment" and maybe "proposes", since
> actually formally updating the DMARC specification would procedurally be
> a bit exciting.
>
>
I've updated this text.

Section 3.2
>
>np:  Requested Mail Receiver policy for non-existent subdomains
>   (plain-text; OPTIONAL).  Indicates the policy to be enacted by the
>
> I assume that "subdomains" here refers only to direct children (i.e.,
> one additional label), not deeper in the hierarchy.  It's not entirely
> clear to me whether all readers will do likewise, though...
>
>
It is the direct subdomain.   There is discussion inb RFC7489 if a subdomain
does not have a _dmarc DNS record, the _dmarc record at the parent domain is
query/used.


> Section 3.3, 3.6
>
> It sounds like this entire paragraph is appended to the section?
> In other subsections we are a bit more explicit about where the new text
> is going and what part is the new text.
>
>
I added this text to the beginning of each paragraph:

If this experiment is successful, this paragraph is added to this
setion.

Does that help?



> Section 4.1
>
>o  Multi-organization PSDs (e.g., ".com") that do not mandate DMARC
>   usage: Privacy risks for Organizational Domains that have not
>   deployed DMARC within such PSDs are significant.  For non-DMARC
>   Organizational Domains, all DMARC feedback will be directed to the
>   PSO.  PSD DMARC is opt-out (by publishing a DMARC record at the
>   Organizational Domain level) vice opt-in, which would be the more
>   desirable characteristic.  This means that any non-DMARC
>   organizational domain would have its feedback reports redirected
>   to the PSO.  The content of such reports, particularly for
>   existing domains, is privacy sensitive.
>
> It might be worth making some statement about the applicability of PSD
> DMARC for such PSDs that do not mandate DMARC usage.  (I guess the
> following paragraphs mostly play that role, though perhaps editorially
> tying them together more clearly is possible.)
>

Re: [dmarc-ietf] Roman Danyliw's No Objection on draft-ietf-dmarc-psd-12: (with COMMENT)

[Tim Wicinski]

On Wed, Apr 21, 2021 at 4:38 PM Roman Danyliw via Datatracker <
nore...@ietf.org> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-dmarc-psd-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/
>
>
>
> --
> COMMENT:
> --
>
> Thank you to Sandra Murphy for the SECDIR review.  Please review those
> proposed
> clarifying edits.
>

Thanks. I believe we've gone over all of them.




>
> ** Section 4.1
> Due to the inherent Privacy and Security risks associated with PSD
>DMARC for Organizational Domains in multi-organization PSDs that do
>not particpate in DMARC, any Feedback Reporting related to multi-
>organizational PSDs MUST be limited to non-existent domains except in
>cases where the reporter knows that PSO requires use of DMARC.
>
> Is there any guidance on how the reporter might know “that [the] PSO
> requires
> use of DMARC”.
>

In the above paragraphs in this section, it defines Multi-organization
PSDs that require DMARC usage and Multi-organization PSDs that do not
require DMARC usage.
Any Advice?



>
> ** Section B.2.
> -- Please define the semantics of the “status” column and the
> expected/possible
> values
>

This is defined in RFC7489, Section 11.4.  I added the following text:
The "Status" column is defined in Section 11.4.



> -- Reconcile the differences between the initial values noted in this this
> document and those at http://psddmarc.org/registry.html: o the text in
> this
> section says “current” for the status column, but the html page has same
> values
> as set to “active”
>
> o the PSD names in the initial values of this document are of the form
> “.*”,
> but the html page has no leading dot (i.e., “.bank” vs. “bank”)
>
>
Thanks, I've reached out to have this corrected


tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Tim Wicinski]

Folks that deploy wildcard MX usually have a reason.   It may not be a
reason that makes sense to others,
but there's usually a reason.

In those cases, np won't work.  We should perhaps spell that out in the
text a bit more clearly.

On Fri, May 7, 2021 at 5:13 PM John Levine  wrote:

> It appears that Douglas Foster  
> said:
> >Is there a query or collection of queries that can ensure that we only
> >accept results from the identifier domain and not from the parent?
>
> This is a meaningless question.  DNS queries ask about a specific name
> and RRTYPE and you get back the answer for that name and RRTYPE.
>
> >*Wildcard DNS:*
> >
> >Wildcard entries create intentional ambiguity.
>
> That is simply false.  Wildcards are perfectly well defined.  I have
> occasionally found wildcard MX records to be useful.
>
> I have taken another look at ticket #111 and found that the questions
> it asks misunderstand both the way that the DNS works and the way that
> SMTP has used the DNS since RFC 1123 over 30 years ago.
>
> Please close this ticket, there is nothing to fix.
>
> R's,
> John
>
> ___
> 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] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation

[Tim Wicinski]

I will be able to attend.

I will ask the kind chairs that once an Interim is scheduled, you could
send a calendar invite with all the details for those of us unable to
function
without one?

thanks
tim


On Thu, May 6, 2021 at 11:08 AM John Levine  wrote:

> It appears that Seth Blank   said:
> >The Chairs ask group participants to explicitly speak up if:
> >1) they intend to participate in the interim
> >or 2) they wish to participate in the interim, but the timing does not
> work
>
> I can do it at that time.
>
> R's,
> John
>
> ___
> 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] Robert Wilton's No Objection on draft-ietf-dmarc-psd-12: (with COMMENT)

[Tim Wicinski]

Robert,


On Mon, Apr 19, 2021 at 12:52 PM Robert Wilton via Datatracker <
nore...@ietf.org> wrote:

> Robert Wilton has entered the following ballot position for
> draft-ietf-dmarc-psd-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/
>
>
>
> --
> COMMENT:
> --
>
> Thanks for this document.  A few minor clarifying comments that may help
> this
> document:
>
>o  Branded PSDs (e.g., ".google"): These domains are effectively
>   Organizational Domains as discussed in [RFC7489].  They control
>   all subdomains of the tree.  These are effectively private
>   domains, but listed in the current public suffix list.  They are
>   treated as Public for DMARC purposes.  They require the same
>   protections as DMARC Organizational Domains, but are currently
>   unable to benefit from DMARC.
>
> I found this paragraph confusing.  In "These are effectively private
> domains",
> it wasn't clear to me what "these" refers to.  Is it the domains or the
> subdomains.   Otherwise it says "these are effectively" twice, with two
> different descriptions.  Perhaps, check if this paragraph can be reworded
> to
> make it clearer.


How about instead of
"These are effectively private domains, but listed in the current public
suffix list." to
"Branded PSDs are private domains currently listing in the public suffix
list."

Would that work?


>
>   These
>   issues are not typically applicable to PSDs, since they (e.g., the
>   ".gov.example" used above) do not typically send mail.
>
> I presume that this means that emails are not directly sent from
> @gov.example,
> rather than there is no mail below .gov.example.  Perhaps worth clarifying?
>

Would this clarify things better?

"These issues are not typically applicable to PSDs, since the PSD itself
(e.g., the ".gov.example" used above)
does not typically send mail. "


>
> For DMARC purposes, a non-existent domain is a domain for which there
>is an NXDOMAIN or NODATA response for A, , and MX records.  This
>is a broader definition than that in NXDOMAIN [RFC8020].
>
> I presume that this means that there is no response for any of A,  and
> MX
> records, not that there is no response for a particular type of record.
> Should
> this be clarified? Although arguably it seems pretty obvious.
>
>
I think adding more here will muddy the waters.  I am willing to be swayed.

tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Éric Vyncke's No Objection on draft-ietf-dmarc-psd-12: (with COMMENT)

[Tim Wicinski]

Eric

I agree that a section with one subsection is a bit too much.
I'll add my text and see how it all looks.

tim


On Mon, Apr 19, 2021 at 1:27 PM Eric Vyncke (evyncke) 
wrote:

> Tim,
>
>
>
> Why not ?
>
>
>
> Or even going simpler and removing the sub-section title (keeping the text
> of course)
>
>
>
> As you can guess, this is purely cosmetic, so, feel free to ignore my
> suggestion
>
>
>
> Kind regards
>
>
>
> -éric
>
>
>
> *From: *Tim Wicinski 
> *Date: *Monday, 19 April 2021 at 17:36
> *To: *Eric Vyncke 
> *Cc: *The IESG , "draft-ietf-dmarc-...@ietf.org" <
> draft-ietf-dmarc-...@ietf.org>, "dmarc-cha...@ietf.org" <
> dmarc-cha...@ietf.org>, IETF DMARC WG , Alexey Melnikov <
> alexey.melni...@isode.com>
> *Subject: *Re: Éric Vyncke's No Objection on draft-ietf-dmarc-psd-12:
> (with COMMENT)
>
>
>
>
>
>
>
> On Fri, Apr 16, 2021 at 1:43 AM Eric Vyncke (evyncke) 
> wrote:
>
> Tim,
>
>
>
> Thank you for your quick reply and the updates to the document.
>
>
>
> My comment on section 5.1 was actually on section 4.1 ... Sorry about the
> mix, I should drink more coffee it seems :-o
>
>
>
>
>
> Ahh, I see what you are referring to.  I think it was written as a
> subsection with the thought of adding this
>
> section to the Privacy Considerations section of the DMARC-bis document.
>  Perhaps some wording to reflect this?
>
> "If this experiment is successful, this section should be incorporated
> into the Privacy Considerations section
>
> of DMARC-bis" ?
>
>
>
> tim
>
>
>
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Éric Vyncke's No Objection on draft-ietf-dmarc-psd-12: (with COMMENT)

[Tim Wicinski]

On Fri, Apr 16, 2021 at 1:43 AM Eric Vyncke (evyncke) 
wrote:

> Tim,
>
>
>
> Thank you for your quick reply and the updates to the document.
>
>
>
> My comment on section 5.1 was actually on section 4.1 ... Sorry about the
> mix, I should drink more coffee it seems :-o
>
>
>

Ahh, I see what you are referring to.  I think it was written as a
subsection with the thought of adding this
section to the Privacy Considerations section of the DMARC-bis document.
 Perhaps some wording to reflect this?
"If this experiment is successful, this section should be incorporated into
the Privacy Considerations section
of DMARC-bis" ?

tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Éric Vyncke's No Objection on draft-ietf-dmarc-psd-12: (with COMMENT)

[Tim Wicinski]

Eric

On Thu, Apr 15, 2021 at 3:17 AM Éric Vyncke via Datatracker <
nore...@ietf.org> wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-dmarc-psd-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for the work put into this document. It is easy to read and
> specify
> an experiment, which could be useful.
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated), and some nits.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == COMMENTS ==
>
> -- Sections 1 and 3--
> I share Lars' concern about the "update" in the last paragraph.
>
> -- Section 5.1 --
> Editorial comment: why using a sub-section ? Let's 'glue' its contents to
> the
> first § of section 5. BTW, interesting read this section.
>
>
Section 5 is Security Considerations and has no subsections. Am I missing
something?

> == NITS ==
>
> -- Section 2.2 --
> Unsure whether "Requests for Comment (RFC)" is really required ;-) cfr
> https://www.rfc-editor.org/materials/abbrev.expansion.txt
>
>
Agreed, and fixed.

> -- Sections 2.2 ... 2.7 --
> Mostly cosmetic but I would have preferred the usual presentation to
> introduce
> terminology, i.e., a list and not several sub-sections.
>
>
Maybe we can make this a note for the RFC Editor ?

tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Lars Eggert's No Objection on draft-ietf-dmarc-psd-12: (with COMMENT)

[Tim Wicinski]

Lars

See below. Thanks for the comments


On Wed, Apr 14, 2021 at 4:44 AM Lars Eggert via Datatracker <
nore...@ietf.org> wrote:

> Lars Eggert has entered the following ballot position for
> draft-ietf-dmarc-psd-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/
>
>
>
> --
> COMMENT:
> --
>
> Section 3, paragraph 2, comment:
> > 3.  PSD DMARC Updates to DMARC Requirements
> >
> >This document updates DMARC as follows:
>
> If I understand things correctly, this document specifies an experiment
> that -
> if successful - would lead to an update of RFC7489. It's therefore
> confusing to
> see the text in Section 3 that is written as if that update was already
> being
> brought into effect. I'd much prefer text that said things like "to
> participate
> in this experiment, implementations should do X or Y or Z and/or interpret
> Section foo of RFC7489 as bar", etc.
>
>
"To participate in this experiment, implementations should nterept RFC7489
as follows"



> Section 7.3, paragraph 1, comment:
> > 7.3.  URIs


This appears to be some artifact of the XML as the URI is listed in the
Informative
Reference section.


>


> It's unusual for an RFC to have reference sections other than for
> normative and
> informative references, because it's not clear what category references
> here
> would fall into. Also, I'll note that [psddmarc.org] was cited as an
> informative
> reference in that section, so why not this one?
>
>
> ---
> All comments below are very minor change suggestions that you may choose to
> incorporate in some way (or ignore), as you see fit. There is no need to
> let me
> know what you did with these suggestions.
>
> Section 3.2, paragraph 3, nit:
> >   to that of the "p" tag defined below.  If the 'np' tag is absent,
>
> The document uses both single and double quotes throughput (above is an
> example), and it's not clear if this is deliberate (i.e., there is a
> meaning to
> this) or whether this is an editorial oversight that should be corrected.
>
>

I believe I've corrected all of these quote mismatches (that is, I've found
all the
single quoted mentions and have updated them to double quotes).


> Section 6.1, paragraph 5, nit:
> >+--+---+-+---+
> >| Tag Name | Reference | Status  | Description   |
> >+--+---+-+---+
> >| np   | this  | current | Requested handling policy for |
> >|  | document  | | non-existent subdomains   |
> >+--+---+-+---+
> >
>
> You should add an RFC Editor Note instructing them to replace "this
> document"
> with the RFC number of this document (to make sure they are aware of the
> action).
>
>
Done


> Section 1, paragraph 2, nit:
> -DMARC ([RFC7489]) provides a mechanism for publishing organizational
> -  - -
> +DMARC [RFC7489] provides a mechanism for publishing organizational
>
>
Fixed

> Section 1, paragraph 3, nit:
> -found in Section 3.2 of the DMARC specification.  Currently the
> +found in Section 3.2 of the DMARC specification.  Currently, the
> +   +
>
> Section 1, paragraph 4, nit:
> -In the basic DMARC model, PSDs are not organizational domains and are
> +In the basic DMARC model, Public Suffix Domains (PSDs) are not
> organizational domains and are
> +   +++   +
>
>
Fixed

> Section 1.2, paragraph 7, nit:
> -handling policy for non-existent subdommains.  This is provided
> -   -
> +handling policy for non-existent subdomains.  This is provided
>
>
Fixed

> Section 1.2, paragraph 7, nit:
> -of requesting harsh policy treatment (e.g. reject) is lower.
> +of requesting harsh policy treatment (e.g., reject) is lower.
> +  +
>
> Section 1.2, paragraph 8, nit:
> -(i.e. if a DMARC record were published for 'example', then mail from
> +(i.e., if a DMARC record were published for 'example', then mail from
> + +
>
>
Fixed



> Section 2.7, paragraph 2, nit:
> -is a broader definition than that in NXDOMAIN [RFC8020].
> -   

Re: [dmarc-ietf] NXDOMAIN

[Tim Wicinski]

Can you point me to some of the tests you are running? you can do that
offline.

you also want to do some testing with domains signed with DNSSEC and those
without.

This came up as an issue in opendmarc:

https://github.com/trusteddomainproject/OpenDMARC/issues/103#issuecomment-810036114





On Mon, Apr 5, 2021 at 5:02 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> As a result of earlier discussions, I have been investigating NXDOMAIN as
> an email filtering criteria.
>
> One question from those discussions was the best way to detect NXDOMAIN.
> I realized that I needed a query which specifically returns NXDOMAIN as a
> result, not simply the absence of a particular result.   Additionally, a
> lookup on A/ with results could represent either a domain name with no
> host segment, or a host segment and a parent domain..   Consequently, the
> best test seems to query for type=TXT, match=domainname.
>
> I have applied this rule to incoming RFC5322.MailFrom addresses and found
> the test to be useful.  For my mail stream, 20% of the messages with
> SPF=NONE have this result because of NXDOMAIN.  The percentages were
> roughly equal whether evaluating unique domain names or unique messages.
>
> While both SPF=NONE and SPF=NXDOMAIN are indicators that the message is
> probably unwanted, NXDOMAIN has a higher probability of being unwanted.
>
> I have not yet begun evaluating NXDOMAIN on the RFC5322.From address, but
> hope to get that done in the weeks ahead.
>
> Is anyone else collecting data on NXDOMAIN, and able to share experience?
> ___
> 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] I-D Action: draft-ietf-dmarc-psd-11.txt

[Tim Wicinski]

Oh shoot y'all I removed "obviously" once, then accidentally added it back
in.

My mistake.



On Mon, Mar 22, 2021 at 11:41 AM Dave Crocker  wrote:

>
>
>> NEW
>>
>>Defensively registering all variants of "tax" is obviously not a
>>scalable strategy.  The intent of this specification, therefore, is
>>to enhance the DMARC discovery method by enabling an agent receiving
>>such a message to be able to determine that a relevant policy is
>>present at "gov.example", which is precluded by the current DMARC
>>specification.
>>
>
> Tim,
>
> I still think that including the term "obviously" in the first sentence of
> this snippet is a pejorative judgemental statement which is out of place in
> a specification. Especially given that there are alternatives to
> "registering" any such domains at all via the use of "trick" DNS servers at
> the PSD level.
>
>
> Even worse is the demonstrable fact that it is far from obvious to many
> people and businesses.  Buying up cousin domains remains an active line of
> effort for (some) companies.
>
> Consequently, the requirement here is to explain why it isn't scalable,
> rather than to simple assert the fact.
>
>
> d/
>
> --
> Dave crockerdcroc...@gmail.com
> 408.329.0791
>
> Volunteer, Silicon Valley Chapter
> Information & PLanning Coordinator
> American Red crossdave.crock...@redcross.org
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-11.txt

[Tim Wicinski]

All

Alessandro had some very good suggestions, but I was looking at the
document,
there were a few other mentions of PSL and I wanted to think it through.

I have some suggested text I'd like to hear some feedback on.

First though, in going over the document again, I also
found where the word "from" was repeated twice in Appendix C.2,
and I updated the reference to RFC5226 with RFC8126

---


In the Introduction, the suggested change is

OLD

   To determine the organizational domain for a message under
   evaluation, and thus where to look for a policy statement, DMARC
   makes use of a Public Suffix List.  The process for doing this can be
   found in Section 3.2 of the DMARC specification.

NEW
   To determine the organizational domain for a message under
   evaluation, and thus where to look for a policy statement, DMARC
   makes use of a public suffix list.  The process for doing this can be
   found in Section 3.2 of the DMARC specification.  Currently the
   public suffix list being used is the most common one that is
   maintained by the Mozilla Foundation and made public at
   http://publicsuffix.org [1].

The document never points to the current PSL, only to 7489. What I'm adding
is more informative to assist folks reading this who are not immersed in
DMARC.

OLD

   This document specifies experimental updates to the DMARC and PSL
   algorithm cited above, in an attempt to mitigate this abuse.

NEW

   This document specifies experimental updates to the DMARC
   specification cited above, in an attempt to mitigate this abuse.

In Section 1.1 "Example"

OLD

   Defensively registering all variants of "tax" is obviously not a
   scalable strategy.  The intent of this specification, therefore, is
   to enhance the DMARC algorithm by enabling an agent receiving such a
   message to be able to determine that a relevant policy is present at
   "gov.example", which is precluded by the current DMARC algorithm.


NEW

   Defensively registering all variants of "tax" is obviously not a
   scalable strategy.  The intent of this specification, therefore, is
   to enhance the DMARC discovery method by enabling an agent receiving
   such a message to be able to determine that a relevant policy is
   present at "gov.example", which is precluded by the current DMARC
   specification.


In section 1.2 "Discussion", this will change.

OLD
   o  Branded PSDs (e.g., ".google"): These domains are effectively
  Organizational Domains as discussed in [RFC7489].  They control
  all subdomains of the tree.  These are effectively private
  domains, but listed in the Public Suffix List.  They are treated
  as Public for DMARC purposes.

NEW

   o  Branded PSDs (e.g., ".google"): These domains are effectively
  Organizational Domains as discussed in [RFC7489].  They control
  all subdomains of the tree.  These are effectively private
  domains, but listed in the current public suffix list.  They are
  treated as Public for DMARC purposes.


In Appendix B.3, the "PSD Extension" is slightly changed.

OLD

   [psddmarc.org] provides a PSL like file to facilitate
   identification of PSD DMARC participants.  Contents are functionally
   identical to the IANA like registry, but presented in a different
   format.

NEW

   [psddmarc.org] provides a file formatted like the Public Suffix List
   (PSL) in order to facilitate identification of PSD DMARC
   participants.  Contents are functionally identical to the IANA like
   registry, but presented in a different format.






Welcome feedback

thanks

tim



On Sat, Mar 20, 2021 at 7:41 AM Alessandro Vesely  wrote:

> On Sat 20/Mar/2021 01:38:40 +0100 Tim Wicinski wrote:
> >> NEW
> >>  o  Branded PSDs (e.g., ".google"): These domains are effectively
> >> Organizational Domains as discussed in [RFC7489].  They control
> >> all subdomains.  These are effectively private
> >> domains, but listed in the Public Suffix List.  They are treated
> >> as Public for DMARC purposes.  They require the same protections
> >> as DMARC Organizational Domains, but are currently unable to
> >> benefit from DMARC.
> >>
> > Hmm, "Public Suffix List" is in this paragraph.  Needs rethinking.
>
>
> Oops, I missed a couple of those "Public Suffix List" entries.  That term
> was
> where the conundrum stemmed from, possibly because we're unsure how much
> we
> want to bind DMARC to the only PSL implementation we know.  That's why we
> want
> to avoid that term.
>
> OTOH, the term "Public Suffix Domain" (PSD), seems to be sound.  It is
> often
> defined as "a domain under which multiple parties that are unaffiliated
> with
> the owner of the 

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-11.txt

[Tim Wicinski]

On Fri, Mar 19, 2021 at 12:28 PM Alessandro Vesely  wrote:

> On Fri 19/Mar/2021 15:09:31 +0100 internet-drafts wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > [...]
>
>
> Much better!
>
> There's still a few style points that I'd propose.  They can be dealt with
> in
> auth48.
>
>
> *Introduction*
>
> The PSL is not mentioned yet.  Therefore:
>
> OLD:
> This document specifies experimental updates to the DMARC and PSL
> algorithm cited above, in an attempt to mitigate this abuse.
>
> NEW
> This document specifies experimental updates to the DMARC specification
> in an attempt to mitigate this abuse.
>
>
Updated

>
> *Example*
>
> Since the algorithm (last word) hasn't been mentioned yet:
>
> OLD
> Defensively registering all variants of "tax" is obviously not a
> scalable strategy.  The intent of this specification, therefore, is
> to enhance the DMARC algorithm by enabling an agent receiving such a
> message to be able to determine that a relevant policy is present at
> "gov.example", which is precluded by the current DMARC algorithm.
>
>
> NEW
> Defensively registering all variants of "tax" is obviously not a
> scalable strategy.  The intent of this specification, therefore, is
> to enhance DMARC discovering method by enabling an agent receiving
> such a
> message to be able to determine that a relevant policy is present at
> "gov.example", which is precluded by the current DMARC specification.
>

Added Kurt's suggestion and put in a "the". Now reads as

Defensively registering all variants of "tax" is obviously not a scalable
strategy.  The intent of this specification, therefore, is to enhance the
DMARC discovery method by enabling an agent receiving such a
message to be able to determine that a relevant policy is present at
"gov.example", which is precluded by the current DMARC specification.




>
> *Discussion* (optional)
>
> The phrase "of the tree" is useless and can be deleted.  That way, the
> first
> appearance of the term "tree" is deferred to Section 2.2, where it is put
> forth
> cleverly, by implicitly recalling that the term refers to graph theory,
> since
> the root is near to the top.
>
> OLD
> o  Branded PSDs (e.g., ".google"): These domains are effectively
>Organizational Domains as discussed in [RFC7489].  They control
>all subdomains of the tree.  These are effectively private
>domains, but listed in the Public Suffix List.  They are treated
>as Public for DMARC purposes.  They require the same protections
>as DMARC Organizational Domains, but are currently unable to
>benefit from DMARC.
>
>
> NEW
> o  Branded PSDs (e.g., ".google"): These domains are effectively
>Organizational Domains as discussed in [RFC7489].  They control
>all subdomains.  These are effectively private
>domains, but listed in the Public Suffix List.  They are treated
>as Public for DMARC purposes.  They require the same protections
>as DMARC Organizational Domains, but are currently unable to
>benefit from DMARC.
>
Hmm, "Public Suffix List" is in this paragraph.  Needs rethinking.


> *DMARC PSD PSL Extension*
>
> Here comes the first appearance of the string "PSL:
>
> OLD
> [psddmarc.org] provides a PSL like file to enable to facilitate
> identification of PSD DMARC participants.  Contents are functionally
> identical to the IANA like registry, but presented in a different
> format.
>
> NEW
> [psddmarc.org] provides a file formatted like the public suffix list
> (PSL) in order to facilitate the identification of PSD DMARC
> participants.
> Contents are functionally identical to the identical to the IANA like
> registry above, but presented in a different format.
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-11.txt

[Tim Wicinski]

Agree with Murray.

Also, I see changing "Algorithm" to "Specification" makes sense.

looking at the other suggestions

tim

On Fri, Mar 19, 2021 at 7:54 PM Murray S. Kucherawy 
wrote:

> Just to nit-pick:
>
> On Fri, Mar 19, 2021 at 9:28 AM Alessandro Vesely  wrote:
>
>> There's still a few style points that I'd propose.  They can be dealt
>> with in
>> auth48.
>>
>
> After Last Call, please.  Don't wait for AUTH48 to process this feedback.
>
> -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

[dmarc-ietf] Publication has been requested for draft-ietf-dmarc-psd-11

[Tim Wicinski via Datatracker]

Tim Wicinski has requested publication of draft-ietf-dmarc-psd-11 as 
Experimental on behalf of the DMARC working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Using CNAME records to DMARC templates causes issues

[Tim Wicinski]

I have to overly agree with Murray here.

Where there should be discussions around using CNAMEs for DMARC records
would be in
a DMARC best practice document.

I spent some time yesterday digging through all the DKIM RFCs, and there is
no place
where there are discussions about using CNAMEs (Except in passing in
RFC5016).
And the use of using CNAMEs for DKIM TXT records is not just widely used,
but is
consider a best practice by M3AAWG:
https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf

As for those few folks who have seen DNS issues around using CNAMEs, I
really want to
hear from you off list.  Tracking down esoteric DNS error operational
behavior is
something I am slightly obsessive about.   "I'm from the DNS, and I'm here
to help"

thanks
tim


On Wed, Mar 3, 2021 at 12:28 PM Murray S. Kucherawy 
wrote:

> On Tue, Mar 2, 2021 at 3:51 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> Because CNAME usage was not mentioned in the previous DMARC document,
>> existing implementations may not have tested this configuration.   For the
>> policy publishing organization, this increases the possibility that some
>> recipients may treat the mail as not protected by DMARC. As with any
>> deployment issue, the publishing organization has no reliable way to know
>> if the deployment of DMARC implementations with full CNAME support is
>> "essentially complete".  This uncertainty may be acceptable for some
>> organizations, but may be an obstacle for others, depending on their
>> motivations for implementing DMARC.
>>
>> On the implementation side, the use of CNAME will introduce the
>> possibility of referral errors, which may or may not require mentioning in
>> the DMARC specification, since such issues have probably been addressed in
>> core DNS documents.   The issues that come to mind are:
>> CNAME referrals to non-existent names
>> Nested CNAME referrals (what depth is allowed?)
>> CNAME referrals that produce loops or excessive nesting depth.
>>
>
> I don't understand why we need to say anything special about CNAMEs here.
> They are processed by the resolver as they would be for any other
> application.
>
> If there's a bug in opendmarc, that's a different question that has
> nothing to do with the output of the working group.
>
> -MSK
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Using CNAME records to DMARC templates causes issues

[Tim Wicinski]

Using a CNAME at  _dmarc.example should not be a problem, as long as
the CNAME target is a TXT record.  The DNS resolver functions should
should handle this seamlessly. This does sound like a vendor software
problem.

I am aware of DKIM records being deployed using CNAMEs pointing to a TXT
record target.
Has anyone seen the above error condition when testing DKIM records?

This definitely sounds like an issue with the software.

Nobody should shy away from publishing DMARC records that are CNAMEs to
DMARC
TXT records elsewhere. Using this design should be strongly encouraged.

tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Tim Wicinski]

Thanks Barry

I sent a pull request along to Scott with the changes.

I also generated an rfcdiff which I include for completeness sake.

thanks
tim


On Sun, Feb 28, 2021 at 5:02 PM Barry Leiba  wrote:

> It looks right to me.  Thanks, Tim.
>
> Barry
>
> On Sun, Feb 28, 2021 at 4:53 PM Tim Wicinski  wrote:
>
>> I was just working on merging Barry's comments with Dave's and Kurt's.
>>
>> I attached what should be correct.  I would like someone to just double
>> check my work.
>>
>> tim
>>
>>
>> On Sun, Feb 28, 2021 at 4:35 PM Murray S. Kucherawy 
>> wrote:
>>
>>> These all work for me.  Thanks for the contributions.
>>>
>>> Scott, please work your magic with a revision so the chairs can request
>>> publication and we can get this on its way.
>>>
>>> -MSK
>>>
>>> On Thu, Feb 25, 2021 at 9:13 AM Dave Crocker  wrote:
>>>
>>>> On 2/25/2021 8:41 AM, Kurt Andersen (b) wrote:
>>>>
>>>> Especially in the case of the PSD policies, one should not expect that
>>>> the controlling organization would necessarily be "a mail-originating
>>>> organization". Generally the idea is to *disavow* being such :-)
>>>>
>>>> Suggested alternate text:
>>>>
>>>> Domain-based Message Authentication, Reporting, and Conformance (DMARC)
>>>> permits a domain-controlling
>>>> organization to express domain-level policies and preferences for
>>>> message validation, disposition, and reporting,
>>>> which a mail-receiving organization can use to improve mail handling.
>>>>
>>>> +1
>>>>
>>>> d/
>>>>
>>>> --
>>>> Dave crockerdcroc...@gmail.com
>>>> 408.329.0791
>>>>
>>>> Volunteer, Silicon Valley Chapter
>>>> American Red crossdave.crock...@redcross.org
>>>>
>>>> ___
>>>> 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
>>>
>>
Title: Diff: draft-ietf-dmarc-psd-11.txt - draft-ietf-dmarc-psd-10.txt
 
 

 
 
 
 
 
 
 
   
   draft-ietf-dmarc-psd-11.txt   draft-ietf-dmarc-psd-10.txt  
   
  Network Working Group   S. Kitterman Network Working Group   S. Kitterman
  Internet-DraftfTLD Registry Services Internet-DraftfTLD Registry Services
  
  Intended status: ExperimentalJanuary 1, 2021 Intended status: Experimental   January 23, 2021
  Expires: July 5, 2021 Expires: July 27, 2021
   
   Experimental DMARC Extension For Public Suffix Domains  Experimental DMARC Extension For Public Suffix Domains
  
  draft-ietf-dmarc-psd-11 draft-ietf-dmarc-psd-10
   
  Abstract Abstract
   
  
 Domain-based Message Authentication, Reporting, and ConformanceDMARC (Domain-based Message Authentication, Reporting, and
 (DMARC) permits a domain-controlling organization to express domain-Conformance) is a scalable mechanism by which a mail-originating
 level policies and preferences for message validation, disposition,organization can express domain-level policies and preferences for
 and reporting, which a mail-receiving organization can use to improvemessage validation, disposition, and reporting, that a mail-receiving
 mail handling.organization can use to improve mail handling.  The design of DMARC
  presumes that domain names represent either nodes in the tree below
  which registrations occur, or nodes where registrations have
  occurred; it does not permit a domain name to have both of these
  properties simultaneously.  Since its deployment in 2015, use of
  DMARC has shown a clear need for the ability to express policy for
  these domains as well.
   
  
 DMARC distinguishes the portion of a name that is a Public SuffixDomains at which registrations can occur are referred to as Public
 Domain (PSD), below which organizational domain names are created.Suffix Domains (PSDs).  This document describes an extension to DMARC
 The basic DMARC capability allows organizational domains to specifyto enable D

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Tim Wicinski]

I was just working on merging Barry's comments with Dave's and Kurt's.

I attached what should be correct.  I would like someone to just double
check my work.

tim


On Sun, Feb 28, 2021 at 4:35 PM Murray S. Kucherawy 
wrote:

> These all work for me.  Thanks for the contributions.
>
> Scott, please work your magic with a revision so the chairs can request
> publication and we can get this on its way.
>
> -MSK
>
> On Thu, Feb 25, 2021 at 9:13 AM Dave Crocker  wrote:
>
>> On 2/25/2021 8:41 AM, Kurt Andersen (b) wrote:
>>
>> Especially in the case of the PSD policies, one should not expect that
>> the controlling organization would necessarily be "a mail-originating
>> organization". Generally the idea is to *disavow* being such :-)
>>
>> Suggested alternate text:
>>
>> Domain-based Message Authentication, Reporting, and Conformance (DMARC)
>> permits a domain-controlling
>> organization to express domain-level policies and preferences for message
>> validation, disposition, and reporting,
>> which a mail-receiving organization can use to improve mail handling.
>>
>> +1
>>
>> d/
>>
>> --
>> Dave crockerdcroc...@gmail.com
>> 408.329.0791
>>
>> Volunteer, Silicon Valley Chapter
>> American Red crossdave.crock...@redcross.org
>>
>> ___
>> 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
>
— Abstract —

OLD
   DMARC (Domain-based Message Authentication, Reporting, and
   Conformance) is a scalable mechanism by which a mail-originating
   organization can express domain-level policies and preferences for
   message validation, disposition, and reporting, that a mail-receiving
   organization can use to improve mail handling.  The design of DMARC
   presumes that domain names represent either nodes in the tree below
   which registrations occur, or nodes where registrations have
   occurred; it does not permit a domain name to have both of these
   properties simultaneously.  Since its deployment in 2015, use of
   DMARC has shown a clear need for the ability to express policy for
   these domains as well.

   Domains at which registrations can occur are referred to as Public
   Suffix Domains (PSDs).  This document describes an extension to DMARC
   to enable DMARC functionality for PSDs.

   This document also seeks to address implementations that consider a
   domain on a public Suffix list to be ineligible for DMARC
   enforcement.

NEW
   Domain-based Message Authentication, Reporting, and Conformance
   (DMARC) permits a domain-controlling organization to express
   domain-level policies and preferences for message validation,
   disposition, and reporting, which a mail-receiving organization
   can use to improve mail handling.

DMARC distinguishes the portion of a name that is a
Public Suffix Domain (PSD), below which
organizational domain names are created.  The basic DMARC
capability allows organizational domains to specify policies
that apply to their subdomains, but it does not give that
capability to PSDs. This document describes an extension to
DMARC to fully enable DMARC functionality for PSDs.

Some implementations of DMARC consider a PSD to be ineligible for
DMARC enforcement.  This specification addresses that case.


— Section 1 —

OLD
   DMARC as specified presumes that domain names present in a PSL are
   not organizational domains and thus not subject to DMARC processing;
   domains are either organizational domains, sub-domains of
   organizational domains, or listed on a PSL.  For domains listed in a
   PSL, i.e., TLDs and domains that exist between TLDs and organization
   level domains, policy can only be published for the exact domain.  No
   method is available for these domains to express policy or receive
   feedback reporting for sub-domains.  This missing method allows for
   the abuse of non-existent organizational-level domains and prevents
   identification of domain abuse in email.

NEW
  In the basic DMARC model, PSDs are not organizational domains
  and are thus not subject to DMARC processing.  In DMARC, domains
  fall into one of three categories: organizational domains,
  sub-domains of organizational domains, or PSDs.  A PSD can only
  publish DMARC policy for itself, and not for any sub-domains
  under it.  In some cases, this limitation allows for the abuse
  of non-existent organizational-level domains and hampers
  identification of domain abuse in email.

— Section 1.1 —

OLD
   As an example, imagine a country code TLD (ccTLD) which has public
   subdomains for government and commercial use (".gov.example" and
   ".com.example").  A PSL whose maintainer is aware of this country's
   domain structurewould include entries for both of these in the PSL,
   indicating that they are PSDs below which registrations can occur.
 

Re: [dmarc-ietf] Announcement - DMARC bis Design Team

[Tim Wicinski]

Thanks for sending this out Seth.   folks are free to contact the chairs
and our AD if they have questions, concerns.

tim


On Mon, Feb 22, 2021 at 12:59 PM Seth Blank  wrote:

> On 27 October 2020, in post
> https://mailarchive.ietf.org/arch/msg/dmarc/qtCDyGbeDHz96G8FaCxJvhJKrvo/
> the chairs announced a split of RFC7489 into three documents, to be scoped
> as follows:
>
>
>- The DMARC Base Spec (editors - Emil Gustafsson, Todd Herr, and John
>Levine)
>- Aggregate Reporting (editor - Alex Brotman)
>- Forensic Reporting (editors - Steve Jones and Alessandro Vesely)
>
>
> The chairs are of the opinion that discussion of topics related to the
> DMARC bis documents on the mailing list has reached a point where it would
> be unreasonable to expect any timely progress toward completion of the
> refinement of the DMARC bis at this point.
>
> Our charter (https://datatracker.ietf.org/wg/dmarc/about/) is clear on
> what this working group’s priority should be when reviewing and improving
> the DMARC specification: “Issues based on operational experience and/or
> data aggregated from multiple sources will be given priority.”
>
> We are spending too much time on items that are at best incidental to
> DMARC, and rarely are informed by operational practice or data from
> multiple sources. Efforts by the chairs to weigh in and declare discussions
> unproductive work for that particular thread, but the involved parties just
> move on to another thread, and consensus remains well over the horizon.
>
> We have therefore decided that the best approach to achieve progress for
> the DMARC bis documents is to form a design team, per RFC 2418, Section
> 6.5. The team will be composed of the editors, focused on their designated
> documents, as defined above. The team will be charged with working through
> all existing tickets and producing an updated version of each DMARC bis
> document to present to the working group, at which point discussion would
> resume on-list with respect to the updated documents.
>
> The design team will operate as follows:
>
>
>1.
>
>A moratorium is hereby imposed on creating tickets for this working
>group, effective at 5pm PT, Friday, February 26th.
>2.
>
>The design team will have until 5pm PT, Friday, April 23rd, to work
>through all applicable tickets, and come to agreement on each to either
>modify DMARC bis documents (and make such modification) or reject the
>ticket, with the reason for rejection added to the ticket's comments. No
>tickets will be closed during this process, everything will be transparent
>for working group review after the design period.
>3.
>
>Changes made to the DMARC bis documents will be tracked in the
>following manner:
>1.
>
>   By comments added to the ticket driving the change
>   2.
>
>   By comments in the markdown (.md) and/or XML version of the
>   documents
>   3.
>
>   Through an Appendix section added temporarily to the documents, so
>   that changes can be easily summarized for the next step in the process.
>   4.
>
>   All changes throughout the process will be publicly visible within
>   GitHub (https://github.com/ietf-wg-dmarc).
>   4.
>
>At the end of the time period, in roughly sixty days (or earlier if
>their work is finished before then), the design team will deliver updated
>versions of the DMARC bis documents to the working group, and the working
>group will have a chance to review that version and make
>comments/recommending edits, etc., using
>https://trac.ietf.org/trac/dmarc/report/1 to create tickets as needed.
>Initial discussion will be limited to what’s in the documents.
>5.
>
>The design team will consult with each other and the chairs during
>their work as needed.
>
>
> The chairs spent a great deal of time discussing this, and we don’t take
> this action lightly or without hesitation, but in the end we feel it’s the
> best way to not only make progress on the working group's efforts, but also
> to allow for working group participants to reset and perhaps gain a fresh
> perspective on this important work.
>
> After the updated documents have been presented to the working group, we
> will hold an interim to discuss them and hear all feedback.
>
> Seth, Tim, and Alexey, as Co-Chairs
>
> --
>
> *Seth Blank* | VP, Standards and New Technologies
> *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-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Tim Wicinski]

All

We've done a number of updates to the PSD document to reflect the GEN-ART
review,
mostly to expand on the experiments.  There has been enough changes that we
want to do a short
working group last call.

https://tools.ietf.org/html/draft-ietf-dmarc-psd-10

To look at the differences, I would suggest looking at this diff from the
-08 version and the current version:

https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08=draft-ietf-dmarc-psd-10

This starts a *one week* Working Group Last Call.  Please review the
changes and offer up comments.
Offering suggestive text would be really useful as well.

This WGLC will end 5 February 2021

tim


-- Forwarded message -
From: 
Date: Sat, Jan 23, 2021 at 6:26 PM
Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-10.txt
To: 
Cc: 



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Domain-based Message Authentication,
Reporting & Conformance WG of the IETF.

Title   : Experimental DMARC Extension For Public Suffix
Domains
Author  : Scott Kitterman
Filename: draft-ietf-dmarc-psd-10.txt
Pages   : 14
Date: 2021-01-23

Abstract:
   DMARC (Domain-based Message Authentication, Reporting, and
   Conformance) is a scalable mechanism by which a mail-originating
   organization can express domain-level policies and preferences for
   message validation, disposition, and reporting, that a mail-receiving
   organization can use to improve mail handling.  The design of DMARC
   presumes that domain names represent either nodes in the tree below
   which registrations occur, or nodes where registrations have
   occurred; it does not permit a domain name to have both of these
   properties simultaneously.  Since its deployment in 2015, use of
   DMARC has shown a clear need for the ability to express policy for
   these domains as well.

   Domains at which registrations can occur are referred to as Public
   Suffix Domains (PSDs).  This document describes an extension to DMARC
   to enable DMARC functionality for PSDs.

   This document also seeks to address implementations that consider a
   domain on a public Suffix list to be ineligible for DMARC
   enforcement.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dmarc-psd-10
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
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] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Tim Wicinski]

I suggest adding it to this paragraph:

   This document specifies experimental updates to the DMARC and PSL
   algorithm cited above, in an attempt to mitigate this abuse.



On Fri, Jan 29, 2021 at 1:44 AM Murray S. Kucherawy 
wrote:

> On Fri, Jan 22, 2021 at 5:01 PM Tim Wicinski  wrote:
>
>> Since this is an experiment, Appendix A discusses the updates that
>> happen.  we don't actually say explicitly "if the experiment is a success,
>> the following changes will be made" and perhaps I should add some wording
>> like that.
>>
>
> Something like this, perhaps?
>
> "A standards track update to [RFC7489] will take into account the results
> of this experiment."
>
> ... somewhere in Section 1.
>
> -MSK
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Tim Wicinski]

(this is really for Murray)

On Fri, Jan 22, 2021 at 6:25 PM Murray S. Kucherawy 
wrote:

>
> Looks good to me where it is.  I would add "(PSL)", introducing the
> acronym, right after its first use if we decide to leave it there.
>
> A formatting thing to take care of at some point: Anyplace you refer to
> DMARC, the protocol, just have it as "DMARC" (e.g., "not exempt from DMARC
> policy"); anyplace you refer to DMARC, the specification (e.g., "Section
> a.b.c of DMARC" or similar), it should be the  ...
>  sorta deal so that it pops out as a reference.
>
>
So the xref for RFC7489 were created of this form:

DMARC

and submitted into the submission system, the HTML document will have this look:


DMARC [RFC7489]   (Link is mapped to [RFC7489])

and the HTML is

[RFC7489]However, when I
run xml2rfc (v3.5.0) locally the


However, when I run xml2rfc (v3.5.0) locally, the HTML shows the text
"DMARC" as a link

and the HTML is

DMARC


So this makes my brain hurt. I'm going to revisit this in the morning.

tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Tim Wicinski]

Kurt

Since this is an experiment, Appendix A discusses the updates that happen.
we don't actually say explicitly "if the experiment is a success, the
following changes will be made" and perhaps I should add some wording like
that.

On Fri, Jan 22, 2021 at 7:58 PM Kurt Andersen (b)  wrote:

> On Fri, Jan 22, 2021 at 4:57 PM Murray S. Kucherawy 
> wrote:
>
>> On Fri, Jan 22, 2021 at 4:55 PM Kurt Andersen (b) 
>> wrote:
>>
>>> On Fri, Jan 22, 2021 at 3:06 PM Tim Wicinski  wrote:
>>>
>>>>
>>>> Here's the paragraph in question
>>>>
>>>>  To determine the organizational domain for a message under
>>>> evaluation,
>>>> and thus where to look for a policy statement, DMARC makes use
>>>> of a Public Suffix
>>>> List. The process for doing this can be found in Section 3.2 of
>>>> the DMARC
>>>> specification.
>>>>
>>>
>>> The concern that I have with this wording is that it is (potentially)
>>> misleading. "How" DMARC determines the org domain does not matter at all to
>>> this spec. The important point is that we go to "org-1" in the tree for
>>> this extra lookup.
>>>
>>
>> This is just establishing context for why we're doing what the rest of
>> the document says (i.e., what problem we're solving).  Leaving this out
>> seems to me to paint an incomplete picture; Section 3 basically describes a
>> delta, but a delta to what?
>>
>
> And if DMARC changes how it determines the org domain, where does that
> leave this spec?
>
> --Kurt
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Tim Wicinski]

On Fri, Jan 22, 2021 at 6:25 PM Murray S. Kucherawy 
wrote:

> On Fri, Jan 22, 2021 at 3:05 PM Tim Wicinski  wrote:
>
>>
>> Thinking twice, perhaps we don't need to introduce the PSL until Section
>>>> 3.4.
>>>> In that case, strike the last two sentences of the above paragraph.
>>>>
>>>
>>> It's not obvious to me that this is better, but sure, let's discuss it.
>>>
>>>> Here's the paragraph in question
>>
>>  To determine the organizational domain for a message under
>> evaluation,
>> and thus where to look for a policy statement, DMARC makes use of
>> a Public Suffix
>> List. The process for doing this can be found in Section 3.2 of
>> the DMARC
>> specification.
>>
>>
>>
>> The more I look at this, you need it near the top because that is where
>> the discussion
>> of the policy.  But also open to be convinced.
>>
>
> Looks good to me where it is.  I would add "(PSL)", introducing the
> acronym, right after its first use if we decide to leave it there.
>

Will do


> A formatting thing to take care of at some point: Anyplace you refer to
> DMARC, the protocol, just have it as "DMARC" (e.g., "not exempt from DMARC
> policy"); anyplace you refer to DMARC, the specification (e.g., "Section
> a.b.c of DMARC" or similar), it should be the  ...
>  sorta deal so that it pops out as a reference.
>
>
Argh yes - I was removing the RFC7489 references which had the XML  bits.
 oh let me do that fix up

tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Tim Wicinski]

On Tue, Jan 19, 2021 at 9:19 AM Murray S. Kucherawy 
wrote:

> On Tue, Jan 19, 2021 at 2:31 AM Alessandro Vesely  wrote:
>
> > To determine the organizational domain for a message under
>> evaluation,
>> > and thus where to look for a policy statement, DMARC makes use of a
>> > Public Suffix List.
>> > The process for doing this can be found in Section 3.2 of the DMARC
>> > specification.
>>
>> Couldn't we skip that kind of functional intro and say something general,
>> such
>> as anticipating Section 2.2:
>>
>>  Public Suffix Domains (PSDs) are domain names publicly accessible for
>>  domain registration.  As explained in Section 2.2, they include all
>> top
>>  level domains and some more.  The way delegations occur on the global
>>  Internet makes it difficult to establish whether a domain is a PSD.
>> A
>>  community maintained Public Suffix List (PSL) exists for that
>> purpose.
>>
>> Thinking twice, perhaps we don't need to introduce the PSL until Section
>> 3.4.
>> In that case, strike the last two sentences of the above paragraph.
>>
>
> It's not obvious to me that this is better, but sure, let's discuss it.
>
>> Here's the paragraph in question

 To determine the organizational domain for a message under
evaluation,
and thus where to look for a policy statement, DMARC makes use of a
Public Suffix
List. The process for doing this can be found in Section 3.2 of the
DMARC
specification.



The more I look at this, you need it near the top because that is where the
discussion
of the policy.  But also open to be convinced.

tim



>>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Tim Wicinski]

On Tue, Jan 19, 2021 at 5:31 AM Alessandro Vesely  wrote:

> On Tue 19/Jan/2021 07:43:01 +0100 Murray S. Kucherawy wrote:
> > [...]
>
>
> I guess "[this document]" refers to the RFC number to be.  I think it's
> useless
> and can be safely removed, all of the five occurrences of it.
>
> It is clearer and more useful to specify the referred document when it is
> /not/
> this document.  For example:
>
>  Changes in Section 6.5 of RFC 7489 "Domain Owner Actions"
>
> The above is going to be rendered with the correct anchor in the htmlized
> version of the document.  It can be expressed in xml as:
>
>  
>
> so as to generate correct links whenever possible.
>

two things:  1) to be accurate I would want to target the section anchor.
But actually the real answer is 2) the RFC editor owns the final XML and I
believe
they perform a bunch of this work during the AUTH48 process.

Now saying that, someone will politely explain how wrong I am.

In fact, those are the two terms appearing in the title.  BTW, I'd change
> the
> title to:
>
>  Domain-based Message Authentication, Reporting, and Conformance
> (DMARC)
>  Extension For Public Suffix Domains (PSDs)
>

I went with the Murray;s "Experimental DMARC Extension For Public Suffix
Domains"

And Murray restructured the Intro and it feels much cleaner.

tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Tim Wicinski]

On Tue, Jan 19, 2021 at 1:43 AM Murray S. Kucherawy 
wrote:

> In the interests of getting this document on its way, I'd like to suggest
> the following edits in response to Dale's most recent message.  If the
> working group concurs, we can finally get this out to Last Call.
>
> My goal as an AD here is just to get the GenART feedback addressed, but
> the text is being submitted as a WG contribution for discussion and
> consensus consideration, not as a demand.   Please process accordingly; I
> believe the agreement is to do another WGLC on the document before it goes
> on its way, so the sooner consensus is reached on all of this, the sooner
> it goes.
>
> First, a suggestion of my own that I think I saw elsewhere, but it's not
> in Dale's reply: In several places there's a reference to "DMARC
> [RFC7489]".  That's appropriate the first time the reference is made, but I
> think after that you can just say "DMARC" when referring to the protocol
> generally, or to "RFC 7489" when you need to make a specific section or
> text reference.  They don't need to appear together everywhere.
>
> I think Dave's original feedback has been addressed -- good stuff -- so
> here are my suggestions around what's left:
>
> On Mon, Nov 16, 2020 at 7:16 PM Dale R. Worley  wrote:
>
>> My apologies for not tending to this promptly.
>>
>> In regard to the description of the experiments, the result criteria are
>> rather subjective, but I don't see that as a problem.  It does seem to
>> me that the title "PSD DMARC Privacy Concern Mitigation Experiment" is
>> too narrow, as only the 3rd experiment seems to be about privacy
>> issues.  A title as generic as "PSD DMARC Experiments" would be fine.
>>
>
> That's OK with me, or "DMARC PSD Experiments" or "DMARC PSD Experiment" if
> we want to treat it all as one common thing.
>
>
>> Although I note that even the -09 does not define "PSD", only "longest
>> PSD", even though "PSD" is used in section 2.5.  I suspect that PSD is
>> equal to "PSO Controlled Domain Name", though, or rather to some related
>> set of them.  That needs to be cleaned up in some way.
>>
>
> PSD appears to be well defined in Section 2.2.
>
> In section 3.5 and later there is the phrase "[this document] longest
>> PSD".  I'm not sure, but I think this is supposed to be "longest PSD
>> ([this document] section NN.NN)".
>>
>
> Agreed.
>
> I believe that my strongest critique was that section 1 is difficult to
>> understand if one does not already understand DMARC, and it does not
>> seem that the section has been revised.  Re-reading it, I notice that it
>> says "DMARC leverages public suffix lists to determine which domains are
>> organizational domains."  Ignoring that I dislike this use of
>> "leverage", a critical point is that it takes the existence of public
>> suffix lists a priori -- indeed, this use of "leverage" generally means
>> that the leveraged thing already exists and one is now extracting
>> additional benefit from that.  Whereas I've never heard of public suffix
>> lists and would naively expect that they are difficult to create and
>> maintain.  It might be better to say "DMARC uses public suffix lists to
>> determine which domains are organizational domains.  Public suffix lists
>> are obtained/maintained/distributed by ..."
>>
>
> Replace all of Section 1 with this (ignore funny line wrapping):
>
>DMARC [RFC7489 ] provides a mechanism 
> for publishing organizational
>policy information to email receivers.  DMARC allows policy to be
>specified for both individual domains and for organizational domains
>and their sub-domains within a single organization.
>
>To determine the organizational domain for a message under evaluation,
>and thus where to look for a policy statement, DMARC makes use of a Public 
> Suffix List.
>The process for doing this can be found in Section 3.2 of the DMARC 
> specification.
>
>DMARC as specified presumes that domain names present in a PSL are not
>organizational domains and thus not subject to DMARC processing; domains
>are either organizational domains, sub-domains of organizational
>domains, or listed on a PSL.  For domains listed in a
>PSL, i.e., TLDs and domains that exist between TLDs and
>organization level domains, policy can only be published for the
>exact domain.  No method is available for these domains to express
>policy or receive feedback reporting for sub-domains.  This missing
>method allows for the abuse of non-existent organizational-level
>domains and prevents identification of domain abuse in email.
>
>This document specifies experimental updates to the DMARC and PSL 
> algorithm cited
>above, in an attempt to mitigate this abuse.
>
>
Done

>
> Looking at the second paragraph of section 1, I notice that despite all
>> the special terms for classifying domain names in section 2, the example
>> in this section does not describe which of 

Re: [dmarc-ietf] Decorum on the DMARC WG list and BCP 94

[Tim Wicinski]

Dave

I agree.  But it seems one person's civil discourse is another person's
abuse.

Perhaps we can start from the position that nobody is attempting to insult
or abuse one another.
I don't believe anyone here consciously wants to be abusive to anyone else.
I have been accused of being an optimist.

tim


On Wed, Jan 6, 2021 at 11:52 PM Dave Crocker  wrote:

> On 1/6/2021 8:47 PM, Tim Wicinski wrote:
>
> You should have a pretty good idea based on these arguments over the past
> few months to have a sense of how responses will be received. Take a step
> back and take a second read.
>
> This goes for all. Folks have very specific views of how they think mail
> should work
>
>
> Tim,
>
> This has nothing to do with differences in opinion.  It has to do with his
> persistent inability to conduct civil discourse in the face of disagreement.
>
> Disagreement is fine.  Abuse is not.
>
> d/
>
> --
> Dave crockerdcroc...@gmail.com
> 408.329.0791
>
> Volunteer, Silicon Valley Chapter
> American Red crossdave.crock...@redcross.org
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Decorum on the DMARC WG list and BCP 94

[Tim Wicinski]

Dave

You should have a pretty good idea based on these arguments over the past
few months to have a sense of how responses will be received. Take a step
back and take a second read.

This goes for all. Folks have very specific views of how they think mail
should work in regards to DMARC/DKIM/SPF/ARC/etc and instead of discounting
the discussion because the two views aren't identical, try to be a bit
open minded.

Tim



On Wed, Jan 6, 2021 at 9:14 PM Dave Crocker  wrote:

> On 1/6/2021 4:21 PM, Seth Blank wrote:
> > and is not likely to escalate tensions.
>
>
> Seth,
>
> Sorry, but please provide guidelines for how anyone is supposed to
> evaluate their draft posting, in that regard?
>
> And please do it with respect to the current list rather than in
> abstract and generic terms.
>
>
> d/
>
> --
> Dave Crocker
> dcroc...@gmail.com
> 408.329.0791
>
> Volunteer, Silicon Valley Chapter
> American Red Cross
> dave.crock...@redcross.org
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Decorum on the DMARC WG list and BCP 94

[Tim Wicinski]

All

If you feel a need to be heard, that is also what the chairs are here for.

thanks
tim


On Wed, Jan 6, 2021 at 7:21 PM Seth Blank  wrote:

> Working Group colleagues,
>
> Discussion on this list is increasingly out of scope and process,
> unproductive, and antagonistic. This behavior undermines the chartered work
> of this group and will not be tolerated. We expect and require more civil
> discourse from our participants, and remind everyone that disciplining
> others is the purview of the chairs.
>
> The current phase of work of our charter (
> https://datatracker.ietf.org/doc/charter-ietf-dmarc/) is to deliver a
> standards track DMARC document based upon operational feedback. We are not
> relitigating SPF, DKIM, DMARC, or ARC, adding new functionality, or
> rehashing other IETF documents or processes.
>
> When we kicked off DMARC bis, Alexey outlined a clear process:
> https://mailarchive.ietf.org/arch/msg/dmarc/rBWzfzDa_tOhaVdxFzUBYVi46QI/
>
> Only tickets opened by the Chairs or a document editor to the list are in
> scope for working group discussion. Everything else should result in the
> creation of a ticket to be discussed later, or off-list discussion. The
> Chairs re-affirm that all tickets will be brought to the list.
>
> To be clear: Before you hit “send” on an email to this list, make sure it
> is on topic for an open ticket and is not likely to escalate tensions.
> Otherwise, delete the message or start a private conversation that is not
> on the list.
>
> From here on out, due to the counter-productive nature of current list
> discourse, off topic or antagonistic discussions will be given a single
> public warning, per BCP 94 (https://tools.ietf.org/html/bcp94), which
> implies that further violations will result in a 30 day suspension for the
> participant. The ADs have been consulted, and everyone should consider
> themselves warned.
>
> Finally, several members of this working group seem to be very effective
> at antagonizing each other. If a thread is spiralling, and a BCP 94 warning
> is given and not heeded, all active participants in the thread after the
> warning has been issued will be suspended, even if it’s to tell others to
> respect the warning.
>
> Now, let’s get back to our chartered work at hand and open tickets.
>
> Seth, Tim, and Alexey, as Chairs
>
> --
>
> *Seth Blank* | VP, Standards and New Technologies
> *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] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports

[Tim Wicinski]

I will admit my memory can get pretty hazy, but I agree with Mr Levine - I
remember splitting out reporting,
but only as one document.

The Working Group can always make a compelling case to change this

tim


On Mon, Dec 28, 2020 at 12:06 PM John R Levine  wrote:

> On Mon, 28 Dec 2020, Ned Freed wrote:
> > I'm not ethusiastic about the split, but if that's what people want then
> so be
> > it. I will say that my experience has been that doing so is usually more
> work
> > and provides less benefit than you'd expect.
>
> I recall agreeing to split out all of the reporting into a separate draft,
> which makes some sense so the two parts can proceed separately, but not
> further splitting aggregate and failure reports.
>
> 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Tim Wicinski]

I would drop that whole third sentence, and mention sending such reports
may contain PII.
The document can refer the reader to non-IETF documents for information,
but in general
we do technical standards, and stay away from policy decisions in standards
track documents.


tim


On Mon, Dec 28, 2020 at 10:57 AM Michael Thomas  wrote:

>
> On 12/28/20 7:48 AM, Todd Herr wrote:
>
>  not a lawyer, but providing A with some information about a message that
> A sent to X seems different, from a privacy perspective, than providing A
> with some information about a message impersonating A that B sent to X, and
> I thought perhaps the generic warning might mention this distinction, if
> possible. Something like:
>
> Security considerations
>
> Failure reports provide detailed information about the failure of a
> single message or a group of similar messages failing for the same
> reason. They are meant to aid domain owners to detect why failures
> reported in aggregate form occured. It is important to note these
> reports can contain either the header or the entire content of a
> failed message, AND THAT THE DOMAIN OWNER RECEIVING THE
> REPORTS MAY NOT BE THE ORIGINATING PARTY FOR THE MESSAGE(S)
> REFERENCED IN THE FAILURE REPORTS. IN ANY CASE, THEY may contain
> personally identifiable information, which should be considered when
> deciding
> whether to generate such reports.
>
>
>
> This is a tempest in a tea pot. This is an issue with the originating
> domain and nobody else. They can send it to a third party even if the url
> lists them to receive the report first.  The receiving domain can't know
> what they will do with the report, and the originating domain has already
> seen the mail in clear text before it was sent. IETF should stay out of the
> business of being nannies that it has no way to enforce.
>
> Mike
> ___
> 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] Ticket #55 - Clarify legal and privacy implications of failure reports

[Tim Wicinski]

I Believe I agree with the current version, but can someone post what we
think is the final text?

tim


On Wed, Dec 23, 2020 at 9:12 PM John R Levine  wrote:

> On Wed, 23 Dec 2020, Dotzero wrote:
> > Based on my experience, I disagree that failure reports are marginal and
> > seldom used. It's kind of like an iceberg, mostly below the surface. ...
>
> Seems to me that if we splice in Ned's tweaked privacy language, we're
> done.  I don't see any reason to change the technical spec.  People will
> send what they send, and it's become clear that we have nothing useful to
> say about what one might redact.
>
> 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] p=quarantine

[Tim Wicinski]

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 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, thinking it
> > means that message authorship is validated.
> >
>
> I'll ignore the whataboutism, but point out that you have never produced
> one piece of evidence where the language of p=reject or any of the other
> previous labels has caused software design decisions to change for the
> worst. I don't even know what would qualify as a mistake. So yes, I'll
> take my direct experience of writing code over your indirect innuendo
> any day.
>
> Mike
>
> ___
> 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] not ADSP, was is DMARC informational?

[Tim Wicinski]

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 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 I completely recognized ADSP/SSP with the addition of SPF policy and
> reporting. I wouldn't expect a whole lot of changes beyond wordsmithing and
> some nits around the edges. If this is really because large mail providers
> have started using p=reject, that seems to be pushing off the actual
> payload way down the line. Standards track is not going to change this
> much, IMO.
>
> Mike
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Tim Wicinski]

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, 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 wanted by the recipient but that
> fails SPF without forwarding (with a -all) or hits a dmarc=reject. I
> quarantine such for review and release to users as needed.
> >
> > Obviously lots is spam, or forwarding that broke SPF or whatever, but
> just as often it is a small piece of a big company doing something without
> fully understanding how modern email works. Oddly it is often security
> sensitive stuff, not crazy long ago it was Facebook password resets, often
> it is 2FA codes (which are probably going through a separate channel to get
> immediate delivery without risking backlog?), and other reasonably
> important things from parts of the company that I would expect to be at
> least moderately aware of the email security world.
> >
> > I agree that ADSP was theoretically fine for this type of use, but in
> practice, DMARC's feedback simplifies things a lot when a client complains
> their outbound mail isn't making it and we can quickly see what is being
> rejected.
> >
> > it is an imperfect world.
>
> I fear that DMARC's reporting only confirmed the obvious: this is hard.
> It gave numbers to anecdotes. That's really useful, don't get me wrong.
> Hopefully it can be used to suss out how to demarcate the long tail of
> don't care use cases.
>
> Mike
>
> ___
> 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] ARC vs reject

[Tim Wicinski]

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 as MIME parts.
> >
> > We really need to keep in mind that there is a lot of list management
> > software with a vast array of configuration options.
>
> 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 that causes their traffic to not get delivered can
> be configured in a way that will. It's not our problem.
>
>
Are you talking about integrating ARC?  Then you are correct, operational
data.  This is why until that happens, we're not talking about adding ARC
into
the DMARC flow, and it's why the ARC work is Out Of Scope in this WG.

tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[Tim Wicinski]

Michael

I don't see john's comments as ad hominem.  He's describing how his mail
system interprets mail flow.

But I do think a lot of this discussion is getting into very
esoteric cases.
I'd suggest trying to put your thoughts into a draft we can sit and chew on.

Tim


On Sat, Dec 5, 2020 at 6:16 PM Michael Thomas  wrote:

>
> On 12/5/20 3:10 PM, John Levine wrote:
> > In article  you write:
> >> If ARC is advocating for a bypass of p=reject that introduces a new
> >> state. If my policy is reject, I want you to reject the mail. If I want
> >> you to reject the mail unless you think it has come from an acceptable
> >> place with receipts, then you need a new policy tag like
> >> reject-except-valid-arc.
> > Other people will have to speak for themselves but on my system
> >
> > a) I don't believe you.
> >
> > 2) I don't care.
> >
> > I think you will find this reaction pretty common.
> >
> > I see lots of mail going through my system like the stuff I described
> > for the town clerk. It is obvious who it is intended for, the only way
> > to deliver it to that recipient is to forward it, and if the DMARC
> > policy says not to do that, the policy is wrong. I don't even need ARC
> > for that, although ARC can be useful for mail that takes indirect
> > routes for the mailing lists they subscribe to.
> >
> > You can say, no I am smarter than those guys and I REALLY REALLY mean
> > it, but see 2) above.
> >
>
> Can you keep your contempt for me off this list? This is not even
> responsive to what I wrote, and is nothing more than an ad hominem.
>
> And  your anecdotal evidence drawn from a tiny system is very suspect.
>
> Mike
>
> ___
> 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] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

[Tim Wicinski]

icts strongly with this.  In section
> A.4, it suggest several ways to do a test of this type, then repudiates all
> of them.  NS lookup is not one of the mentioned options.
>
> There is a possible second-level policy test for a "mail-enabled domain".
> I would define that test as "MX record exists or SPF policy exists".
>  That could be an additional option to NP, but should not be a replacement
> for it.
>
> PSD for DMARC clearly intends for the NP policy to be a general solution
> to a general problem.If there are still objections to it becoming a
> general solution, this should be addressed soon.
>
> Doug Foster
>
>
> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Tim Wicinski
> Sent: Friday, November 13, 2020 1:42 PM
> To: IETF DMARC WG
> Cc: dmarc-cha...@ietf.org
> Subject: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd
>
>
> All
>
> During the IESG reviews of draft-ietf-dmarc-psd, there were several issues
> raised with some of the document.   Most of them are editorial but the one
> big item was the description of the Experiment.   The chairs sat down and
> broke out the experiment section into three separate experiments, and
> included language on how to capture the data to confirm how the experiment
> worked.
>
> It's enough of a change that we wanted to do a second working group last
> call to make sure the working group agrees with our changes. The diff of
> the current version with the previous version is here:
>
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08=draft-ietf-dmarc-psd-09
>
> This starts a *one* week second working group last call for
>  draft-ietf-dmarc-psd
> Please review the changes and offer up comments to the working group.
>
> This working group last call 20 November 2020
>
> Thanks,
>
> ___
> 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

[dmarc-ietf] Minutes for DMARC meeting

[Tim Wicinski]

All

I've uploaded the minutes into the datatracker.  Please take a look to make
sure I captured everyone's comments correctly, and let us know updates.

https://datatracker.ietf.org/meeting/109/materials/minutes-109-dmarc-00

thanks

tim
(for Alexey/Seth)
# DMARC (Domain-based Message Authentication, Reporting, and Conformance) WG

* Date: Wednesday, November 18, 2020
* Time: 05:00-07:00 UTC (or 12:00-14:00 UTC+7)
* Meetecho: https://meetings.conf.meetecho.com/ietf109/?group=dmarc==1


###
* Jabber: dm...@jabber.ietf.org
* Notes: https://codimd.ietf.org/notes-ietf-109-dmarc


### Chairs
* Seth Blank s...@valimail.com
* Alexey Melnikov alexey.melni...@isode.com
* Tim Wicinski tjw.i...@gmail.com

### Documents:
 https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/?include_text=1
 https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/?include_text=1
 https://datatracker.ietf.org/doc/draft-ietf-dmarc-failure-reporting/?include_text=1
 
## MINUTES

* Should we deprecate “pct” tag?



Todd Herr: google groups required p=quarantine;pct=0 to get reports in the past. 

Autumn Tyr-Salvia: p=quarantine mailing list munging happens but not p=none. Large customers very risk averse without pct=0.

Alexey: Could be addressed with more text?

Autumn: Yes. 

Alwin de Bruin: Practical cases moving from quarantine to reject

Jim Fenton: deprecate may not be the right term here.  Could just leave out.

Alexey: Will still explain reasoning. 

Jim:  Autumn in the chat p=none reports w/out header munging. 


* Aggregate reporting


* Extensible reporting

What kind of extensions should be allowed?
What’s needed for future authentication mechanisms to be folded into DMARC?
	Extending reports for arbitrary authentication mechanisms to be reported makes it easy to collect data and run experiments without modifying the spec

Autumn: gmail including dkim selecters in aggregate reports, but not common. Would love to see more. 
Very useful for tracking down usage in large orgs. 

Murray Kucherawy: 8601 add header s most common use case.

Todd: Ticket 57 on making dkim selectors required. 

John Levine: add them into the reporting XML, advice on ignoring during parsing. 


* ARC Reporting


* NXDOMAIN reporting

John: Both seem reasonable, suggest folks send suggested XML 


* Failure reporting

Murray: Is question what must be included or might be included or some mix?

Alexey: Both - reasons to include or not include more, and privacy considerations. 

Todd: Jesse @ Wisconsin strawman failure reporting to find problems. 

Autumn: Some pieces we are less in need of. don't need full dkim header; don't need full date/time stamp;
do use From addresses. Message-Id helpful at times. what specific fields people objecting to? 


Michael Hammer: failure reports useful in getting rid of the baddness, not just arbitrary failures.

John: Not sure of problem solving itself. Most won't send failure reports, others will redact for legal reasons.

Alexey: Should have text on what should be included for useful failure report.

John: Talking to lawyers here about failure reports. People will report what they report. 


* Break out definition of org domain to a different document?

Dave Crocker: Messy, unpleasant topic making do with solution.  Different solutions, one may work. 
Having the spec state what it wants as a result does make sense. How it gets the info is a problem. 
Suggested text was clean and simple by whom?  (Murray https://mailarchive.ietf.org/arch/msg/dmarc/Zw0KjyrNfHMQ5S8TpoBRNvnfVRc/)

John: Almost agree with Dave! when we split out into another document, different result. 

Murray:  Produce an org domain document from 7489 into new document. Can also add tree walk into same
document or a new document. 

Kurt Andersen: talk policy discovery first, before org domain is needed.  On the fence on a separate document.

* Policy Discover - Tree Walk!

Autumn: Seen in higher ed.  example of grad.univ.edu and multiple sub domains. univ.edu was not interested in doing dmarc.
also seen in governments.  one or two levels would be useful. 

John: Asked DNSOP, wasn't concerned.  CAA specifies a tree walk, and CAs do this. 5 levels, use the resolver cache to catch NXDOMAINs. 

Jim: Discussed tree walk with ADSP, was very toxic at the time. 

Wes Hardaker: CAA was used as an example but CAA queries much different than mail server.  
The latter can produce more traffic. Provide guidance some reference to another dmarc record. 

Alexey:  Will take discussions to mailing list. 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] IETF 109 possible agenda/session discussion

[Tim Wicinski]

Dave

It's the latter.   Alexey and I are quite fine with running the meeting,
that was part of our conversation.

tim


On Fri, Nov 13, 2020 at 3:23 PM Dave Crocker  wrote:

> On 11/13/2020 10:40 AM, Tim Wicinski wrote:
> > During the chairs call this morning we were discussing the upcoming
> > meeting.  Now Seth has a conflict with the meeting time that can't be
> > altered.   Since work items have been progressing rather well recently,
> > and the editors are in positing, we discussed canceling the meeting.  We
> > wanted to get some feedback from the working group.
> >
> > Here is a lightweight agenda Seth put together.  Should we 1) have a
> > meeting around these topics;  2) discuss other topics or 3) cancel the
> > meeting and keep moving along.
>
>
> Four days before a scheduled, rare meeting, it's being canceled because
> one of its 3 chairs can't attend?
>
> Or because it has suddenly been realized that the meeting won't be useful?
>
> Really?
>
> d/
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd

[Tim Wicinski]

All

During the IESG reviews of draft-ietf-dmarc-psd, there were several issues
raised with some of the document.   Most of them are editorial but the one
big item was the description of the Experiment.   The chairs sat down and
broke out the experiment section into three separate experiments, and
included language on how to capture the data to confirm how the experiment
worked.

It's enough of a change that we wanted to do a second working group last
call to make sure the working group agrees with our changes. The diff of
the current version with the previous version is here:

https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08=draft-ietf-dmarc-psd-09

This starts a *one* week second working group last call for
draft-ietf-dmarc-psd

Please review the changes and offer up comments to the working group.


This working group last call 20 November 2020

Thanks,
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Subject: Call for Adoption: DMARC-bis

[Tim Wicinski]

All

The call for adoption ended earlier in the week, with the document being
adopted, and split.   Since the existing document was going to be split, we
will wait until the editors produce  their documents and those will be
adopted.

Thanks
tim


On Mon, Oct 26, 2020 at 5:58 PM Tim Wicinski  wrote:

>
> All
>
> While the chairs are aware that working on DMARC-bis is the charter of the
> working group, we want to ensure the process is followed.
>
> This starts a Call for Adoption for: DMARC-bis
>
> We'll be starting with the text from the RFC 7489.
> This is available here:
> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-dmarcbis/
>
> Changes made so far have been to include the current Errata.
>
> Please review this draft, and we are looking for *objections to adoption*,
> and send comments to the list stating your objections.  The working group
> can pick over the document after adoption.
>
> Also, the Chairs have announced that the document will be split into
> multiple pieces. The details around this split will be sent out shortly in
> a separate email.
>
> Since this bis project is the group’s currently chartered phase of work,
> the chairs believe one week is sufficient time for objections. This call
> for adoption ends: November 2nd, 2020, at 5pm PST.
>
> Thanks,
>
> tim
> (for Alexey/Seth)
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Subject: Call for Adoption: DMARC-bis

[Tim Wicinski]

All

While the chairs are aware that working on DMARC-bis is the charter of the
working group, we want to ensure the process is followed.

This starts a Call for Adoption for: DMARC-bis

We'll be starting with the text from the RFC 7489.
This is available here:
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-dmarcbis/

Changes made so far have been to include the current Errata.

Please review this draft, and we are looking for *objections to adoption*,
and send comments to the list stating your objections.  The working group
can pick over the document after adoption.

Also, the Chairs have announced that the document will be split into
multiple pieces. The details around this split will be sent out shortly in
a separate email.

Since this bis project is the group’s currently chartered phase of work,
the chairs believe one week is sufficient time for objections. This call
for adoption ends: November 2nd, 2020, at 5pm PST.

Thanks,

tim
(for Alexey/Seth)
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Tim Wicinski]

Dale

Apologies for the delay on the PSD updates.  I sat down with Scott and went
through your review and made lots of edits
related to your comments.  I actually attached the reply to your email as
it's been sitting in my editor buffer for a few months too long.

One normative change that I want your assistance on is the descriptions of
the Experiments.  I updated them and pulled them apart, to make them more
understandable to folks looking at this for the first time.  I'm not still
100% on them.

I want to go back through your opening Nits/editorial comments to make sure
I'm not missing anything.

Here's the link to the diff.

https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08=draft-ietf-dmarc-psd-09

thanks
tim


On Tue, Apr 21, 2020 at 9:22 PM Dale R. Worley  wrote:

> Scott Kitterman  writes:
> > [important discussion clipped for brevity]
> > If you want to add it and are confident we aren't diving into a deep,
> > deep hole, I don't strongly object.  Just let me know what to add.
>
> Well, my review amounted to about 5 pages of ordinary text, and my
> follow-up e-mail about a page and a half.  If I was unclear regarding
> what I thought should be done to make the document clearer to the
> unsophisticated reader, please get back to me so that I can improve my
> review style.
>
> Dale
>
> * Summary:
> 
>This draft is on the right track but has open issues, described
>in the review.
> 
> * Major issues:
> 
> The privacy concerns described in section 4 are written as if there is
> no certainty that the mechanisms described in the document properly
> mitigate them.  So the document appears to be incomplete.  OTOH, since
> this is an Experimental RFC, such mitigation isn't necessary if there
> is commitment to do so later.  In that case, the section should
> explicitly state that these are open issues and that there is an
> intention of revising the document to mitigate them.
> 
> The text suggests that a mail receiver(?) that does DMARC processing
> has knowledge of all PSDs.  This seems a priori unlikely and even
> impossible to implement.  So this ought to be either explained at the
> appropriate place or resolved technically.
> 
> * Minor issues:
> 
> The document has the (common) editorial problem that it is written by
> people who are deeply familiar with the subject, and it's difficult to
> read if one doesn't share that familiarity.  This is particularly
> significant because DMARC is an e-mail facility that (ideally) will
> affect all e-mail that is sent, so the target audience really should
> be anyone who has a basic understanding of e-mail.  Three particular
> elements of this are:
> 
> - It would be very helpful if the Introduction could state, in a few
>   sentences, the purpose and operation of DMARC, thus informing the
>   reader of the framework whose deficiencies this document attempts to
>   address.  In particular, one shouldn't have to read the DMARC RFCs
>   to be able to read this document and understand its general import.
> 
> - The "experiment" appendixes are unclear about what the experiments
>   actually are:  what questions they are to answer, what actions will
>   be taken, how the results will be evaluated.  Starting each appendix
>   with an overview paragraph would be helpful.
> 
> - Forward references should be minimized so that a reader can
>   understand the document in one pass.
> 
> As a derivative of the first of these elements, the terminology used
> for the properties of domain names is not clearly defined.  In
> particular, where does a registration "occur"?  The only term for
> which I think the general audience possesses an unambiguous definition
> is "the registered domain name", e.g. ietf.org.  Now I *think* its PSD
> is ".org", but it might be "ietf.org", and I don't know whether the
> registration of ietf.org "occurs" at ietf.org or .org.  Further points
> I didn't understand are pointed out in the review of the
> Abstract and Introduction.
> 
> * Nits/editorial comments: 
> 
> Abstract
> 
> I'm having quite a bit of difficulty figuring out exactly what the
> Abstract means.  I'm sure that the working group clearly understands
> what is meant, but the writing is just loose enough that I can't fix
> the meaning.  To raise the immediate questions:
> 
>DMARC (Domain-based Message Authentication, Reporting, and
>Conformance) is a scalable mechanism by which a mail-originating
>organization can express domain-level policies and preferences for
>message validation, disposition, and reporting, that a mail-receiving
>organization can use to improve mail handling.
> 
> This sentence is quite good, as it introduces what DMARC is all about.
> 
>The design of DMARC
>presumes that domain names represent either nodes in the tree below
>which registrations occur, or nodes where registrations have
>occurred; it does not permit a domain name to have both of these
>properties simultaneously.
> 
> You want to make 

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Tim Wicinski]

And here we were getting along so well!

Mr Foster, it's perfectly fine to disagree with Mr Crocker technical
points, and you are
welcome to have your own opinion on whether he chooses to hear or not.  But
those opinions should
be kept to yourself.

I see a lot of these heated discussions as a sign that people really care
about this issue. That's
a good thing.

For the record, I'm a DNS person.  I see most problems as being solved with
more DNS, or less DNS.
I will say that I have had "passionate discussions" with Mr Crocker on
several issues and I found that
it was not that he did not listen, but figuring out how to better explain
my point of view.
Surprisingly to many, he does listen.

Whether this work is in scope for DMARC or not, I would plead guilty for
not considering this carefully.
In the DNSOP working group I co-chair, *everything* DNS is in scope, until
it is not in scope.
These types of discussions I was leaning on Seth, Alexey and of course
Murray the AD.

thanks for listening.
tim


On Sat, Sep 26, 2020 at 8:55 AM Douglas E. Foster  wrote:

> The problems with your proposal have been well documented, but you
> apparently choose not to hear.   The single paragraph that Scott quoted has
> multiple problems within it.
>
> The group has considered other and better technical proposals (conditional
> signatures, ATSP, RHSWL), but they have all been dropped because the group
> did not believe that Domain Owners would have any desire to implement them,
> and because Mailing List Operators would have no way of knowing which
> mailing lists had implemented the new feature.
>
> If you have solutions to these problems, please put them forward.
> Otherwise, why are we dragging this back up?
>
> --
> *From*: Dave Crocker 
> *Sent*: 9/25/20 11:04 PM
> *To*: Scott Kitterman 
> *Cc*: IETF DMARC WG 
> *Subject*: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the
> RFC5322.Sender Header Field
>
> On 9/25/2020 4:21 PM, Scott Kitterman wrote:
>
> On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote:
>
> I think the obligation to justify is on the advocate for change.
>
> That means you are demanding I prove  negative.  Which, of course, is an
> impossible assignment.
>
> Rather, the obligation is on the person claiming the affirmative, which in
> this case means the claim that this proposal somehow 'breaks' or otherwise
> hurts DMARC.
>
>
> Because the current email protection behavior involves the
>RFC5322.From field, and pertain to the human author, it is common to
>think that the issue, in protecting the field's content, is behavior
>of the human recipient.  However there is no indication that the
>enforced values in the RFC5322.From field alter end-user behavior.
>In fact there is a long train of indication that it does not.
>   Rather, the meaningful protections actually operate at the level of
>the receiving system's mail filtering engine, which decides on the
>dispostion of received mail.
>
> Please provide references for your long train of indications, speaking of
> making overly broad assumptions.  If that's accurate, I'd like to understand
> the data that tells us that.
>
> I'm not going to do that, because there's a long history of that work
> being ignored, in spite of it being reviewed repeatedly in thse and related
> fora over the years.  It's gotten tiresome to have people claiming an
> effect that they lacks evidence for, and the data to the contrary that they
> are somehow unaware of.
>
> Again, the real requirement is focus on the affirmative.
>
> In this case, an affirmative claim that end-users are relevant to the
> efficacy of DMARC.  I don't recall seeing any research results validating
> such a view, but perhaps I missed it.
>
> Well, ok, here's one that shows lack of efficacy, and it's a big one:
> EV-certs
>
> *Google to bury indicator for Extended Validation certs in Chrome because
> users barely took notice*
>
>
> https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/
>
> "The reason is simple. "Through our own research as well as a survey of
> prior academic work, the Chrome Security UX team has determined that the EV
> UI does not protect users as intended... users do not appear to make secure
> choice..."
>
>
> If this is just an input into an algorithm, then your assertion that you are
> only providing another input is supportable, but that's contrary to the DMARC
> design.
>
> Perhaps you have not noticed but the demonstrated field use of DMARC, to
> date, tends to be contrary to the design, to the extent anyone thinks that
> the design carries a mandate that receivers follow the directives of the
> domain owners.
>
> So the text in the draft merely reflects real-world operational style.
>
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorkingbbiw.net
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> 

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Tim Wicinski]

Dave Crocker reminded me that we were going to adopt this document as
Experimental. I was remiss in not mentioning that.

Even though the WG adopted this document, it was said during the call that
the WG may not be able to come to a consensus to move the document
forward.   Adoption does not mean published (see: ARC Usage).

tim


On Fri, Sep 25, 2020 at 10:01 AM Tim Wicinski  wrote:

> All
>
> This call for adoption ended a few weeks ago, I have been recalcitrant in
> following up.   The chairs feel
> there is enough consensus to adopt this work in DMARC.   While there were
> issues raised, the chairs feel
> they can be addressed through the document process.
>
> thanks
> tim
>
>
> On Mon, Aug 24, 2020 at 2:00 AM Hector Santos  40isdg@dmarc.ietf.org> wrote:
>
>> On 8/21/2020 3:09 PM, Jim Fenton wrote:
>>
>> > On 8/15/20 3:53 PM, John Levine wrote:
>> >> Assurances that are provided by ADSP are generally obtained out of
>> band in the
>> >> real Internet, and not through ADSP.  Current deployment of ADSP is not
>> >> recommended.
>>
>> > Is that not exactly the same situation with DMARC, except that the
>> > policy in question now is "reject" rather than "discardable"? Yes,
>> > it's just a keyword, but it reflects the semantics of the expected
>> > action as well.
>> >
>> > -Jim
>>
>> No one was expected to follow a reject, so it was said, until it did
>> happen.  SPF pushed
>>
>> --
>> Hector Santos,
>> https://secure.santronics.com
>> https://twitter.com/hectorsantos
>>
>>
>> ___
>> 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