[dmarc-ietf] DMARC exceptions

[Douglas Foster]

DMARC is an imperfect tool, as evidenced by the mailing list problem, among
others.  DMARCbis has failed to integrate RFC7489 with RFC 7960, because it
provides no discussion of the circumstances where an evaluator should
override the DMARC result.  I believe DMARCbis needs a discussion about the
appropriate scope and characteristics of local policy.  I have developed an
initial draft of proposed language for that section, which appears below

Doug Foster


x. Exceptions / Local Policy

A DMARC disposition policy communicates the domain owner’s recommendation
for handling of messages which fail to authenticate. By definition,
this recommendation cannot take into consideration the local interest of
specific receivers, or the specific flow path of any specific message.   As
a result, evaluators should anticipate the need to implement local policy
exceptions that override the DMARC recommended disposition when
appropriate.   These exceptions can be considered in two groups:   policy
overrides and authentication overrides.   This section discusses some
expected override scenarios, without intending to be comprehensive, so that
product implementers can create appropriate exception structures for these
and similar possible situations.

x.1 Policy Overrides

x.1.1 Override p=none

A disposition policy of “none” indicates that the domain owner suspects
that some evaluators may receive some legitimate and wanted messages which
lack authentication when received.   The evaluator may reasonably conclude
that its risk of allowing a message which maliciously impersonates the
domain is much greater than the risk of hindering a
legitimate-but-unauthenticated message from the domain.   In such cases,
the local policy will override p=none and handle the domain with
p=quarantine or p=reject.

x.1.2 Override missing PSL=Y

Some PSDs have implemented DMARC policies in accordance with RFC 9901,
without a PSL tag because that RFC assumed that organizational domain
determination would be provided by the PSL.   Particularly during the early
rollout of this specification, evaluators should use the PSL to identify
DMARC policies which are intended to be treated as PSL=Y even though the
PSD’s policy has not yet been updated to include the PSD=Y tag.

x.1.3 Override strict alignment

A domain may publish aspf=s or adkim=s incorrectly, which the evaluator
will detect when legitimate and wanted messages produce a DMARC Fail
result, even though they would produce Pass using relaxed alignment.   In
this case, the evaluator overrides the strict alignment rules in the
published policy and applies a local policy of relaxed alignment.

x.2 Authentication Overrides

An Authentication Override provides alternate authentication when a message
is acceptable but the DMARC algorithm produces a result of Fail.   To
ensure that the exception does not create a vulnerability, the rule should
include at least one verified identifier with a value that indicates the
trusted message source, often coupled with unverified identifiers with
specific values the further narrow scope of the rule.

x.2.1 Mailing List messages

Mailing Lists typically add content to the Subject or Body, and replace the
Mail From address, while forwarding a message.   As a result, the
RFC5322.From address of the author can no longer produce SPF Pass or DKIM
Pass.   If list messages are received directly, without secondary
forwarding, an exception rule can typically use the Mail From address of
the list coupled with a result of SPF Pass on that address.  If the message
is received after secondary forwarding, the rule might be based on a DKIM
signature matching the list domain and a List-ID header with the list
identity.   The specific parameters will vary based on the list
characteristics and the message flow between the list and the evaluator.

x.2.2 SPF Distrust

SPF Pass is designed on the assumption that a submitting server does not
have multiple tenant domains, or does not allow domain tenants to
impersonate each other.   Some shared tenancy environments have difficulty
ensuring that this assumption is valid, weakening trust in a result of
DMARC Pass based on SPF Pass.   When an evaluator has determined that
messages from a particular domain are reliably signed, and that the SPF
policy includes an environment with weak controls, the evaluator may
implement a local policy to reject or quarantine unsigned messages from
that domain, even if the messages produce SPF PASS

x.2.3 Non-malicious impersonators

Some legitimate network services provide services to individual clients
from many domains, and generate messages on behalf of those individual
clients using the client’s email address.   These messages fail DMARC
authentication because they originate outside control of the client’s
domain owner.  While the intent of DMARC is to encourage such services to
identify their email differently, not all legitimate senders have done
so.   As with Mailing List messages, an evaluator 

Re: [dmarc-ietf] Problem with multiple policies, different alignment

[John R. Levine]

Some universities' resolvers return NOERROR instead of NXDOMAIN (samba4 server 
used as AD, and resolvers)


They still do that?  Wow.  At least that won't screw up DMARC evaluators 
too much.


In any event, I don't think it's our job to redesign our specs for the 
benefit of people who've ignored other IETF standards.


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

Re: [dmarc-ietf] Problem with multiple policies, different alignment

[OLIVIER HUREAU]

> I'm fairly sure they would say that behavior is extremely broken. It 
is so broken that I doubt it's actuallly happening other than in 
obscure corner cases involving ancient hardware with a thick layer of 
dust. 

Some universities' resolvers return NOERROR instead of NXDOMAIN (samba4 server 
used as AD, and resolvers) 

On others, you must wait for ~30s a SERVFAIL instead of NXDOMAIN. (I don't have 
the spec) 
And of course, all UDP packet port 53 with a different address destination than 
the official resolvers' IP are dropped 

Olivier 


De: "John R Levine"  
À: "dmarc"  
Cc: "Murray S. Kucherawy"  
Envoyé: Vendredi 15 Mars 2024 02:45:01 
Objet: Re: [dmarc-ietf] Problem with multiple policies, different alignment 

It appears that Murray S. Kucherawy  said: 
>It's alarming to hear that NXDOMAIN replies are never issued or (perhaps 
>more likely) are dropped by some software or firewalls. It completely 
>prevents any benefits of negative caching. I wonder what the DNS community 
>might have to say about this practice. 

I'm fairly sure they would say that behavior is extremely broken. It 
is so broken that I doubt it's actuallly happening other than in 
obscure corner cases involving ancient hardware with a thick layer of 
dust. 

I mean, if you don't get NXDOMAIN, every time you mistype a domain in 
a URL or an email address, your browser or mail server will just sit 
there indefinitely. Seems unlikely. 

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] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

[OLIVIER HUREAU]

> If we need some real world examples of this, got a few here: 

According to my measurements, 14M domain names out of 280M active domains have 
a CNAME at _dmarc. 
871,245 has a valid DMARC record. Part of them, 7609 are a 1M top popular 
domain (tranco) 

