[dmarc-ietf] General Purpose Domain

[Neil Anuskiewicz]

Unless I’m misunderstanding, a General Purpose Domain is a separate domain or 
at least subdomain:

*   You’d use a General Purpose Domain (GPD) exclusively for Mailing Lists
*  You would designate either a subdomain or a less critical org domain as your 
GPD. 
* The GPD MUST NOT have an enforcing policy of reject. That is, the policy of a 
GPD must remain p=none.

The heading is Interoperability considerations which is a section mostly 
talking about indirect mail flows. The explanation’s cursory for such a common 
and challenging problem. 

I’d say start with defining the problem and solution in more depth, giving 
Mailing Lists its own heading under Indirect mail flows with a clearly 
delineated problem and solution even at the risk of some redundancy.

Otherwise, I think there will be a lot of busy people who will miss the 
indirect mail bit entirely and many who do read it won’t grok what exactly 
they’re supposed to do and why.

 Neil


 




___
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

[Scott Kitterman]

On Wednesday, February 28, 2024 7:37:30 PM EDT Barry Leiba wrote:
> The editors and chairs think version -30 resolves the open issues and is
> ready for a final look, so this message starts a working group last call
> for the DMARCbis spec.  Because of the upcoming IETF 119 meeting, we’ll let
> this go until the end of March, so there’s lots of time to review.
> 
> Please post to the DMARC mailing list by 31 March, giving your last call
> comments (which should include “I read it and I think it’s ready” as
> well).  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.

I've reviewed the document and the issues previously raised.  Modulo 
resolution of the open issues (which seems on track), including the new one I 
just sent, I think it's ready.

Scott K


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

[dmarc-ietf] DMARCbis WGLC Issue - Section 11.5

[Scott Kitterman]

Not sure if this is "significant" or not.

I don't particularly like the title, but that's been that way for quite some 
time, so for WGLC, meh.

The particular concern I have is with the text that was added right before 
WGLC about multi-valued RFC5322.From fields.  It includes the statement:

> Such an approach might prove useful for a small number of Author
> Domains, but it is likely that applying such logic to messages with a larger
>  number of domains (as defined by each Mail Receiver) will expose the
> Mail Receiver to a form of denial of service attack, and so applying a
> negative disposition decision to the message may be the best course of
> action.

In particular, the word "likely" seems a bit much.  Additionally, I think 
beyond the Domain Owner DMARC policy published in a DMARC record, I think 
discussions about message disposition are outside the scope of this document.  
How about this instead:

> Such an approach might prove useful for a small number of Author
> Domains, but it is possible that applying such logic to messages with a
> large number of domains (as defined by each Mail Receiver) will expose the
> Mail Receiver to a form of denial of service attack.  Limiting the number of
> Author Domains processed will avoid this risk.  If not all Author Domains
> are processed, then the DMARC evaluation is incomplete.

I don't think we need to tell people what to do with such messages.  I think 
this is enough.

Scott K


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

Re: [dmarc-ietf] DMARCbis WGLC Issue - Clarify When Tree Walk Starts?

[Scott Kitterman]

On Thursday, March 7, 2024 8:55:55 AM EDT Todd Herr wrote:
> On Thu, Mar 7, 2024 at 5:08 AM Alessandro Vesely  wrote:
> > On 06/03/2024 21:00, Todd Herr wrote:
> > > Section 4.7, DMARC Policy Discovery, starts with the following sentence:
> > > For policy discovery, a DNS Tree Walk starts at the domain found in
> > > the RFC5322.From header of the message being evaluated.
> > > 
> > > I think the above is muddy, [...]
> > > 
> > > When it comes to policy discovery, if the RFC5322.From domain has a
> > > published policy record, it's the policy regardless of the value of the
> > > 'psd' tag, is it not? Step 2 of the Tree Walk would seem to indicate
> > > that if such a record didn't have psd=n then the Tree Walk would
> > > continue for policy discovery.
> > > 
> > > I believe that the first sentence in Section 4.7 should be replaced as
> > > 
> > > follows:
> > > For policy discovery, first query for a DMARC policy record at the
> > > name created by prepending the label "_dmarc" to the RFC5322.From
> > > domain. If no valid DMARC policy record is found there, then perform
> > > a DNS Tree Walk starting with the parent domain of the RFC5322.From
> > > domain.
> > 
> > That's not exact.  If the From: domain has more than 5 labels you don't
> > start with its parent domain.
> > 
> > My take:
> > Policy discovery starts by querying the DMARC record for the
> > RFC5322.From domain, as in step 1 of the DNS Tree Walk.  If a record
> > is found there, that's the policy record, otherwise continue the
> > DNS Tree Walk .
> 
> You are of course correct, Ale; thank you for spotting my error.