For those without DMARC records (I haven't digged a lot, just on the fly stats) 
it's either an "SPF" CNAME or wildcard TXT records 

Olivier 

De: "Mark Alley"  
À: "dmarc"  
Envoyé: Jeudi 14 Mars 2024 21:28:11 
Objet: Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs 



If we need some real world examples of this, got a few here: 

_dmarc.oit.alabama.gov 

_dmarc.tjx.com 

_dmarc.walmart.com 

_dmarc.novanta.com 
- Mark Alley 
On 3/14/2024 3:18 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., 


BQ_BEGIN



_ [ http://dmarc.example.com/ | dmarc.example.com ] IN CNAME _ [ 
http://dmarc.example.org/ | dmarc.example.org ] 


_ [ http://dmarc.example.org/ | dmarc.example.org ] IN TXT "v=DMARC1; p=reject; 
rua= [ mailto:dmarc-repo...@example.org | 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: 

BQ_BEGIN



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 [ http://c.isi.edu/ | C.ISI.EDU ] 
[ http://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. 

BQ_END



I recommend adding a paragraph to DMARCbis, section 5.1 DMARC Policy Record at 
the end of that section that reads: 

BQ_BEGIN



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. 

BQ_END

Issue 136 has been opened for this. 

-- 


Todd Herr | Technical Director, Standards & Ecosystem 
Email: [ mailto:todd.h...@valimail.com | 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 [ mailto:dmarc@ietf.org | dmarc@ietf.org ] [ 
https://www.ietf.org/mailman/listinfo/dmarc | 
https://www.ietf.org/mailman/listinfo/dmarc ] 

BQ_END

___ 
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] Problem with multiple policies, different alignment

[John Levine]

It appears that Murray S. Kucherawy   said:
>It's alarming to hear that NXDOMAIN replies are never issued or (perhaps
>more likely) are dropped by some software or firewalls.  It completely
>prevents any benefits of negative caching.  I wonder what the DNS community
>might have to say about this practice.  

I'm fairly sure they would say that behavior is extremely broken. It
is so broken that I doubt it's actuallly happening other than in
obscure corner cases involving ancient hardware with a thick layer of
dust.

I mean, if you don't get NXDOMAIN, every time you mistype a domain in
a URL or an email address, your browser or mail server will just sit
there indefinitely.  Seems unlikely.

R's,
John

___
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

[Murray S. Kucherawy]

On Fri, Mar 15, 2024 at 9:11 AM John Levine  wrote:

> 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.
>

+1, I don't understand what needs to be clarified here.  If I ask for a TXT
record at a given name, I expect to get one back (or a non-success code).
It really doesn't matter to DMARC whether that process traversed a CNAME
record in the process.  (Or if it does matter, I've yet to see a reason
why.)

-MSK, p11g
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Fri, Mar 15, 2024 at 12:55 AM Alessandro Vesely  wrote:

> On Thu 14/Mar/2024 15:47:14 +0100 Todd Herr wrote:
> > On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely 
> wrote:
> >> On 12/03/2024 03:18, Neil Anuskiewicz wrote:
> >> > Please remove the pct tag from the spec.
> >>
> >> It has been removed already, which is incompatible with current records.
> >>
> >
> > I don't believe your assertion of incompatibility to be true, Ale.
> >
> > DMARCbis, like RFC 7489 before it, contains this sentence in the
> > description of DMARC records:
> >
> > Unknown tags MUST be ignored.
> >
> > Any site implementing the DMARCbis spec will see "pct" as an unknown and
> > ignore it.
>
> People having pct=n, n ≪ 100, will be in for a harsh surprise.
>

My impression from the previous discussions is that those users weren't
getting what they expected from "pct=" anyway because of varying
implementations at receivers.  One could argue that the surprise has
already happened.

-MSK, p11g
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC Issue 134 - What To Do With Appendix A.5?

[Murray S. Kucherawy]

On Fri, Mar 15, 2024 at 3:20 AM John Levine  wrote:

> As an author of the ADSP RFC, I enthusiastically support dropping it
> into the memory hole. It was a bad idea then and time has not improved
> it.


I tend to agree.  That appendix was meant to answer the question "Why DMARC
and not ADSP?" but I think nobody is really asking that question anymore.

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

Re: [dmarc-ietf] Problem with multiple policies, different alignment

[Murray S. Kucherawy]

On Thu, Mar 14, 2024 at 9:17 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> All of this is based on my slightly confrontational comment that "Tree
> Walk is inefficient and unreliable", which maybe needs elaboration.   My
> approach to the problem changed dramatically when I discovered, by
> accident, that a subset of DNS servers will refuse to answer queries that
> produce NXDOMAIN, and a non-response does not come with a TTL value.
> Additionally, the increase in DNS traffic of at least 100% will be
> mostly NXDomain queries, while the raw volume will also increase the
> frequency of random DNS timeouts.   All of this means that a successful
> implementation needs to have optimizations which ensure known answers are
> cached, especially if that result was obtained after experiencing timeout
> errors.I don't think the oblique reference to DNS timeouts comes close
> to documenting the severity of the problem.
>

It's alarming to hear that NXDOMAIN replies are never issued or (perhaps
more likely) are dropped by some software or firewalls.  It completely
prevents any benefits of negative caching.  I wonder what the DNS community
might have to say about this practice.  I can ask at 119 next week.  Has
anyone else observed this phenomenon?

I don't know that DMARC should talk about caching answers, since it's my
impression that applications typically rely on their resolvers to implement
caching according to DNS best practices.  DMARC caching would be largely
redundant to DNS caching, and might mess with domain owners' intentional
use of their TTL values.

-MSK, participating
___
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

[Mark Alley]

On 3/14/2024 6:11 PM, John Levine wrote:

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?


Fair.


Really, there is nothing to say here, so let's not say it.
R's,
John


For some document consumers I still posit the original proposed text may 
be useful for clarity, but to their point (and yours), it's already 
presumed the reader has a working conceptual understanding of DNS; I see 
your point how it could add only more questions.



- Mark Alley


___
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

[John Levine]

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.

R's,
John

___
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

[John Levine]

It appears that Todd Herr   said:
>The reasons given were:
>
>   1. https://www.rfc-editor.org/rfc/rfc5863#section-4.1

I am reasonably sure it was referring to DNS crudware that wouldn't
let you put an underscore in the name, or that limited TXT records to
a single 255 byte string, not CNAMEs.

>   2. https://datatracker.ietf.org/doc/html/rfc6376#section-7.5

I don't see that implying anything about CNAMEs.

>   3. Neither RFC 7489 nor DMARCbis contain the phrase "CNAME", so if it's
>   not explicitly mentioned...

I suggest we mark this "no change" and close it. There is a very short
list of RRTYPEs where you're not allowed to use CNAMES, and TXT isn't
on it.

R's,
John

PS: If anyone cares, the list contains NS and MX.  See RFC 2181, sec 10.3

___
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

[Scott Kitterman]

On March 14, 2024 8:38:17 PM UTC, 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.
>
Thanks.  

CNAMES have been used for DKIM since DKIM has existed.  I don't think any of 
those things say don't use CNAMES.

I think we don't need to say anything.  Explaining how DNS works is out of 
scope.  This kind of thing is a distraction which makes the document more 
complex and confusing.

Scott K

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

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

[Todd Herr]

On Thu, Mar 14, 2024 at 4:52 PM Hector Santos  wrote:

>
> On Mar 14, 2024, at 4:02 PM, Todd Herr  40valimail@dmarc.ietf.org> wrote:
>
> On Thu, Mar 14, 2024 at 3:25 PM Hector Santos  40isdg@dmarc.ietf.org> wrote:
>
>> On Mar 14, 2024, at 10:09 AM, Todd Herr > 40valimail@dmarc.ietf.org> wrote:
>>
>> To configure SPF for DMARC, the Domain Owner MUST choose a domain to use
>> as the RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail
>> that aligns with the Author Domain, and then publish an SPF policy in DNS
>> for that domain. The SPF record MUST be constructed at a minimum to ensure
>> an SPF pass verdict for all known sources of mail for the RFC5321.MailFrom
>> domain.
>>
>>
>> A major consideration, Todd, is receivers will process SPF for SPF
>> without DMARC (payload) considerations.  IOW, if SPF is a hardfail, we have
>> SMTP processors who will not continue to transmit a payload (DATA).
>>
>> DMARCBis is making a major design presumption receivers will only use SPF
>> as a data point for a final DMARC evaluation where a potentially high
>> overhead payload was transmitted only to be rejected anyway,
>>
>
> I don't necessarily think your assertion is true here, or at least I'd
> submit that DMARCbis and RFC 7489 aren't approaching this subject any
> differently.
>
> Section 10.1 from RFC 7489, titled "Issues Specific to SPF" had two
> paragraphs, the second of which reads:
>
>Some receiver architectures might implement SPF in advance of any
>DMARC operations.  This means that a "-" prefix on a sender's SPF
>mechanism, such as "-all", could cause that rejection to go into
>effect early in handling, causing message rejection before any DMARC
>processing takes place.  Operators choosing to use "-all" should be
>aware of this.
>
>
> Yes, I agree.  I am only reminding the community SPF can preempt DMARC
> with a restrictive hardfail policy.   Does DMARCBis integrate the tag to
> delay SPF failures?
>

Perhaps some additional cautionary text for Mail Receivers, either added to
the above paragraph or just after it, warning against rejecting solely due
to SPF -all unless the SPF record is simply "v=spf1 -all"? Such text would
be consistent, for example, with M3AAWG's Email Authentication Best
Practices

document.


>
>
> DMARCbis contains the same two paragraphs with no change to the text,
> other than the section is now numbered 8.1.
>
>
>> In the ticket, I propose the following new text:
>>
>> ==
>> To configure DKIM for DMARC, the Domain Owner MUST choose a DKIM-Signing
>> domain (i.e., the d= domain in the DKIM-Signature header) that aligns with
>> the Author Domain.
>> ==
>>
>>
>> In order to maximize security, the Domain Owner is REQUIRED to choose a
>> …..
>>
>> Is REQUIRED the same as MUST?   I think SHOULD or MUST is fine as long as
>> we specify the reason it is required,
>>
>
> I'm not understanding the comment you're making here, as I don't see the
> word "REQUIRED" in anything I wrote.
>
>
> For any protocol, there are “Protocol Requirements,”   A MUST or SHOULD is
> a “Requirement” for proper support,  So I just wanted to just note that it
> can stated another way.  Developers need a Requirements Section that allow
> us to code the logic,
>
> Its getting pretty confusing for implementors.
>
>
>
I'm sorry but I'm still not understanding the source of your confusion
here. The text we're discussing is pulled from the Domain Owners section,
and while it's not explicitly stated, "choosing a DKIM-signing domain"
would essentially involve indicating to the sending platform what domain
the Domain Owner wants to use in DKIM signing and then publishing a public
key in DNS. It is presumed that the sending platform has already built into
it the ability to DKIM sign messages based on the Domain Owner's choices.

What logic must be coded to support 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

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

[Todd Herr]

On Thu, Mar 14, 2024 at 5:05 PM Mark Alley  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

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

[Mark Alley]

On 3/14/2024 3:49 PM, Todd Herr wrote:

On Thu, Mar 14, 2024 at 4:43 PM Mark Alley 
 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.

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

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

[Hector Santos]

> On Mar 14, 2024, at 4:02 PM, Todd Herr 
>  wrote:
> 
> On Thu, Mar 14, 2024 at 3:25 PM Hector Santos 
> mailto:40isdg@dmarc.ietf.org>> wrote:
>>> On Mar 14, 2024, at 10:09 AM, Todd Herr 
>>> >> > wrote:
>>> To configure SPF for DMARC, the Domain Owner MUST choose a domain to use as 
>>> the RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail 
>>> that aligns with the Author Domain, and then publish an SPF policy in DNS 
>>> for that domain. The SPF record MUST be constructed at a minimum to ensure 
>>> an SPF pass verdict for all known sources of mail for the RFC5321.MailFrom 
>>> domain.
>> 
>> A major consideration, Todd, is receivers will process SPF for SPF without 
>> DMARC (payload) considerations.  IOW, if SPF is a hardfail, we have SMTP 
>> processors who will not continue to transmit a payload (DATA).
>> 
>> DMARCBis is making a major design presumption receivers will only use SPF as 
>> a data point for a final DMARC evaluation where a potentially high overhead 
>> payload was transmitted only to be rejected anyway,  
> 
> I don't necessarily think your assertion is true here, or at least I'd submit 
> that DMARCbis and RFC 7489 aren't approaching this subject any differently.
> 
> Section 10.1 from RFC 7489, titled "Issues Specific to SPF" had two 
> paragraphs, the second of which reads:
> 
>Some receiver architectures might implement SPF in advance of any
>DMARC operations.  This means that a "-" prefix on a sender's SPF
>mechanism, such as "-all", could cause that rejection to go into
>effect early in handling, causing message rejection before any DMARC
>processing takes place.  Operators choosing to use "-all" should be
>aware of this.

Yes, I agree.  I am only reminding the community SPF can preempt DMARC with a 
restrictive hardfail policy.   Does DMARCBis integrate the tag to delay SPF 
failures?


> 
> DMARCbis contains the same two paragraphs with no change to the text, other 
> than the section is now numbered 8.1.
> 
>> 
>>> In the ticket, I propose the following new text:
>>> 
>>> ==
>>> To configure DKIM for DMARC, the Domain Owner MUST choose a DKIM-Signing 
>>> domain (i.e., the d= domain in the DKIM-Signature header) that aligns with 
>>> the Author Domain.
>>> ==
>> 
>> In order to maximize security, the Domain Owner is REQUIRED to choose a ….. 
>> 
>> Is REQUIRED the same as MUST?   I think SHOULD or MUST is fine as long as we 
>> specify the reason it is required,
> 
> I'm not understanding the comment you're making here, as I don't see the word 
> "REQUIRED" in anything I wrote.

For any protocol, there are “Protocol Requirements,”   A MUST or SHOULD is a 
“Requirement” for proper support,  So I just wanted to just note that it can 
stated another way.  Developers need a Requirements Section that allow us to 
code the logic,

Its getting pretty confusing for implementors.

—
HLS

___
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] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

[Todd Herr]

On Thu, Mar 14, 2024 at 4:43 PM Mark Alley  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.

-- 

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

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

[Mark Alley]

- Mark Alley

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.


- Mark Alley
___
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

[Todd Herr]

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.

-- 

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

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

[Scott Kitterman]

On March 14, 2024 8:18:31 PM UTC, 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.
>

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.

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

[Mark Alley]

If we need some real world examples of this, got a few here:

_dmarc.oit.alabama.gov

_dmarc.tjx.com

_dmarc.walmart.com

_dmarc.novanta.com

- Mark Alley

On 3/14/2024 3:18 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

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

[Todd Herr]

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

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

[Todd Herr]

On Thu, Mar 14, 2024 at 3:25 PM Hector Santos  wrote:

> On Mar 14, 2024, at 10:09 AM, Todd Herr  40valimail@dmarc.ietf.org> wrote:
>
> To configure SPF for DMARC, the Domain Owner MUST choose a domain to use
> as the RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail
> that aligns with the Author Domain, and then publish an SPF policy in DNS
> for that domain. The SPF record MUST be constructed at a minimum to ensure
> an SPF pass verdict for all known sources of mail for the RFC5321.MailFrom
> domain.
>
>
> A major consideration, Todd, is receivers will process SPF for SPF without
> DMARC (payload) considerations.  IOW, if SPF is a hardfail, we have SMTP
> processors who will not continue to transmit a payload (DATA).
>
> DMARCBis is making a major design presumption receivers will only use SPF
> as a data point for a final DMARC evaluation where a potentially high
> overhead payload was transmitted only to be rejected anyway,
>

I don't necessarily think your assertion is true here, or at least I'd
submit that DMARCbis and RFC 7489 aren't approaching this subject any
differently.

Section 10.1 from RFC 7489, titled "Issues Specific to SPF" had two
paragraphs, the second of which reads:

   Some receiver architectures might implement SPF in advance of any
   DMARC operations.  This means that a "-" prefix on a sender's SPF
   mechanism, such as "-all", could cause that rejection to go into
   effect early in handling, causing message rejection before any DMARC
   processing takes place.  Operators choosing to use "-all" should be
   aware of this.


DMARCbis contains the same two paragraphs with no change to the text, other
than the section is now numbered 8.1.


> In the ticket, I propose the following new text:
>
> ==
> To configure DKIM for DMARC, the Domain Owner MUST choose a DKIM-Signing
> domain (i.e., the d= domain in the DKIM-Signature header) that aligns with
> the Author Domain.
> ==
>
>
> In order to maximize security, the Domain Owner is REQUIRED to choose a
> …..
>
> Is REQUIRED the same as MUST?   I think SHOULD or MUST is fine as long as
> we specify the reason it is required,
>

I'm not understanding the comment you're making here, as I don't see the
word "REQUIRED" in anything I wrote.

If one wants to configure DKIM for DMARC, one MUST choose a DKIM signing
domain that aligns with the Author Domain, mustn't one? Saying SHOULD
choose an aligned DKIM domain means that the Domain Owner can choose not to
choose an aligned DKIM domain, and that won't be configuring DKIM for DMARC.

-- 

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

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

[Hector Santos]

> On Mar 14, 2024, at 10:09 AM, Todd Herr 
>  wrote:
> 
> 
> In the ticket, I propose the following replacement text:
> 
> ==
> Because DMARC relies on SPF [[RFC7208]] and DKIM [[RFC6376], in order to take 
> full advantage of DMARC, a Domain Owner MUST first ensure that either SPF or 
> DKIM authentication are properly configured, and SHOULD ensure that both are.

+1

> 
> To configure SPF for DMARC, the Domain Owner MUST choose a domain to use as 
> the RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail that 
> aligns with the Author Domain, and then publish an SPF policy in DNS for that 
> domain. The SPF record MUST be constructed at a minimum to ensure an SPF pass 
> verdict for all known sources of mail for the RFC5321.MailFrom domain.

A major consideration, Todd, is receivers will process SPF for SPF without 
DMARC (payload) considerations.  IOW, if SPF is a hardfail, we have SMTP 
processors who will not continue to transmit a payload (DATA).

DMARCBis is making a major design presumption receivers will only use SPF as a 
data point for a final DMARC evaluation where a potentially high overhead 
payload was transmitted only to be rejected anyway,  

> In the ticket, I propose the following new text:
> 
> ==
> To configure DKIM for DMARC, the Domain Owner MUST choose a DKIM-Signing 
> domain (i.e., the d= domain in the DKIM-Signature header) that aligns with 
> the Author Domain.
> ==

In order to maximize security, the Domain Owner is REQUIRED to choose a ….. 

Is REQUIRED the same as MUST?   I think SHOULD or MUST is fine as long as we 
specify the reason it is required,

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

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

[John Levine]

It appears that Scott Kitterman   said:
>> SPF it treated in multiple places.  We cannot warn against a bad practice in
>> one place (135) and recommend it unconditionally in another (132).
>
>That is exactly how one handles Security Considerations.  So 132 says do SPF.  
>Security Considerations gives you stuff to think about how you do SPF.  
>There's 
>not need to embed mitigations for the considerations throughout the draft 
>(someone with more IETF experience than me, please correct me if I'm wrong 
>about this).

If you're going to provide implementation advice for SPF, which I still think is
a bad idea, security considerations is indeed the least bad place to do it.

R's,
John

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

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

[Hector Santos]

> On 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=...?)
> 
> 

If anything, DMARCBis should assist (provide guidance) with ADSP to DMARC 
migration considerations.

There are still folks who don’t believe in DMARC and continue to have an ADSP.  
  ADSP has two basic policies: DISCARDABLE and ALL.

ALL means lways signed by anyone. DISCARDABLE means always signed by the Author 
Domain,

DMARCbis continues to use the term “Super ADSP” in section A5.  We may be 
beyond justifications of why DMARC replaced ADSP.   Help with migration would 
be useful.

While an ADSP DISCARD policy may translate to a DMARC p=reject, an ADSP ALL 
policy may not have any DMARC equivalent unless non-alignment was a defined 
policy (in DMARC) - I don’t there is.

All the best,
Hector Santos

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

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

[Scott Kitterman]

On Thursday, March 14, 2024 1:59:58 PM EDT Alessandro Vesely wrote:
> On Thu 14/Mar/2024 18:35:05 +0100 Scott Kitterman wrote:
> > On Thursday, March 14, 2024 11:27:03 AM EDT Alessandro Vesely wrote:
> >> On Thu 14/Mar/2024 15:09:37 +0100 Todd Herr wrote:
> >>> [...]
> >>> 
> >>> In the ticket, I propose the following replacement text:
> >>> 
> >>> ==
> >>> Because DMARC relies on SPF [[RFC7208]] and DKIM [[RFC6376], in order to
> >>> take full advantage of DMARC, a Domain Owner MUST first ensure that
> >>> either
> >>> SPF or DKIM authentication are properly configured, and SHOULD ensure
> >>> that
> >>> both are.
> >>> 
> >>> To configure SPF for DMARC, the Domain Owner MUST choose a domain to use
> >>> as
> >>> the RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail
> >>> that aligns with the Author Domain, and then publish an SPF policy in
> >>> DNS
> >>> for that domain. The SPF record MUST be constructed at a minimum to
> >>> ensure
> >>> an SPF pass verdict for all known sources of mail for the
> >>> RFC5321.MailFrom
> >>> domain.
> >>> ==
> >> 
> >> Wouldn't you at least add "trusted",  "ensure an SPF pass verdict for all
> >> known, trusted sources of mail"?  To avoid mandating an insecure
> >> behavior.
> >> Consider:
> >> 
> >> _ Hey dude, they're spoofing your domain with a tide of phishing.
> >> 
> >> _ How come?
> >> 
> >> _ You have an include:phisherman.example in your SPF.  Remove it.
> >> 
> >> _ No, since they occasionally send a true message from us, the RFC says I
> >> MUST keep it.
> 
> [...]
> 
> > I think that's issue 135, not this one.
> 
> SPF it treated in multiple places.  We cannot warn against a bad practice in
> one place (135) and recommend it unconditionally in another (132).

That is exactly how one handles Security Considerations.  So 132 says do SPF.  
Security Considerations gives you stuff to think about how you do SPF.  There's 
not need to embed mitigations for the considerations throughout the draft 
(someone with more IETF experience than me, please correct me if I'm wrong 
about this).

Scott K



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

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

[Alessandro Vesely]

On 14/03/2024 19:06, Matt V wrote:

On Thu, Mar 14, 2024 at 10:55 AM Alessandro Vesely  wrote:

On Thu 14/Mar/2024 15:47:14 +0100 Todd Herr wrote:

On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely  wrote:

On 12/03/2024 03:18, Neil Anuskiewicz wrote:

Please remove the pct tag from the spec.


It has been removed already, which is incompatible with current records.


I don't believe your assertion of incompatibility to be true, Ale.

DMARCbis, like RFC 7489 before it, contains this sentence in the 
description of DMARC records:


Unknown tags MUST be ignored.

Any site implementing the DMARCbis spec will see "pct" as an unknown and 
ignore it.


People having pct=n, n ≪ 100, will be in for a harsh surprise.


From what I understand several big mailbox providers already ignore it if 
it's not pct=0 or pct=100.



Maybe.  But new implementations will ignore pct=0 as well.


Best
Ale
--






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

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

[Matt V]

On Thu, Mar 14, 2024 at 10:55 AM Alessandro Vesely  wrote:

> On Thu 14/Mar/2024 15:47:14 +0100 Todd Herr wrote:
> > On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely 
> wrote:
> >> On 12/03/2024 03:18, Neil Anuskiewicz wrote:
> >> > Please remove the pct tag from the spec.
> >>
> >> It has been removed already, which is incompatible with current records.
> >>
> >
> > I don't believe your assertion of incompatibility to be true, Ale.
> >
> > DMARCbis, like RFC 7489 before it, contains this sentence in the
> > description of DMARC records:
> >
> > Unknown tags MUST be ignored.
> >
> > Any site implementing the DMARCbis spec will see "pct" as an unknown and
> > ignore it.
>
>
> People having pct=n, n ≪ 100, will be in for a harsh surprise.
>
>
>From what I understand several big mailbox providers already ignore it if
it's not pct=0 or pct=100.

~

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

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

[Alessandro Vesely]

On Thu 14/Mar/2024 18:35:05 +0100 Scott Kitterman wrote:

On Thursday, March 14, 2024 11:27:03 AM EDT Alessandro Vesely wrote:

On Thu 14/Mar/2024 15:09:37 +0100 Todd Herr wrote:

[...]

In the ticket, I propose the following replacement text:

==
Because DMARC relies on SPF [[RFC7208]] and DKIM [[RFC6376], in order to 
take full advantage of DMARC, a Domain Owner MUST first ensure that either 
SPF or DKIM authentication are properly configured, and SHOULD ensure that 
both are.


To configure SPF for DMARC, the Domain Owner MUST choose a domain to use as 
the RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail 
that aligns with the Author Domain, and then publish an SPF policy in DNS 
for that domain. The SPF record MUST be constructed at a minimum to ensure 
an SPF pass verdict for all known sources of mail for the RFC5321.MailFrom 
domain.

==


Wouldn't you at least add "trusted",  "ensure an SPF pass verdict for all 
known, trusted sources of mail"?  To avoid mandating an insecure behavior.

Consider:

_ Hey dude, they're spoofing your domain with a tide of phishing.

_ How come?

_ You have an include:phisherman.example in your SPF.  Remove it.

_ No, since they occasionally send a true message from us, the RFC says I 
MUST keep it.



[...]


I think that's issue 135, not this one.



SPF it treated in multiple places.  We cannot warn against a bad practice in 
one place (135) and recommend it unconditionally in another (132).



Best
Ale
--



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

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

[Scott Kitterman]

On Thursday, March 14, 2024 11:27:03 AM EDT Alessandro Vesely wrote:
> On Thu 14/Mar/2024 15:09:37 +0100 Todd Herr wrote:
> > [...]
> > 
> > In the ticket, I propose the following replacement text:
> > 
> > ==
> > Because DMARC relies on SPF [[RFC7208]] and DKIM [[RFC6376], in order to
> > take full advantage of DMARC, a Domain Owner MUST first ensure that either
> > SPF or DKIM authentication are properly configured, and SHOULD ensure that
> > both are.
> > 
> > To configure SPF for DMARC, the Domain Owner MUST choose a domain to use
> > as
> > the RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail
> > that aligns with the Author Domain, and then publish an SPF policy in DNS
> > for that domain. The SPF record MUST be constructed at a minimum to ensure
> > an SPF pass verdict for all known sources of mail for the RFC5321.MailFrom
> > domain.
> > ==
> 
> Wouldn't you at least add "trusted",  "ensure an SPF pass verdict for all
> known, trusted sources of mail"?  To avoid mandating an insecure behavior.
> Consider:
> 
> _ Hey dude, they're spoofing your domain with a tide of phishing.
> 
> _ How come?
> 
> _ You have an include:phisherman.example in your SPF.  Remove it.
> 
> _ No, since they occasionally send a true message from us, the RFC says I
> MUST keep it.
> 
> > [...]
> > 
> > Further notes on the threads that gave rise to this ticket:
> > - I do not believe that recommending the use of the ? modifier in an
> > SPF
> > record configured for DMARC is appropriate, since as I understand the
> > ?
> > modifier, the result produced is not "pass", but rather "neutral",
> > which is
> > the same as "none". Therefore, an SPF record using ? would not produce
> > an
> > aligned pass to be used with DMARC. I am willing to be convinced that
> > I'm
> > wrong here.
> 
> The drastic solution for those who unwittingly chose a non-filtering
> provider is to remove the SPF record altogether.  The compromise is to use
> the neutral qualifier.  If we mention that —which I think we should— we
> should also add that DKIM is necessary for such mail flows.

I think that's issue 135, not this one.

Scott K


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

Re: [dmarc-ietf] DMARCbis WGLC Issue 134 - What To Do With Appendix A.5?

[John Levine]

It appears that Todd Herr   said:
>-=-=-=-=-=-
>
>Colleagues,
>
>Two people have spoken up on list asking for removal of this section
>(thread subject is "A.5 Issues with ADSP in Operation") while one person
>has registered opposition to the idea. I don't believe this is anywhere
>close to critical mass for consensus.

As an author of the ADSP RFC, I enthusiastically support dropping it
into the memory hole. It was a bad idea then and time has not improved
it.

R's,
John

___
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 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.

Scott K



___
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?

[Alessandro Vesely]

On Thu 14/Mar/2024 16:44:22 +0100 Todd Herr wrote:


Issue 135 is open for the subject topic. Please add your thoughts to this 
thread and/or to the issue in Github.



I proposed an alternative text for section 5, Policy[*].  I repeat it here with 
an added sentence:


OLD
   A Domain Owner or PSO may choose not to participate in DMARC
   evaluation by Mail Receivers simply by not publishing an appropriate
   DNS TXT record for its domain(s).  A Domain Owner can also choose not
   to have some underlying authentication technologies apply to DMARC
   evaluation of its domain(s).  In this case, the Domain Owner simply
   declines to advertise participation in those schemes.  For example,
   if the results of path authorization checks ought not to be
   considered as part of the overall DMARC result for a given Author
   Domain, then the Domain Owner does not publish an SPF policy record
   that can produce an SPF pass result.

NEW
   A Domain Owner or PSO may choose not to participate in DMARC
   evaluation by Mail Receivers simply by not publishing an appropriate
   DNS TXT record for its domain(s).  A Domain Owner can also adjust how
   some underlying authentication technologies apply to DMARC evaluation
   of its domain(s).  To do so, the Domain Owner directly operates on
   its participation in those schemes.  For example, if the results of
   path authorization checks ought not to be considered as part of the
   overall DMARC result for a given Author Domain, then the Domain Owner
   does not publish an SPF policy record, or it can use the neutral
   qualifier to avoid granting "pass" results to external domains (that
   is, for example "v=spf1 ?include:example.com -all").  Obviously, the other
   authentication technology has to be resiliently implemented in such case.


Best
Ale
--
[*] https://mailarchive.ietf.org/arch/msg/dmarc/Mr0jW04HijJqeleW0sXZhWX-s3Q







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

Re: [dmarc-ietf] Problem with multiple policies, different alignment

[Alessandro Vesely]

On Thu 14/Mar/2024 12:17:17 +0100 Douglas Foster wrote:

Your latter questions were similar to Ale's

- If the SPF/DKIM domain is a parent of the From domain, then we check its
relationship to the organizational domain.   If it is a parent of the
organizational domain, the result is unaligned.   If it is anywhere between
the organizational domain and the From domain, then it is aligned.   In
either case, the Tree Walk is no needed.



Well, you remove the leftmost label and lookup the DMARC record.  Much more 
than a string comparison.  You may call it not a Tree Walk, but it actually is. 
 The point is that you stop whether or not there's psd=y, or even no record at 
all.  An Interrupted Tree Walk.  That is:


If there is a DMARC record at the From: domain and it has no psd=y, then:
   * if DKIM domain equals From: domain, aligned, no walk (already documented),
   * if DKIM domain is a direct child of the From: domain, one must check its 
record has no psd= tag,
   * if DKIM domain is the parent of the From: domain, one must check its 
record doesn't have psd=y.



I agree an appendix could be useful, unless we think developers are so much 
smarter than domain owners that the latter deserve the pedantic thoughtfulness 
that characterizes record publishing explanations, while developers can work it 
out by themselves...



Best
Ale
--



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

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

[Todd Herr]

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.

-- 

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

Re: [dmarc-ietf] DMARCbis WGLC Issue 134 - What To Do With Appendix A.5?

[Alessandro Vesely]

On Thu 14/Mar/2024 15:53:30 +0100 Todd Herr wrote:

Colleagues,

Two people have spoken up on list asking for removal of this section
(thread subject is "A.5 Issues with ADSP in Operation") while one person
has registered opposition to the idea. I don't believe this is anywhere
close to critical mass for consensus.

I've opened the subject issue for this matter, and in that issue I floated
the possibility of moving A.5 to section 7, Changes from RFC 7489, with
some text along the lines of "we deleted the discussion of ADSP from this
version, but it's preserved here for historical purposes"

Discuss...



Could do.  Although I'm uncertain about the value of preserving large passages 
of RFC 7489 in Section 7.  In fact, RFC 7489 is not going to be deleted from 
the archives.  It would be enough to reference it.



Best
Ale
--




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

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

[Alessandro Vesely]

On Thu 14/Mar/2024 15:09:37 +0100 Todd Herr wrote:

[...]

In the ticket, I propose the following replacement text:

==
Because DMARC relies on SPF [[RFC7208]] and DKIM [[RFC6376], in order to
take full advantage of DMARC, a Domain Owner MUST first ensure that either
SPF or DKIM authentication are properly configured, and SHOULD ensure that
both are.

To configure SPF for DMARC, the Domain Owner MUST choose a domain to use as
the RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail
that aligns with the Author Domain, and then publish an SPF policy in DNS
for that domain. The SPF record MUST be constructed at a minimum to ensure
an SPF pass verdict for all known sources of mail for the RFC5321.MailFrom
domain.
==



Wouldn't you at least add "trusted",  "ensure an SPF pass verdict for all 
known, trusted sources of mail"?  To avoid mandating an insecure behavior. 
Consider:


_ Hey dude, they're spoofing your domain with a tide of phishing.

_ How come?

_ You have an include:phisherman.example in your SPF.  Remove it.

_ No, since they occasionally send a true message from us, the RFC says I MUST 
keep it.




[...]
Further notes on the threads that gave rise to this ticket:

- I do not believe that recommending the use of the ? modifier in an SPF
record configured for DMARC is appropriate, since as I understand the ?
modifier, the result produced is not "pass", but rather "neutral", which is
the same as "none". Therefore, an SPF record using ? would not produce an
aligned pass to be used with DMARC. I am willing to be convinced that I'm
wrong here.



The drastic solution for those who unwittingly chose a non-filtering provider 
is to remove the SPF record altogether.  The compromise is to use the neutral 
qualifier.  If we mention that —which I think we should— we should also add 
that DKIM is necessary for such mail flows.



Best
Ale
--








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

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

[Todd Herr]

On Thu, Mar 14, 2024 at 11:04 AM Alessandro Vesely  wrote:

> On Thu 14/Mar/2024 15:38:23 +0100 Todd Herr wrote:
> > To summarize this thread, I see three nits, all of which have been added
> to
> > issue 133:
> >
> [snip]
> >
> > 3. Section 5.3., General Record Format, update the description of the
> > 'd' and 's' values for the 'fo' tag. They currently begin with
> > "Generate a DKIM failure report"/"Generate an SPF failure report",
> > respectively, and both should instead begin with "Generate a DMARC
> > failure report".
>
>
> I'm glad that's a nit.  I feared it was meant.
>
>
Honestly I'm no longer sure what's correct here.

The text I'm proposing a change to first appeared in RFC 7489, and both
value descriptions linked out to AFRF format RFCs for DKIM and SPF,
respectively (6651 and 6652).

Both of those RFCs speak of separate reporting addresses for the
failure-specific reports.

I now think this merits further 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

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

[Alessandro Vesely]

On Thu 14/Mar/2024 15:38:23 +0100 Todd Herr wrote:

To summarize this thread, I see three nits, all of which have been added to
issue 133:

1. Section 5.4, Formal Definition, reword the comments for dmarc-uri to be:

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

2. Section 5.4, update the ABNF for dmarc-value to be "%x20-3A /
%x3C-7E" (there is currently a vertical bar/pipe where the forward
slash should be)

3. Section 5.3., General Record Format, update the description of the
'd' and 's' values for the 'fo' tag. They currently begin with
"Generate a DKIM failure report"/"Generate an SPF failure report",
respectively, and both should instead begin with "Generate a DMARC
failure report".



I'm glad that's a nit.  I feared it was meant.



Please confirm/discuss further.



It looks good to me.


Best
Ale
--






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

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

[Alessandro Vesely]

On Thu 14/Mar/2024 15:47:14 +0100 Todd Herr wrote:

On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely  wrote:

On 12/03/2024 03:18, Neil Anuskiewicz wrote:
> Please remove the pct tag from the spec.

It has been removed already, which is incompatible with current records.



I don't believe your assertion of incompatibility to be true, Ale.

DMARCbis, like RFC 7489 before it, contains this sentence in the
description of DMARC records:

Unknown tags MUST be ignored.

Any site implementing the DMARCbis spec will see "pct" as an unknown and
ignore it.



People having pct=n, n ≪ 100, will be in for a harsh surprise.


Best
Ale
--





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

[dmarc-ietf] DMARCbis WGLC Issue 134 - What To Do With Appendix A.5?

[Todd Herr]

Colleagues,

Two people have spoken up on list asking for removal of this section
(thread subject is "A.5 Issues with ADSP in Operation") while one person
has registered opposition to the idea. I don't believe this is anywhere
close to critical mass for consensus.

I've opened the subject issue for this matter, and in that issue I floated
the possibility of moving A.5 to section 7, Changes from RFC 7489, with
some text along the lines of "we deleted the discussion of ADSP from this
version, but it's preserved here for historical purposes"

Discuss...

-- 

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

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

[Todd Herr]

On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely  wrote:

> On 12/03/2024 03:18, Neil Anuskiewicz wrote:
> > Please remove the pct tag from the spec.
>
> It has been removed already, which is incompatible with current records.
>

I don't believe your assertion of incompatibility to be true, Ale.

DMARCbis, like RFC 7489 before it, contains this sentence in the
description of DMARC records:

Unknown tags MUST be ignored.


Any site implementing the DMARCbis spec will see "pct" as an unknown and
ignore it.


-- 

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

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

[Todd Herr]

On Thu, Mar 14, 2024 at 10:22 AM Scott Kitterman 
wrote:

>
> I think MUST do SPF or DKIM, SHOULD do SPF, to do SPF MUST do xxx, SHOULD
> do
> DKIM, to do DKIM MUST do yyy is reasonable (that's how I parsed your
> proposed
> changes, is that right?).  I think it's an improvement and assuming I am
> reading it correctly, I support the change.
>

That is the gist of the text I've proposed, yes.

[rest snipped for further discussion when issue is opened and reported to
list]

-- 

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

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

[Todd Herr]

To summarize this thread, I see three nits, all of which have been added to
issue 133:

1. Section 5.4, Formal Definition, reword the comments for dmarc-uri to be:

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

2. Section 5.4, update the ABNF for dmarc-value to be "%x20-3A /
%x3C-7E" (there is currently a vertical bar/pipe where the forward
slash should be)

3. Section 5.3., General Record Format, update the description of the
'd' and 's' values for the 'fo' tag. They currently begin with
"Generate a DKIM failure report"/"Generate an SPF failure report",
respectively, and both should instead begin with "Generate a DMARC
failure report".

Please confirm/discuss further.



On Mon, Mar 11, 2024 at 10:17 PM Neil Anuskiewicz  wrote:

>
>
> On Mar 9, 2024, at 7: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"
>
> > 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.
>
> 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"
>
>
>
> 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
>
>
>
> Yes, since most people are used to the FO tag but would happily embrace
> this upgrade.
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

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

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

[Scott Kitterman]

On Thursday, March 14, 2024 10:09:37 AM EDT Todd Herr wrote:
> Colleagues,
> 
> After reviewing the "Another point SPF advice" thread and Murray's separate
> post re: SHOULD vs. MUST, I have opened issue 132 on the topic:
> 
> The current text of section 5.5.1, Publish and SPF Policy for an Aligned
> Domain, reads:
> 
> ==
> Because DMARC relies on SPF [[RFC7208]] and DKIM [[RFC6376]], in order to
> take full advantage of DMARC, a Domain Owner SHOULD first ensure that SPF
> and DKIM authentication are properly configured. As a first step, the
> Domain Owner SHOULD choose a domain to use as the RFC5321.MailFrom domain
> (i.e., the Return-Path domain) for its mail, one that aligns with the
> Author Domain, and then publish an SPF policy in DNS for that domain. The
> SPF record SHOULD be constructed at a minimum to ensure an SPF pass verdict
> for all known sources of mail for the RFC5321.MailFrom domain`
> ==
> 
> In the ticket, I propose the following replacement text:
> 
> ==
> Because DMARC relies on SPF [[RFC7208]] and DKIM [[RFC6376], in order to
> take full advantage of DMARC, a Domain Owner MUST first ensure that either
> SPF or DKIM authentication are properly configured, and SHOULD ensure that
> both are.
> 
> To configure SPF for DMARC, the Domain Owner MUST choose a domain to use as
> the RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail
> that aligns with the Author Domain, and then publish an SPF policy in DNS
> for that domain. The SPF record MUST be constructed at a minimum to ensure
> an SPF pass verdict for all known sources of mail for the RFC5321.MailFrom
> domain.
> ==
> 
> In addition, the last paragraph in section 5.5.2, Configure Sending System
> for DKIM Signing Using an Aligned Domain, reads:
> 
> ==
> The Domain Owner SHOULD choose a DKIM-Signing domain (i.e., the d= domain
> in the DKIM-Signature header) that aligns with the Author Domain.
> ==
> 
> In the ticket, I propose the following new text:
> 
> ==
> To configure DKIM for DMARC, the Domain Owner MUST choose a DKIM-Signing
> domain (i.e., the d= domain in the DKIM-Signature header) that aligns with
> the Author Domain.
> ==
> 
> Further notes on the threads that gave rise to this ticket:
> 
>- I do not believe that recommending the use of the ? modifier in an SPF
>record configured for DMARC is appropriate, since as I understand the ?
>modifier, the result produced is not "pass", but rather "neutral", which
> is the same as "none". Therefore, an SPF record using ? would not produce
> an aligned pass to be used with DMARC. I am willing to be convinced that
> I'm wrong here.
>- That said, I think there is room for discussion of too-permissive SPF
>records and the  cross-user forgery discussed in RFC 7208 Section 11.4,
> and I will open a separate issue for that to expand on section 8.1

I think MUST do SPF or DKIM, SHOULD do SPF, to do SPF MUST do xxx, SHOULD do 
DKIM, to do DKIM MUST do yyy is reasonable (that's how I parsed your proposed 
changes, is that right?).  I think it's an improvement and assuming I am 
reading it correctly, I support the change.

Relative to the further notes section:

I think we need to do something about this.  For SPF, there's a trade off 
available when including third parties in your SPF record that allows you to 
have them not fail SPF, but not be aligned for DMARC purposes (the ? 
qualifier).  It's a trade off and that trade off should be described.

Third parties are always a risk.  If you set up DKIM signing for a third party 
and they sign mail from your domain that you didn't send, you'll get the exact 
same issue.  It's fundamentally the same problem.  Just because we aren't 
seeing scads of this at the moment, doesn't mean we should ignore it.

I'll leave this just as a thought for now, since we should discuss it in the 
other issue, but I think this discussion probably belongs in security 
considerations.

Scott K



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

Re: [dmarc-ietf] Fwd: [Errata Held for Document Update] RFC7489 (7835)

[Todd Herr]

Issue 129 is already open to discuss all existing RFC 7489 Errata in
DMARCbis

On Mon, Mar 11, 2024 at 12:40 PM Eliot Lear  wrote:

> FYI
>
>  Forwarded Message 
> Subject: [Errata Held for Document Update] RFC7489 (7835)
> Date: Mon, 11 Mar 2024 09:34:11 -0700 (PDT)
> From: RFC Errata System 
> 
> To: giuse...@ohpe.it, superu...@gmail.com, zwi...@yahoo-inc.com
> CC: rfc-...@rfc-editor.org, rfc-...@rfc-editor.org,
> rfc-edi...@rfc-editor.org
>
> The following errata report has been held for document update for RFC7489,
> "Domain-based Message Authentication, Reporting, and Conformance (DMARC)".
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7835
>
> --
> Status: Held for Document Update
> Type: Technical
>
> Reported by: Giuseppe Trotta  
> Date Reported: 2024-03-04
> Held by: Eliot Lear (ISE & Editorial Board)
>
> Section: 6.6.3
>
> Original Text
> -
> 2. Records that do not start with a "v=" tag that identifies the
> current version of DMARC are discarded.
>
> 3. If the set is now empty, the Mail Receiver MUST query the DNS for
> a DMARC TXT record at the DNS domain matching the Organizational
> Domain in place of the RFC5322.From domain in the message (if
> different). This record can contain policy to be asserted for
> subdomains of the Organizational Domain. A possibly empty set of
> records is returned.
>
> 4. Records that do not start with a "v=" tag that identifies the
> current version of DMARC are discarded.
>
> Corrected Text
> --
> 2. Records that do not start with a "v=" tag that identifies the
> current version of DMARC are discarded.
>
> 3. If the set is now empty, the Mail Receiver MUST query the DNS for
> a DMARC TXT record at the DNS domain matching the Organizational
> Domain in place of the RFC5322.From domain in the message (if
> different). This record can contain policy to be asserted for
> subdomains of the Organizational Domain. A possibly empty set of
> records is returned.
>
> Notes
> -
> The intent of the original text is that indeed step 2 should be repeated
> as follows:
> (1) Go get a set of things.
> (2) Filter them.
> (3) If the set is now empty, go get a set of things from a different
> location.
> (4) Filter them.
>
> At the time of this writing, draft-ietf-dmarc-dmarcbis is being developed,
> and so that text may clarify this point. As such we will hold this erratum
> for update.
>
> --
> 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
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

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

Re: [dmarc-ietf] Appendix B.2.3. Per-Message Failure Reports Directed to Third Party

[Todd Herr]

On Sun, Mar 10, 2024 at 8:56 AM Alessandro Vesely  wrote:

> Hi,
>
> it would be much more real-life to exemplify directing /aggregate/
> reports to third parties, which is quite common.  Directing failure
> reports to third parties would be a privacy nightmare.
>
> I'd suggest turning the subsection from ruf= to rua=.  Indeed, the spec
> for Verifying External Destinations is Section 3 of the
> aggregate-reporting I-D.  Perhaps the whole B.2.3 should be moved there
> as well.
>
>
There are a number of vendors acting as third-party DMARC report consumers
for both aggregate and failure reports, though, so I submit that it is
"real-life" to exemplify directing failure reports to third parties.

-- 

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

Re: [dmarc-ietf] Nit: Appendix B.1, examples parallelism and typo

[Todd Herr]

These have been added to Issue 133

On Sun, Mar 10, 2024 at 8:29 AM Alessandro Vesely  wrote:

> Hi,
>
> first the typo.  Example 3 in appendix B.1.2 uses sample.net (an
> existing domain) instead of example.net:
>
>  DKIM-Signature: v=1; ...; d=sample.net; ...
>
> Second, Example 2 is labelled "parent" in both SPF and DKIM subsections.
>   However, for SPF the identifier is a child of the From: domain, while
> for DKIM the From: domain is a child of the identifier.
>
> I'd either label "child" the DKIM example or parallelize the roles of
> the identifiers.
>
>
> Best
> Ale
> --
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

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

Re: [dmarc-ietf] Section 9.5 DMARC Report Format Registry

[Todd Herr]

Acknowledged that Issue 130 is open for this.

On Sat, Mar 9, 2024 at 7:21 PM Tim Wicinski  wrote:

>
> 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
>


-- 

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

Re: [dmarc-ietf] Nit: missing angle brackets

[Todd Herr]

Issue 133 has been opened for this and subsequent nits.

On Sat, Mar 9, 2024 at 5:33 AM Alessandro Vesely  wrote:

> Hi,
>
> this is section 11.4, Display Name Attacks.  It has:
>
>From: "u...@example.org via Bug Tracker" supp...@example.com
>(mailto:supp...@example.com)
>
> Should be:
>
>From: "u...@example.org via Bug Tracker" 
>(mailto:supp...@example.com)
>
> Or even
>
>From: " via Bug Tracker" 
>(mailto:supp...@example.com)
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

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-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

[Todd Herr]

Colleagues,

After reviewing the "Another point SPF advice" thread and Murray's separate
post re: SHOULD vs. MUST, I have opened issue 132 on the topic:

The current text of section 5.5.1, Publish and SPF Policy for an Aligned
Domain, reads:

==
Because DMARC relies on SPF [[RFC7208]] and DKIM [[RFC6376]], in order to
take full advantage of DMARC, a Domain Owner SHOULD first ensure that SPF
and DKIM authentication are properly configured. As a first step, the
Domain Owner SHOULD choose a domain to use as the RFC5321.MailFrom domain
(i.e., the Return-Path domain) for its mail, one that aligns with the
Author Domain, and then publish an SPF policy in DNS for that domain. The
SPF record SHOULD be constructed at a minimum to ensure an SPF pass verdict
for all known sources of mail for the RFC5321.MailFrom domain`
==

In the ticket, I propose the following replacement text:

==
Because DMARC relies on SPF [[RFC7208]] and DKIM [[RFC6376], in order to
take full advantage of DMARC, a Domain Owner MUST first ensure that either
SPF or DKIM authentication are properly configured, and SHOULD ensure that
both are.

To configure SPF for DMARC, the Domain Owner MUST choose a domain to use as
the RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail
that aligns with the Author Domain, and then publish an SPF policy in DNS
for that domain. The SPF record MUST be constructed at a minimum to ensure
an SPF pass verdict for all known sources of mail for the RFC5321.MailFrom
domain.
==

In addition, the last paragraph in section 5.5.2, Configure Sending System
for DKIM Signing Using an Aligned Domain, reads:

==
The Domain Owner SHOULD choose a DKIM-Signing domain (i.e., the d= domain
in the DKIM-Signature header) that aligns with the Author Domain.
==

In the ticket, I propose the following new text:

==
To configure DKIM for DMARC, the Domain Owner MUST choose a DKIM-Signing
domain (i.e., the d= domain in the DKIM-Signature header) that aligns with
the Author Domain.
==

Further notes on the threads that gave rise to this ticket:

   - I do not believe that recommending the use of the ? modifier in an SPF
   record configured for DMARC is appropriate, since as I understand the ?
   modifier, the result produced is not "pass", but rather "neutral", which is
   the same as "none". Therefore, an SPF record using ? would not produce an
   aligned pass to be used with DMARC. I am willing to be convinced that I'm
   wrong here.
   - That said, I think there is room for discussion of too-permissive SPF
   records and the  cross-user forgery discussed in RFC 7208 Section 11.4, and
   I will open a separate issue for that to expand on section 8.1


-- 

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

Re: [dmarc-ietf] Problem with multiple policies, different alignment

[Douglas Foster]

Your latter questions were similar to Ale's

- If the SPF/DKIM domain is a parent of the From domain, then we check its
relationship to the organizational domain.   If it is a parent of the
organizational domain, the result is unaligned.   If it is anywhere between
the organizational domain and the From domain, then it is aligned.   In
either case, the Tree Walk is no needed.

- Exact match domains do not need the Tree Walk.   That is obvious and was
handled in one of my first bullets.Otherwise, the SPF/DKIM domain must
be a child of the organizational domain.   Determining whether a candidate
domain meets these criteria do not require a Tree Walk.

All of this is based on my slightly confrontational comment that "Tree Walk
is inefficient and unreliable", which maybe needs elaboration.   My
approach to the problem changed dramatically when I discovered, by
accident, that a subset of DNS servers will refuse to answer queries that
produce NXDOMAIN, and a non-response does not come with a TTL value.
Additionally, the increase in DNS traffic of at least 100% will be
mostly NXDomain queries, while the raw volume will also increase the
frequency of random DNS timeouts.   All of this means that a successful
implementation needs to have optimizations which ensure known answers are
cached, especially if that result was obtained after experiencing timeout
errors.I don't think the oblique reference to DNS timeouts comes close
to documenting the severity of the problem.

I have always felt that the Tree Walk should be referenced in the main body
as a concept, to focus on the decision process, and then described in
detail in an appendix, where the differences between first and second tree
walks can be presented succinctly, and some discussion of optimizations can
be included without losing train of thought.   You write really good prose
when you have room to do so.  In this case, the Tree Walk description  was
done early, because it was needed, but then it became frozen in place.

Doug

On Wed, Mar 13, 2024 at 10:04 AM Todd Herr  wrote:

> On Wed, Mar 13, 2024 at 6:24 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> My unsuccessful attempt to implement to the specification has reminded me
>> of my past concerns.
>>
>> Our document gives primacy to the Tree Walk, as if it will be used on
>> every From domain, SPF domain, and DKIM domain.   The Tree Walk algorithm
>> is explained in detail before any discussion of how it is used, and the
>> differences between the From walk and the SPF/DKIM walks have been
>> ignored.  I find that this makes the document harder to follow and less
>> usable.
>>
>> The reality is that the Tree Walk is an inefficient and unreliable way of
>> obtaining an answer, particularly because of the risk of DNS timeouts.   As
>> a result, the Tree Walk should be avoided whenever possible.   In fact, the
>> secondary tree walks for SPF and DKIM can frequently be avoided:
>>
>>- When strict alignment is required.
>>- When the SPF/DKIM domain is not verified.
>>- When the SPF/DKIM domain matches the From domain.
>>- When the SPF/DKIM domain is a parent of the From domain.
>>- When a string comparison shows that the SPF/DKIM domain is not a
>>child of the organizational domain
>>
>> For many messages, these optimizations will mean that no secondary tree
>> walk will be needed at all.   In the event that multiple secondary tree
>> walks are required, additional efficiencies can be gained by prioritizing
>> which signature domain is walked first.
>>
>> The Tree Walk is an important tool for deprecating the PSL.   But the
>> oversimplification of its discussion has prevented any substantive
>> consideration of either the differences between the two types of Tree Walk
>> or the available optimizations to avoid performance problems.
>>
>
> Section 4.8 in DMARCbis includes this text:
>
>
> ==
>
> Note: There is no need to perform Tree Walk searches for Organizational
> Domains under any of the following conditions:¶
> <#m_5516805231390163404_section-4.8-3>
>
>
>- The RFC5322.From domain and the RFC5321.MailFrom domain (if SPF
>   authenticated), and/or the DKIM d= domain (if present and authenticated)
>   are all the same, and that domain has a DMARC record. In this case, this
>   common domain is treated as the Organizational Domain.
>   - No applicable DMARC policy is discovered for the RFC5322.From
>   domain during the Tree Walk for that domain. In this case, the DMARC
>   mechanism does not apply to the message in question.
>   - The record for the RFC5322.From domain indicates strict
>   alignment. In this case, a simple string comparison of the RFC5322.From
>   domain and the RFC5321.MailFrom domain (if SPF authenticated), and/or 
> the
>   DKIM d= domain (if present and authenticated) is all that is required.
>
>
>