I've reviewed the text in the rev 31 branch in Git (which is essentially 
what's above) and I think this is good.

Scott K


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

Re: [dmarc-ietf] The description of psd=n

[Scott Kitterman]

On Wednesday, March 6, 2024 6:04:01 AM EDT Alessandro Vesely wrote:
> On 05/03/2024 21:47, Scott Kitterman wrote:
> > On March 5, 2024 8:10:46 PM UTC, Todd Herr 
 wrote:
> >> On Tue, Mar 5, 2024 at 1:30 PM Scott Kitterman  
wrote:
> >>> On March 5, 2024 2:47:47 PM UTC, Todd Herr 
 wrote:
>  On Tue, Mar 5, 2024 at 6:12 AM Alessandro Vesely  
wrote:
> > Section 5.3, in the format description of psd:
> > n:  The DMARC policy record is published for a PSD, but it is
> > the
> > 
> >Organizational Domain for itself and its subdomain.  There
> >is
> >no need to put psd=n in a DMARC record, except in the very
> >unusual case of a parent PSD publishing a DMARC record
> >without
> >the requisite psd=y tag.
> > 
> > Perhaps a "not" is missing between "is" and "published"?  I'd
> > just say the domain is not a PSD /and/ it is the
> > Organizational Domain for itself and its subdomain. >
>  
>  You may be correct in your assertion here; I'll wait for others to
>  weigh
> >>> 
> >>> in.
> >>> 
>  In the meantime, Issue 126 has been opened to track this.
> >>> 
> >>> I think it's missing a not, but is overwise fine.
> >> 
> >> John Levine commented directly on issue 126
> >> ,
> >> 
> >> indicating that he believes the text should read (emphasis added by me):
> >>n:  The DMARC policy record is published for a PSD, but it is NOT
> >>the
> >>
> >>   Organizational Domain for itself and its subdomain.  There is
> >>   no need to put psd=n in a DMARC record, except in the very
> >>   unusual case of a parent PSD publishing a DMARC record without
> >>   the requisite psd=y tag.
> >> 
> >> I think this is the correct place to put the 'not', as it's consistent
> >> with
> 
> >> the second sentence here, as well as this text from the following 
sections:
> I thought psd=n means the domain is not a PSD.  Why would the text say
> the opposite?
> 
> >> 4.8 Organizational Domain Discovery - "If a valid DMARC record contains
> >> the
> >> psd= tag set to 'n' (psd=n), this is the Organizational Domain, and the
> >> selection process is complete."
> 
> This says psd=n means the domain IS the org domain.
> 
> >> 11.8 Determination of Organizational Domain for Relaxed Alignment -  "If
> >> a
> >> PSD domain publishes a DMARC record without the appropriate psd=y tag,
> >> organizational domain owners can add psd=n to their organizational
> >> domain's
> >> DMARC record so that the PSD record will not be incorrectly evaluated to
> >> be
> >> the organizational domain."
> 
> Ditto.
> 
> Besides, to say that a record is "published for" may sound as indicating
> who are the target readers of such publication.  Holding that a domain
> owner publishes psd=n in the hope that its PSO will read it and
> consequently amend its own record is not a valid interpretation of the
> text proposed above...
> 
> Shouldn't it be thus:
> 
>n:  The domain is NOT a PSD, it is the Organizational Domain for
>   itself and its subdomain.  There is no need to put psd=n in a
>   DMARC record, except in the very unusual case of a parent PSD
>   publishing a DMARC record without the requisite psd=y tag.
> 
> Best
> Ale

Yes.  I've reviewed the change in the rev 31 draft in Git and the not was 
added in the wrong place.

Please update rev 31 and then close the issue again.

Scott K



___
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

[Neil Anuskiewicz]

> On Mar 16, 2024, at 9:38 AM, Scott Kitterman  wrote:
> 
> On Saturday, March 16, 2024 4:52:54 AM EDT Tero Kivinen wrote:
>> John Levine writes:
>>> It appears that Todd Herr   said:
 I agree that clarifying it can't hurt, obviously, ...
>>> 
>>> I disagree, it does hurt.
>>> 
>>> If we say you're allowed to use CNAMEs to point to DMARC records,
>>> people are to say uh oh, is there something special here? What about
>>> DKIM records? what about SPF records? how about SPF includes? or SPF
>>> redirects?
>>> 
>>> Really, there is nothing to say here, so let's not say it.
>> 
>> We could add an example Appendix B that uses CNAME, so that would give
>> indication, yes of course you can use CNAMEs, without explicitly
>> adding text that might cause confusion.
> 
> I think we have more important things to spend our time on.
> 
> Scott K
> 

I agree that CNAMES isn’t worth time or effort. From what I’ve seen it’s the 
larger ESP’s do this and they document it and they provide records to copy and 
paste from the auth settings into DNS. Then you go back and click a button and 
it lights up green. The sort of person who’s confused by the CNAME is the same 
person confused by a TXT record. I’m reading DMARCbis 30  now and things are 
looking good to me.

My only quibble is, so far, I’ve not seen a clear,  concise explanation of the 
general purpose domain. It’s not complicated but I think the idea is going to 
be new for a lot of people. Some people might misunderstand in less than useful 
ways as well.

Neil


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

Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

[Scott Kitterman]

On Thursday, March 14, 2024 12:24:50 PM EDT Scott Kitterman wrote:
> On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote:
> > Colleagues,
> > 
> > Issue 135 is open for the subject topic. Please add your thoughts to this
> > thread and/or to the issue in Github.
> > 
> > Thank you.
> 
> I'd suggest we discuss where to say it first.  I think the right place is
> security considerations, which starts:
> 
> 11.  Security Considerations
> 
>This section discusses security issues and possible remediations
>(where available) for DMARC.
> 
> I think there are two, related questions here:
> 
> One is the risk associated with which I'll call a false pass from one of the
> underlying authentication mechanisms.
> 
> The other is the risk associated with using DMARC results for positive
> associations (as BIMI does).  Even absent third party considerations, all it
> takes is one compromised user account and forged messages can get a DMARC
> pass.  DMARC was designed to identify "bad" mail, not certify any kind of
> goodness.
> 
> I think both of these should be addressed as part of this issue in Security
> Considerations.

It seems to me that, to the extent we are going to address this issue, there 
is agreement that Security Considerations is appropriate.  Here's proposed 
text:

11.X  External Mail Sender Cross-Domain Forgery

Both of the email authentication methods which underlie DMARC fundamentally 
provide some degree of assurance that an email was transmitted by an MTA which 
is authorized to do so.  SPF policies just map domain names to sets of 
authorized MTAs [ref to RFC 7208, section 11.4].  Verified DKIM signatures 
indicate that an email was transmitted by an MTA with access to a private key 
that matches the published DKIM key record.

When Domain Owners authorize mail to be sent by sources outside their 
Administrative Management Domain there is a risk that an overly permissive 
source may send mail which will, as a result, receive a DMARC pass result that 
was not, in fact, authorized by the Domain Owner.  These false positives may 
lead to issues with systems that make use of DMARC pass results to indicate a 
message is in some way authentic.  They also allow such unauthorized senders 
to evade the Domain Owner's requested message handling for authentication 
failures.

The only method to avoid this risk is to ensure that no overly permissive 
sources can successfully DKIM sign the domain's mail or transmit mail which 
will evaluate as SPF pass.  If there are non-DMARC reasons for a domain owner 
to include a permissive source in a domain's SPF record, the source can be 
excluded from DMARC consideration by using the '?' qualifier on the SPF record 
mechanism associated with that source.

Scott K


___
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

[Scott Kitterman]

On Saturday, March 16, 2024 4:52:54 AM EDT Tero Kivinen wrote:
> John Levine writes:
> > It appears that Todd Herr   said:
> > >I agree that clarifying it can't hurt, obviously, ...
> > 
> > I disagree, it does hurt.
> > 
> > If we say you're allowed to use CNAMEs to point to DMARC records,
> > people are to say uh oh, is there something special here? What about
> > DKIM records? what about SPF records? how about SPF includes? or SPF
> > redirects?
> > 
> > Really, there is nothing to say here, so let's not say it.
> 
> We could add an example Appendix B that uses CNAME, so that would give
> indication, yes of course you can use CNAMEs, without explicitly
> adding text that might cause confusion.

I think we have more important things to spend our time on.

Scott K



___
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

[Tero Kivinen]

John Levine writes:
> It appears that Todd Herr   said:
> >I agree that clarifying it can't hurt, obviously, ...
> 
> I disagree, it does hurt.
> 
> If we say you're allowed to use CNAMEs to point to DMARC records,
> people are to say uh oh, is there something special here? What about
> DKIM records? what about SPF records? how about SPF includes? or SPF
> redirects?
> 
> Really, there is nothing to say here, so let's not say it.

We could add an example Appendix B that uses CNAME, so that would give
indication, yes of course you can use CNAMEs, without explicitly
adding text that might cause confusion.
-- 
kivi...@iki.fi

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