[dmarc-ietf] RUA XML : maxOccurs="unbounded" not allowed

[OLIVIER HUREAU]

Hi, 

I have tried to run some measurements with the new XSD but it seems that it is 
not valid : 

``` 
xmlschema.validators.exceptions.XMLSchemaParseError: attribute 
maxOccurs='unbounded': value must be one of [0, 1]: 
``` 

The complex type "ReportMetadataType" has a  (see below). 
However the Python library i am using refuses the XSD files as, according to 
W3, macOccurs unbounded are not accepted in all : 

``` 
Schema Component Constraint: All Group Limited 
When a model group has {compositor} all, then all of the following must be 
true: 
1 It appears only as the value of one or both of the following properties: 
1.1 the {model group} property of a model group definition. 
1.2 the {term} property of a particle with {max occurs}=1which is part of a 
pair which constitutes the {content type} of a complex type definition. 
2 The {max occurs} of all the particles in the {particles} of the group must be 
0 or 1. 
``` 
[ https://www.w3.org/TR/xmlschema-1/#cos-all-limited | 
https://www.w3.org/TR/xmlschema-1/#cos-all-limited ] [ 
https://www.w3.org/TR/xmlschema-1/#cos-all-limited ] 

Shouldn't we remove the maxOccurs for the error element ? 


-- 


OLD 
``` 
 
 
 
 
 
 
 
 
 
 
``` 



NEW 
``` 
 
 
 
 
 
 
 
 
 
 
``` 





----- 
Olivier HUREAU 
PhD Student 
Laboratoire Informatique Grenoble - UGA - Drakkar 
[ https://hureau.com/ | hureau.com ] 
___
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] picking nits with the ABNF

[OLIVIER HUREAU]

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


BQ_BEGIN

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

BQ_END

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

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

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

Could they be rewritten for readability 

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

gladly tell me i'm too obsessive 


thanks 
tim 



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

Re: [dmarc-ietf] Working Group Last Call on draft-ietf-dmarc-dmarcbis-30

[OLIVIER HUREAU]

Would you prefer one comment/issue or in batch? 


De: "Todd Herr"  
À: "dmarc"  
Envoyé: Jeudi 29 Février 2024 15:37:01 
Objet: Re: [dmarc-ietf] Working Group Last Call on draft-ietf-dmarc-dmarcbis-30 

On Wed, Feb 28, 2024 at 7:37 PM Barry Leiba < [ mailto:barryle...@computer.org 
| barryle...@computer.org ] > wrote: 



The editors and chairs think version -30 resolves the open issues and is ready 
for a final look, so this message starts a working group last call for the 
DMARCbis spec. Because of the upcoming IETF 119 meeting, we’ll let this go 
until the end of March, so there’s lots of time to review. 

Please post to the DMARC mailing list by 31 March, giving your last call 
comments (which should include “I read it and I think it’s ready” as well). If 
you have significant issues to raise that have not already been discussed and 
closed, please post each of those as a separate thread. Minor issues and 
editorial comments can just be posted here, to this thread, and we can split 
them off if necessary. 

Please do keep in mind that we have discussed this at great length and over a 
long time period. Therefore, please do NOT ask to re-open settled issues 
because you still disagree with the result. Significant issues raised at this 
point need to be accompanied by a clear, understandable explanation of why this 
is a NEW argument. 




I'll be tracking minor issues and editorial comments in Github Issue 121, which 
I've cleverly titled "WGLC Minor Issues and Editorial Comments". 

I've already found one: Kurt Andersen's last name is misspelled in 
"Acknowledgements - RFC 7489". 

[ https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/121 | 
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/121 ] 

-- 



Todd Herr | Technical Director, Standards & Ecosystem 
e: [ mailto:todd.h...@valimail.com | todd.h...@valimail.com ] 
p: 703-220-4153 
m: 703.220.4153 


This email and all data transmitted with it contains confidential and/or 
proprietary information intended solely for the use of individual(s) authorized 
to receive it. If you are not an intended and authorized recipient you are 
hereby notified of any use, disclosure, copying or distribution of the 
information included in this transmission is prohibited and may be unlawful. 
Please immediately notify the sender by replying to this email and then delete 
it from your system. 

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

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[Olivier Hureau]

On 15/11/2023 14:22, Alessandro Vesely wrote:



We've had quite some discussion on that scheme, which resulted in
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-aggregate-reporting/blob/main/dmarc-xml-0.2.xsd 

included in the current draft. 


Indeed, I was referring to this one.
However, I think you should have a fixed value for the /version variable 
in order to clearly differentiate the XSD version, Even thought it is 
clearly specified in RFC 7489 :
``` The "version" for reports generated per this specification MUST 
bethe value 1.0. ``` It is not yet specified in Dmarcbis.


On 16/11/2023 02:25, Steven M Jones wrote:

I can put an updated version on dmarc.org


Attached you will find the version of the XSD as presented in RFC 7489. 
I have removed the trailing white-space and line breaks.
However, I would suggest waiting the WG opinion before doing any 
modifications. It's been like that for a long time already.



Regards,

Olivier





rfc7489.xsd
Description: XML document
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[OLIVIER HUREAU]

Hi, 

As mentioned here: [ 
https://mailarchive.ietf.org/arch/msg/dmarc/ouSBtpMhD5KJp2osPfUXJktuoMQ/%C2%A0 
| https://mailarchive.ietf.org/arch/msg/dmarc/ouSBtpMhD5KJp2osPfUXJktuoMQ/  ] 
I have found out that the current reporting ecosystem uses two types of XML 
Schema Definitions. 

During IETF-118, I raised concerns to John and Murray regarding the current 
reporting ecosystem's use of two types of XML Schema Definitions. 
They suggested creating a dedicated thread to address this matter. 

Upon investigation, I found that the XSD present in RFC 7489 Appendix C ( [ 
https://datatracker.ietf.org/doc/html/rfc7489#appendix-C | 
https://datatracker.ietf.org/doc/html/rfc7489#appendix-C ] ) contains a 
targetNamespace with the URI [ http://dmarc.org/dmarc-xml/0.1. | 
http://dmarc.org/dmarc-xml/0.1. ] 
However, the website offers a different XSD. It seems plausible that 
implementers may have downloaded the version from dmarc.org, which lacks 
certain elements like /record/auth_result/spf/scope, /policy_published/fo, 
/record/identifiers/envelope_from, and /version, in contrast to the RFC 
version. 

Additionally, errata 5229 ( [ https://www.rfc-editor.org/errata/eid5229 | 
https://www.rfc-editor.org/errata/eid5229 ] ) and 5733 ( [ 
https://www.rfc-editor.org/errata/eid5229 | 
https://www.rfc-editor.org/errata/eid5229 ] ) introduce further disparities. 

Furthermore, the Dmarcbis XML schema ( [ 
https://www.ietf.org/archive/id/draft-ietf-dmarc-aggregate-reporting-13.html#name-appendix-a-dmarc-xml-schema
 | 
https://www.ietf.org/archive/id/draft-ietf-dmarc-aggregate-reporting-13.html#name-appendix-a-dmarc-xml-schema
 ] ) also deviates from the previous versions. 

These inconsistencies pose challenges for report receivers, leading to 
difficulties in parsing aggregated reports. 
I believe it is imperative for our working group to address and rectify these 
issues. 

I was personally thinking about the following options: 

1) Specify Version "2" in the XML Schema for DmarcBis Aggregated Reports: 
While this option provides clarity on the version, there may be reluctance 
among actors to re-implement the reporting system. 
I am not sure that even with Dmarcbis, the report's sender will modify their 
implementation 

2) Explore a JSON Format for Aggregated Reports: 
Considering a shift to a JSON format may address the inconsistencies and 
encourage improvements in implementations. 
This approach could potentially bring about a positive transformation in the 
reporting system (at the same time, they might fix their implementations and 
have a correct email object, who knows..). 

3) Create an Extended XML Schema for Interoperability: 
Developing an extended XML schema that ensures interoperability across all 
versions could be a comprehensive solution. 
I have identified a working draft ( [ 
https://github.com/jorritfolmer/TA-dmarc/blob/master/bin/dmarc/rua_ta_dmarc_relaxed_v01.xsd
 | 
https://github.com/jorritfolmer/TA-dmarc/blob/master/bin/dmarc/rua_ta_dmarc_relaxed_v01.xsd
 ] ) 
that demonstrates promise, having resulted in approximately 10 times fewer 
reports with errors. 

I am inclined towards the third option as it offers a holistic approach to 
interoperability. 

I am looking forward to your remarks and propositions. 

Regards, 
Olivier Hureau 



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

Re: [dmarc-ietf] Question on RFC7489: trailing whitespaces

[Olivier Hureau]

Hi,

I'm digging up an old discussion, sorry.

It is also related to one of the discussion I opened about duplicate tag :
https://mailarchive.ietf.org/arch/msg/dmarc/NAWZlMNnXt9m_MCvuou9IiYxSrA/

Murray pointed out that a parser is also supposed to follow the DKIM 
specifications.
Finally, Alessandro proposed an expansion of the statement about DKIM 
specification in DMARC.

Thus, If we follow the DKIM RFC6376 specifications, whitespace are 
allowed :


```Note that WSP is allowed anywhere around tags. In particular, any

   WSP after the "=" and any WSP before the terminating ";" is not part
   of the value; however, WSP inside the value is significant.```

https://datatracker.ietf.org/doc/html/rfc6376#section-3.2


Regards,
Olivier



On 27/02/2023 19:14, Scott Kitterman wrote:

Seems reasonable.  Thanks for the warning on the required white space 
engineering.

Scott K

On February 27, 2023 6:05:11 PM UTC, John Levine  wrote:

It appears that Tim Wicinski  said:

-=-=-=-=-=-

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

I made a pull request.  The change is four characters but the pull request
looks complicated because I had to futz with whitespace to keep xml2rfc

>from complaining that things are too wide.

R's,
John


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


On Mon, Feb 27, 2023 at 2:29 AM Tõnu Tammer
wrote:


I am curious to know what the stance is on trailing whitespace within
DMARC records.

Strictly following the RFC 7489 and the formal specification in section
6.4, if there is no trailing dmarc-sep with the associated semicolon,
trailing whitespace is not allowed.



For example a record like: "v=DMARC1; p=reject; pct=100 " would be
invalid,
whereas "v=DMARC1; p=reject; pct=100 ; " would be valid.


I think your interpretation is correct, that's what the specification
says.  A parser would be right to reject it.

As an implementer, I would probably tolerate this.  Trailing whitespace
has almost never been something worth failing on in my experience.

I would also suggest that the working group discuss making such tolerance
explicit in the bis document if it's not too late to add a small issue for
consideration.

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


-=-=-=-=-=-
[Alternative: text/html]
-=-=-=-=-=-


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


--
--
Olivier HUREAU
PhD Student
Laboratoire Informatique Grenoble - UGA - Drakkar



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC session at IETF 118

[OLIVIER HUREAU]

I was personally planning to go to the IETF-118 specifically for the DMARC 
meeting. In the end, many other activities caught my eye. 
However, if any of you are going to the IETF, I'd be happy to share a few words 
about DMARC and put a face to your e-mail addresses. 

Regards, Olivier 


De: "Barry Leiba"  
À: "IETF DMARC WG"  
Envoyé: Mercredi 1 Novembre 2023 23:20:46 
Objet: Re: [dmarc-ietf] DMARC session at IETF 118 

The sense I’m getting is to cancel the session in Prague. I’ll do that tomorrow 
(Thursday) morning SFO time unless someone screams loudly with a convincing 
reason that we need to keep the session. 

Barry 

On Sat, Oct 28, 2023 at 10:38 AM Barry Leiba < [ mailto:barryle...@computer.org 
| barryle...@computer.org ] > wrote: 


I'm starting this in a separate thread that I want to keep for ONLY 
the following question: 

Do we want to use the session we have scheduled at IETF 118 to talk 
about the issue that clearly is still in discussion about adding a tag 
to specify which authentication mechanism(s) to use when evaluating 
DMARC? 

Or shall I cancel the 118 session and just let the discussion continue 
on the mailing list? 

And being clear here: the "eliminate SPF entirely" suggestion is 
definitely out, failing rough consensus. We're *only* talking about 
the suggestion to add a tag to specify what the sender wants. 

Barry 




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

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

[OLIVIER HUREAU]

> Error reports are a different class than failure errors 
Indeed, I was referencing those ones. 

> Did any mail operator actually sends error reports 
I had access to multiple reports (~40K). I have seen a lot of aggregate, some 
forensic/failures (very rare), but no error reports. 

Regards, 
Olivier 




De: "Matthäus Wander"  
À: "dmarc"  
Envoyé: Mercredi 1 Novembre 2023 19:13:02 
Objet: Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception. 

Steven M Jones wrote on 2023-11-01 10:46: 
> On 10/25/23 4:25 AM, Matthäus Wander wrote: 
>> Olivier Hureau wrote on 2023-10-25 12:56: 
>>> What about using the error report of RFC 7489 for this purpose 
>>> instead of aggregate report? ( 
>>> https://datatracker.ietf.org/doc/html/rfc7489#section-7.2.2 ) 
[...] 
> Failure reports were actually sent for many years, and not just by small 
> operators - NetEase and Hotmail were sending them between 2013 and 2018. 
> And the reports had real value, even when heavily redacted. 

Error reports are a different class than failure errors. Did any mail 
operator actually send error reports as per RFC 7489 Section 7.2.2? 

Regards, 
Matt 

___ 
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] Jumping the Gun

[Olivier Hureau]

On 26/10/2023 07:25, Mark Alley wrote:

On Wed, Oct 25, 2023, 8:25 PM Jesse Thompson  wrote:



Is it advisable to use "t=y pct=0" for backwards compatibility?


I'm curious about this as well.

I imagine implementation experience with this will vary widely because 
there's unfortunately no shortage of receivers rolling non-standard 
DMARC evaluation logic with liberal interpretations of expected syntax 
and tags, even though the ABNF and section 5.3 are explicit with 
instruction on how to proceed in those cases.



- Mark Alley


I assume there is a semicolon such as 't=y; pct=0'

As unknown tags must be ignore in both RFC 7489 and dmarcbis : the 
unknown tag "t" must be ignored by an RFC 7489 parser.
Same for a dmarcbis parser, as the pct tag does not exist anymore, the 
parser must ignore "pct".


If it is a backward-compatible parser, I would personally ignore the 
oldest tags : pct.


Regards,
Olivier



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

[Olivier Hureau]

On 25/10/2023 13:25, Matthäus Wander wrote:


As error reports have never gotten any traction, it would be a big 
effort to make this work. Reusing the existing ecosystem of aggregate 
reports is a lower hanging fruit. Tools and processes are established 
and even the aggregate report format supports it already.



I totally understand..


I believe aggregate reports have already addressed this issue 
(Verifying External Destinations).


In current RFC 7489 EDV are a "SHOULD", it is upgraded to "MUST" in 
dmarcbis.


However, the Usenix paper I have provided earlier have shown that it is 
not widely respected.



--
------
Olivier HUREAU
PhD Student
Laboratoire Informatique Grenoble - UGA - Drakkar

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

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

[Olivier Hureau]

On 25/10/2023 08:10, Steven M Jones wrote:


It's not so much changing the handling as changing the reporting.

* The policy to apply is "none," because the p/sp/np value was faulty. 
Done.
* Next step, if there's no "rua" target you can't report - which is 
now equivalent to bailing out of DMARC processing for this message.



I am not fan of this exceptions, it breaks the ABNF ... 'A DMARC policy 
recordMUSTcomply with the formal specification found inSection 5.4 
' 

The record 'v=DMARC1; p=foobar; rua=mailto:r...@example.com' does not 
comply with the formal specification (ABNF rule dmarc-request)
Furthemore, 'mailto://example.com' is a valid URI according to RFC3986. 
If we take into consideration the record 'v=DMARC1; p=foobar; 
rua=mailto://example.com' : a 'rua' tag is present and contains at least 
one syntactically valid reporting URI (no need to have a mailto). Who 
are we going to send the reports specifying the errors?


What about using the error report of RFC 7489 for this purpose instead 
of aggregate report? ( 
https://datatracker.ietf.org/doc/html/rfc7489#section-7.2.2 )


I have never seen any error report but I think that error reports were a 
great ideas because they can advertise the domain owner (through the 
valid URI) for any failing external destination verification
We could also use the error reports for  to reports any syntactic errors 
in the record could be also useful, in my opinion.


However, it needs to be well defined to avoid sending to much 
unsolicited  message (Usenix 2023 : You've Got Report: Measurement and 
Security Implications of DMARC Reporting 
.)
Sending error reports only to domains under authority of the Domain 
Owner would solve the issue.


Regards,
Olivier



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

[Olivier Hureau]

On 20/10/2023 21:35, Murray S. Kucherawy wrote:


A couple of things here:

(1) As written, the text says (to me) that the handling of a message 
might change depending on this mapping of a broken value to "none", 
but only if "rua" is present; absent "rua", the record is treated as 
junk and DMARC doesn't apply.  That seems a peculiar decision tree to 
me.  We might want to tease these apart: Does the policy handling 
change in the presence of a typo, or does the reporting logic change, 
or both?  And don't gate it on the "rua" tag.  (And if "quarantine" is 
misspelled, how do we know "rua" isn't?)


(2) Mapping a misspelled "reject" or "quarantine" to "none" even only 
in the report will be confusing; the domain owner will be told there's 
a "none" out there when there isn't.  A non-thorough domain owner 
might conclude that the receiver is broken and not debug their 
problem.  The guidance here ought to result in the report indicating 
somehow that the receiver assumed "none" because what it extracted 
from the DNS appeared to be junk.  Should the report include a 
mechanism making this explicit?


-MSK, participating


As we can see this text is to prone to multiple interpretation. I would 
said that there is the "naive" one that is only looking at the RFC 
itself (Murray's and mine) and the "logic" one (Alessandro's and Neil's) 
that interprets the RFC on a practical way and as experienced DMARC user.


In my opinion, not only this exception does not contribute something 
constructive, from an operative point of view  it also complicates 
implementation.


I would argue that the documents (RFC 7489 and Dmarcbis) already contain 
enough parsing information and I would rather ignore the spelling 
mistake for sp= and np= and reject the record if p= is not valid.


However, it leads to writing an errata for RFC 7489.

Regards,
Olivier



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

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

[OLIVIER HUREAU]

Hi, 

> The correct solution is that the person responsible for creating the problem 
> record should fix the problem record they created. 

How does downgrading p=reject to p=none help the person responsible for 
creating the problem record to fix it? 

If it is by looking at the aggregate report, sp and np DispositionType is 
enough, no need to change p 

Olivier 


De: "Dotzero"  
À: "dmarc"  
Envoyé: Vendredi 20 Octobre 2023 17:05:45 
Objet: Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception. 



On Fri, Oct 20, 2023 at 10:39 AM OLIVIER HUREAU < [ 
mailto:olivier.hur...@univ-grenoble-alpes.fr | 
olivier.hur...@univ-grenoble-alpes.fr ] > wrote: 



Hi, 

> Why would we even consider going down this path? 
I am considering this pass in order to fix any miscomprehension in the RFC. 

> Why do you only consider "fixing" quarantine with a dropped "e"? Why don't 
> you want to fix all the other potential mispellings of quarantine? 
> Should quarntine be a candidate for "fixing"? If not, why not? 

I think I wasn't clear enough. 
I am not concerned about fixing misspelled tags, I am only concerned about the 
possible "downgrade" of p=reject to p=none if sp/np tag is not valid (and rua 
is present) 



Regards, 
Olivier 




The correct solution is that the person responsible for creating the problem 
record should fix the problem record they created. 

Michael Hammer 

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

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

[OLIVIER HUREAU]

Hi, 

> Why would we even consider going down this path? 
I am considering this pass in order to fix any miscomprehension in the RFC. 

> Why do you only consider "fixing" quarantine with a dropped "e"? Why don't 
> you want to fix all the other potential mispellings of quarantine? 
> Should quarntine be a candidate for "fixing"? If not, why not? 

I think I wasn't clear enough. 
I am not concerned about fixing misspelled tags, I am only concerned about the 
possible "downgrade" of p=reject to p=none if sp/np tag is not valid (and rua 
is present) 



Regards, 
Olivier 




De: "Dotzero"  
À: "dmarc"  
Envoyé: Vendredi 20 Octobre 2023 16:05:57 
Objet: Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception. 



On Fri, Oct 20, 2023 at 9:51 AM OLIVIER HUREAU < [ 
mailto:olivier.hur...@univ-grenoble-alpes.fr | 
olivier.hur...@univ-grenoble-alpes.fr ] > wrote: 



Hi, 

Assuming that the comma is an Oxford comma, I do interpret the sentence with 
the following boolean: 

( ' retrieved policy record does not contain a valid "p" tag' || contains an 
"sp" or "np" tag that is not valid ) && ( a "rua" tag is present and contains 
at least one syntactically valid reporting URI ) 

Nevertheless, I forgot to add the "rua" tag in the previous email: 

> 'v=DMARC1; p=reject; sp=quarantin;' (an 'e' is missing at 'quarantine') MUST 
> be interpreted as 'v=DMARC1; p=none;' because the "sp" tag is not valid. 
Should be : 

'v=DMARC1; p=reject; sp=quarantin; rua=mailto: [ mailto:r...@example.com | 
r...@example.com ] ' (an 'e' is missing at 'quarantine') MUST 
be interpreted as 'v=DMARC1; p=none;' because the "sp" tag is not valid. 
Regards, 
Olivier 
[ mailto:olivier.hur...@univ-grenoble-alpes.fr ] [ 
mailto:jan.ba...@univ-grenoble-alpes.fr ] 



Why would we even consider going down this path? Why do you only consider 
"fixing" quarantine with a dropped "e"? Why don't you want to fix all the other 
potential mispellings of quarantine? Should quarntine be a candidate for 
"fixing"? If not, why not? What if someone includes "policy=q"in their DMARC 
record? 

If someone is getting RUA reports, monitoring logs, etc., spelling and/or 
syntax mistakes should be identified fairly easily. Even something basic like 
sending test emails to freemail providers and looking at headers on the 
receiver side will quickly identify problems. 

Michael Hammer 











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

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

[OLIVIER HUREAU]

Hi, 

Assuming that the comma is an Oxford comma, I do interpret the sentence with 
the following boolean: 

( ' retrieved policy record does not contain a valid "p" tag' || contains an 
"sp" or "np" tag that is not valid ) && ( a "rua" tag is present and contains 
at least one syntactically valid reporting URI ) 

Nevertheless, I forgot to add the "rua" tag in the previous email: 

> 'v=DMARC1; p=reject; sp=quarantin;' (an 'e' is missing at 'quarantine') MUST 
> be interpreted as 'v=DMARC1; p=none;' because the "sp" tag is not valid. 

Should be : 

'v=DMARC1; p=reject; sp=quarantin; rua=mailto:r...@example.com' (an 'e' is 
missing at 'quarantine') MUST 
be interpreted as 'v=DMARC1; p=none;' because the "sp" tag is not valid. 

Regards, 
Olivier 


De: "Alessandro Vesely"  
À: "OLIVIER HUREAU" , "dmarc" 
 
Cc: "Jan Bayer"  
Envoyé: Vendredi 20 Octobre 2023 09:45:10 
Objet: Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception. 

Hi, 

On Fri 20/Oct/2023 09:04:38 +0200 OLIVIER HUREAU wrote: 
> 
> I don't understand the choice made when writing the point 6. of the policy 
> discovery mechanism (Dmarcbis : 
> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-28.html#section-4.7 
> ) 
> 
> ```If a retrieved policy record does not contain a valid "p" tag, or 
> contains an "sp" or "np" tag that is not valid, then: 
> 
> * If a "rua" tag is present and contains at least one syntactically 
> valid reporting URI, the Mail Receiver MUST act as if a record 
> containing "p=none" was retrieved and continue processing; 
> 
> * Otherwise, the Mail Receiver applies no DMARC processing to this 
> message.``` 
> 
> According to this text, the record : 
> 'v=DMARC1; p=reject; sp=quarantin;' (an 'e' is missing at 'quarantine') MUST 
> be interpreted as 'v=DMARC1; p=none;' because the "sp" tag is not valid. 


That's not my reading of the text above. The record contains a valid "p" tag, 
thereby escaping the first hypothesis of said text. 


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

[dmarc-ietf] DMARC policy discovery and invalid tag exception.

[OLIVIER HUREAU]

Dear DMARC WG members, 

I don't understand the choice made when writing the point 6. of the policy 
discovery mechanism (Dmarcbis : [ 
https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-28.html#section-4.7 | 
https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-28.html#section-4.7 ] 
) 

```If a retrieved policy record does not contain a valid "p" tag, or 
contains an "sp" or "np" tag that is not valid, then: 

* If a "rua" tag is present and contains at least one syntactically 
valid reporting URI, the Mail Receiver MUST act as if a record 
containing "p=none" was retrieved and continue processing; 

* Otherwise, the Mail Receiver applies no DMARC processing to this 
message.``` 

According to this text, the record : 
'v=DMARC1; p=reject; sp=quarantin;' (an 'e' is missing at 'quarantine') MUST be 
interpreted as 'v=DMARC1; p=none;' because the "sp" tag is not valid. 

It implies that domain name owners who had made a spelling mistake on the sp 
tag see their 'p' tag downgrade to 'none'.. 
Even though the domain owner will receive the aggregate report containing the 
'p' DispositionType, I am not sure he/she will catch the issue. 

I would then propose to set the invalid tag to none instead of the 'p' tag such 
as : 

[Old Version] 
* If a "rua" tag is present and contains at least one syntactically 
valid reporting URI, the Mail Receiver MUST act as if a record 
containing "p=none" was retrieved and continue processing; 
[/Old Version] 

[Proposition] 
* If a "rua" tag is present and contains at least one syntactically 
valid reporting URI, the Mail Receiver MUST act as if the invalid tag was set 
to none and continue processing; 
[\ Proposition ] 

The situation for RFC 7489 is slightly the same, with the keyword SHOULD 
instead of MUST: [ https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.3 
| https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.3 ] 

Best regards, 
Olivier Hureau 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] What happens when the DMARC record contains two identical tags?

[OLIVIER HUREAU]

Quick follow-up: 

I just looked at my scans for duplicates and found 8670 domain names with 
duplicates (0.007% of total DMARC records) 

'dmarc-srequest': 5551 
'dmarc-request': 1651 
'dmarc-auri': 657 
'dmarc-aspf': 292 
'dmarc-percent': 174 
'dmarc-furi': 129 
'dmarc-fo': 95 
'dmarc-ainterval': 59 
'dmarc-rfmt': 36 
'dmarc-adkim': 26 

Looking quickly at the records that fail the analysis, 5339 have the same 
record and seem to belong to the same organization (contacted) that offers 
email services. 
The records failing the semantical analysis contain an additional 
'dmarc-srequest' ('sp=none'). 

I do not know if this kind of data is relevant for this mailing list. If not, 
please let me know. 


Regards, 
Olivier Hureau 


De: "Alessandro Vesely"  
À: "dmarc"  
Envoyé: Mardi 25 Juillet 2023 13:39:17 
Objet: Re: [dmarc-ietf] What happens when the DMARC record contains two 
identical tags? 

On Mon 24/Jul/2023 18:17:10 +0200 Murray S. Kucherawy wrote: 
> On Mon, Jul 24, 2023 at 9:13 AM OLIVIER HUREAU 
>  wrote: 
> 
>>> If you want more than just the ABNF to defend that position, have a 
>>> look at the DKIM RFC, from which this syntax was cloned; it says: 
>> 
>> Then wouldn't it make sense to add this specification to DMARC-bis? 
> 
> Can't hurt. 


+1, the reference in Section 5.3 is a bit vague. For a possible expansion: 


OLD 
DMARC records follow the extensible "tag-value" syntax for DNS-based key 
records defined in DKIM [RFC6376]. 

NEW 
DMARC records follow the extensible "tag-value" syntax for DNS-based key 
records defined in DKIM [Section 3.2 of RFC6376], which defines parser behavior 
when tags are unrecognized, repeated, case-sensitive and the like. 



jm2c 
Ale 
-- 





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

Re: [dmarc-ietf] What happens when the DMARC record contains two identical tags?

[OLIVIER HUREAU]

> Correct, the ABNF doesn't allow this construction, so it's a syntax error. 

DMARCbis ABNF is not as restrictive as RFC 7489 : 

dmarc-record  = dmarc-version *(dmarc-sep dmarc-tag) [dmarc-sep] *WSP 

> If you want more than just the ABNF to defend that position, have a look at 
> the DKIM RFC, from which this syntax was cloned; it says: 

Then wouldn't it make sense to add this specification to DMARC-bis? 

Olivier 


De: "Murray S. Kucherawy"  
À: "dmarc"  
Envoyé: Lundi 24 Juillet 2023 17:57:43 
Objet: Re: [dmarc-ietf] What happens when the DMARC record contains two 
identical tags? 

On Mon, Jul 24, 2023 at 8:37 AM Mark Alley mailto:40tekmarc@dmarc.ietf.org | 40tekmarc@dmarc.ietf.org ] > wrote: 





>From my understanding, that would most likely result in a permerror code for 
>evaluation, given that's not syntactically valid per the ABNF for the 
>dmarc-record, see below where it only shows each tag once from [ 
>https://datatracker.ietf.org/doc/html/rfc7489#section-6.4 | section
6.4 ] in 7489. 


In DMARCbis, I don't see this particular table in [ 
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-28#section-5.4 
| section
5.4 ] , but given the tags are all mentioned explicitly once in both 
ABNFs, it would imply they're expected only once in the record, otherwise, 
permerror; But I'll defer to the authors if that's correct. 



Correct, the ABNF doesn't allow this construction, so it's a syntax error. 

If you want more than just the ABNF to defend that position, have a look at the 
DKIM RFC, from which this syntax was cloned; it says: 
Tags with duplicate names MUST NOT occur within a single tag-list; if
   a tag name does occur more than once, the entire tag-list is invalid. 
-MSK 

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

[dmarc-ietf] What happens when the DMARC record contains two identical tags?

[OLIVIER HUREAU]

I am wondering how a parser should behave when the record contains two 
identical tags. 

i.e: 'v=DMARC1; p=none; rua=mailto:t...@example.org; 
rua=mailto:t...@example.com;' 

While RFC 7489 and DMARC-bis state that any unknown tags must be ignored, I 
have not found any specifications about identical tags. 

Should we take into consideration the first tag? The second? Both? or ignore 
both? 

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

Re: [dmarc-ietf] Why does DKIM fail when SPF succeeds (was: DMARC2 & SPF Dependency Removal)

[OLIVIER HUREAU]

Hi, 

> c) There is a pattern of similar looking reports, which omit the  
> element in the  altogether and always report 
> fail in the policy result. I suspect a product, which makes 
> it a bit too easy to enable DMARC validation without also enabling DKIM 
> verification, but I wasn't able to identify the product yet. 

I have also discovered that some report sender does not send valid aggregate 
reports because the DKIM and SPF auth Result type are not in the right 
position. 

According to the RFC 7489 XSD, Auth Result type is as follows: 

 
 
 
 
 
 
 
 

According to XML definitions, the position cannot be swapped and the 
DKIMAuthResultType (if there is one) must appear before the SPFAuthResultType. 
However, some reporter does not follow this implementation. 

E.g: the no longer maintained Linkedin dmarc-sys : 
[ https://github.com/LinkedInAttic/dmarc-msys/blob/master/dmarc_report.py#L240 
| https://github.com/LinkedInAttic/dmarc-msys/blob/master/dmarc_report.py#L240 
] where SPFAuthResultType appears before DKIMAuthResultType . 

Are you talking about the same error? 

Best, 
Olivier 



De: "Matthäus Wander"  
À: "dmarc"  
Envoyé: Dimanche 23 Juillet 2023 22:05:44 
Objet: [dmarc-ietf] Why does DKIM fail when SPF succeeds (was: DMARC2 & SPF 
Dependency Removal) 

Barry Leiba wrote on 2023-06-10 01:50: 
> That's interesting and disturbing if it remains consistent. 
> Theoretically, DKIM should *never* fail when SPF succeeds, so if 
> that's happening it means there is: 
> 1. bad signing software, 
> 2. bad verifying software, 
> 3. misconfiguration somewhere, 
> ...or a combination of those three. 
> 
> I would *really* like to see a current study of this, because I think 
> it's critical for the future viability of DMARC, whether or not we 
> accept the proposal to remove SPF. 
Not a study, but some data points I've observed: 

a) Signing with 3072-bit RSA leads to DKIM verification failures, 
because a popular mail gateway product (Cisco ESA) does not support RSA 
key lengths larger than 2048 bit. 

b) Messages are generated by an automated system without a Date header 
and signed by a central MTA. An outgoing mail gateway then adds the 
missing Date header (Postfix option 'always_add_missing_headers'), thus 
invalidating the DKIM signature. 

Such misconfigurations go unnoticed for years until someone checks the 
DMARC reports. While aggregate reports are incredibly helpful, it is 
still difficult to identify the cause of subtle DKIM failures. I'd wish 
that the  field would be filled by reporting software with 
the DKIM verification error message ('body hash did not verify', etc.) 
to aid with troubleshooting. 

Contacting the report  or postmaster address has never worked for 
me: if they don't bounce, nobody replies. 

c) There is a pattern of similar looking reports, which omit the  
element in the  altogether and always report 
fail in the policy result. I suspect a product, which makes 
it a bit too easy to enable DMARC validation without also enabling DKIM 
verification, but I wasn't able to identify the product yet. 

Regards, 
Matt 

___ 
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] Eliminating From Munging from this list

[OLIVIER HUREAU]

> Instead, I see language that drives people to fixate on the 1% of traffic 
> that has a DMARC policy with p=reject. 

> Indeed: I caution everyone about making assumptions based on what we 
think we know, and extending those assumptions to the entire Internet. 
There are things we can study (by, for example, doing DNS queries and 
analyzing results), and there are things about which we just say, "I 
don't know anyone who does [or doesn't do] this, so that must be the 
case overall." The latter is hazardous. 

According to September 2020 scans ( [ 
https://ieeexplore.ieee.org/abstract/document/9375477/ | 
https://ieeexplore.ieee.org/abstract/document/9375477/ ] ) 

41% of them have p=reject, 9.3% have p=quarantine, and 39.6% have p=none. 

However, my September 2022 measurements (not published) shows that only 38.3% 
have p != none. 
Even though, September 2020 scans resulted in only 310,185 organizational 
domain names with DMARC and my measurements 11M8. 

> Then we are disappointed if they don't look for exceptions, including mailing 
> list messages, 

One of our latest discussions was about domain owners having p=none who might 
enhance their infrastructure. 
>From my measurements, ~40% of domain owners have p=none but nor rua/ruf. 
I extrapolate that 40% of domain owners do not plan to have more restrictive 
handling policies. 

Thus what are the expectations of newcomers in DMARC? 
In my opinion, the current state of DMARC does not meet the expectations. 
I think that the task force should take a closer look at this problem and work 
towards a more user-friendly reporting system, and different, more customizable 
handling policies. 

Best 


De: "Douglas Foster"  
À: "IETF DMARC WG"  
Envoyé: Vendredi 21 Juillet 2023 01:40:49 
Objet: Re: [dmarc-ietf] Eliminating From Munging from this list 

It is not at all clear that my goals for this effort match with others, so I 
will state mine: 
My goal is to develop documents that help evaluators make better disposition 
decisions, to save civilization from as much malicious content as possible. An 
inference from my piece of reality is that this effort has a large upside 
potential. 

Sender authentication is the core of this effort because it is something that 
we can actually specify. Defining a standard for defenses against malicious 
content seems infeasible. For all its difficulties, sender authentication is 
relatively feasible. 

Verification of RFC5322.From is the linchpin to Sender Authentication because 
the RFC5322.From address links the user-visible content to the invisible 
document metadata and SMTP protocol parameters. DMARC defines a formula for 
declaring the RFC5322.From address verified, thereby separating a general 
mailstream into two sub-streams: the verified portion and the unverified 
portion. 

This group has taken the position that a message is only verified if the domain 
owner has published a DMARC policy and the message produces DMARC PASS. From my 
data, that works out to about 40% of the traffic, most of which is Gmail. My 
results seem roughly consistent with data from other sources. This means that 
60% of the traffic has no defined method for detecting possible impersonation, 
so network safety depends entirely on the strength of your content filtering. 

However, it is easy to note that the DMARC concept of Aligned SPF PASS or 
Aligned DKIM PASS is applicable to any message, with or without a DMARC policy. 
There is a minor complication about choosing between relaxed and strict 
authentication, which is solvable by local policy. Applying the DMARC formula 
to a general mailstream, the DMARC-equivalent PASS percentage suddenly jumps 
into the vicinity of 85%. 

The remaining 15% of mail has uncertain impersonation risk, but is much more 
manageable than 60%. It has been a fertile field for investigation. When I ask, 
"Why is this message not impersonated?", the investigation produces one of 
three answers: 


* The message stream is acceptable, but needs a local policy to allow 
future messages to appear authenticated. 
* The message stream is unwanted even though it is not an impersonation, so 
this and future messages from this sender should be blocked. 
* The message stream is from a malicious impersonator, so this and future 
messages from this sender should be blocked. 
Whichever conclusion is reached, investigation is a one-time effort per message 
source. So a technical path exists for ensuring 100% authentication of all 
allowed messages, and quarantining the uncertain messages for investigation. In 
my experience, the middle result dominates. As my recurring and wanted traffic 
gets an authentication rule, and unwanted traffic gets blocked, the volume of 
investigations goes down while the percentage of block results goes up. 

When I examine the language of RFC 7489 and our proposed documents, I find no 
path toward 100% authentication. Instead, I see language that drives people to 
fixate on the 1% 

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

[OLIVIER HUREAU]

Hi, 

> Can you find a commercial product that can configure a rule which says, 
> "Don't worry about DMARC if Mail from = bounceaddtess@listdomain and the 
> MailFrom address produces SPF PASS"? 

The solution I can propose to you is using Cisco AsyncOS ( [ 
https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0.html
 | 
https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0.html
 ] ) software. 

Ciscos's solution does have Email authentication global settings where you can 
bypass the DMARC verification if the message contains a specific header. 

[ 
https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0/b_ESA_Admin_Guide_12_1_chapter_010110.html#con_1225789
 | 
https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0/b_ESA_Admin_Guide_12_1_chapter_010110.html#con_1225789
 ] 

Let's assume the header we are looking for is 'X-MAILFROM-SPF-PASS:TRUE' 

The idea is then to use the Message Filters features of AsyncOs to add a 
specific header using the action 'insert-header' 

You can then use the SPF-Status Rule ( [ 
https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0/b_ESA_Admin_Guide_12_1_chapter_01000.html#con_1132105
 | 
https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0/b_ESA_Admin_Guide_12_1_chapter_01000.html#con_1132105
 ] ) and EnvelopeFrom such as : 

overpass_dmarc_if_spf_mailfrom_pass: 
if (EnvelopeFrom == "bounceaddtess@listdomain" AND spf-status("mailfrom") == 
"Pass"){ 
insert-header("X-MAILFROM-SPF-PASS","TRUE") 
} 

I am not a Cisco expert but, to be confirmed. 

Regards, 
Olivier Hureau 


De: "Douglas Foster"  
À: "Dotzero"  
Cc: "IETF DMARC WG"  
Envoyé: Jeudi 20 Juillet 2023 04:41:57 
Objet: Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix 
it? 

Can you find a commercial product that can configure a rule which says, "Don't 
worry about DMARC if Mail from = bounceaddtess@listdomain and the MailFrom 
address produces SPF PASS"? 

Simple enough rule. If vendors understood what we want them to understand, they 
would allow creation of multipe-attribute rules like this, combining 
authentication results and identifier values, to provide local authentication 
overrides. But they don't, or at least I have not found one after diligently 
searching. 

On the other hand, finding products that block unconditionally on FAIL is 
pretty easy. 

We need to find words in our document that begin to fix this, to obtain the 
products and evaluator behavior that we both want and their users need. 

Doug 

On Wed, Jul 19, 2023, 8:07 PM Dotzero < [ mailto:dotz...@gmail.com | 
dotz...@gmail.com ] > wrote: 





On Wed, Jul 19, 2023 at 6:21 PM Douglas Foster < [ 
mailto:dougfoster.emailstanda...@gmail.com | 
dougfoster.emailstanda...@gmail.com ] > wrote: 

BQ_BEGIN

Perhaps you can clarify what you think DMARC is. 
Apparently a significant number of evaluators think that "DMARC Fail with 
p=reject always means unwanted mail". Or to use Michael Hammer's language, 
"DMARC Fail with p=reject means the domain owner wants it rejected so I will 
reject it." These are exactly the attitudes that cause us so much trouble 
because (a) DMARC Fail with p=reject does not mean that rejection is always the 
correct response, and (b) DMARC Fail with p=none is an important piece of 
information. 



You are misrepresenting my position by ignoring local policy. A DMARC policy of 
quarantine or reject is a request by the domain owner or administrator. While 
consideration of a sending domain's request should be given consideration, a 
receiving domain is free to do as it wishes. A receiving domain may choose not 
to implement DMARC validation at all. A sending domain may believe that the 
risk of some legitimate emails being rejected or quarantined is an acceptable 
tradeoff in order to protect itself and users/recipients. You appear to have a 
problem with these choices being made by both the sending domain and the 
receiving domain. Why do you presume to know better than they as to what they 
should do? Certainly, if I publish a policy of p=reject and a receiver allows 
an email that should have been rejected to reach their user/customer and that 
person contacts me because that message caused them a problem, I'm going to 
tell them they need to speak with their mail administrator, mailbox provider, 
etc. I've done that in the past and I'll do it in the future. What others 
choose to do is their choice. While I may have an opinion, I recognize that it 
is their choice. 

BQ_BEGIN


We have only two ways to block unwanted messages: Identify unwanted and 
malicious messages based on the sender, or based on the content. Impersonation 

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

[OLIVIER HUREAU]

Hi, 

> The stupid evaluator says, "p=none means no problem here". 

And the non-stupid evaluator knows that p=none means that the domain owner 
doesn't (yet) have the appropriate sending infrastructure to have p=reject. 


> The appropriate response to an authentication failure is to investigate, not 
> to block. 

When I first became interested in DMARC, I thought the idea of forensic reports 
was brilliant, as I was able to carry out investigations thanks to them. Today, 
however, forensic reports are not a trend. 
How can you properly investigate with limited information on the aggregate 
report? 

> that maliciously impersonate a major university 

It is not that related to DMARC but from what I've seen in France, scammers do 
not spoof domains name. They already have a pool of infected users in other 
universities and use those credentials to send us phishing emails (all the 
phishing I have seen comes from authenticated users at other universities) 

> How did DMARC go wrong? 

This is just my opinion, and I've published very little on this list. I just 
curiously read the discussions (especially the catchy subject like this one). 
I think DMARC went wrong as soon as the big organizations started to break away 
from the IETF and RFC7489 in particular. 
You only have to look at the inconsistencies between what is suggested and 
stated in the RFC and what happens in reality to understand why it went wrong. 


Best, 
Olivier Hureau 


De: "Douglas Foster"  
À: "IETF DMARC WG"  
Envoyé: Samedi 15 Juillet 2023 13:27:04 
Objet: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it? 

Murray recently observed, correctly, that something went horribly wrong with 
the DMARC rollout, because it caused (continues to cause) many safe and wanted 
messages to be blocked. 
My assessment was in a recent post: 

Something about the language of RFC 7489 caused implementers to focus on 
blocking individual messages, when the appropriate use of DMARC is to identify 
and investigate potentially malicious sources. 

The "message blocking" approach violates the interests of the users it is 
intended to protect: 

- An attacker sends 10 messages that maliciously impersonates a big bank. With 
help from DMARC p=reject, the evaluator blocks them all. The attacker follows 
up with 10 messages that maliciously impersonate a major university. The stupid 
evaluator says, "p=none means no problem here". The message is accepted and the 
user is harmed because the evaluator learned nothing from blocking the 
successful attack. 

Consider a variant of the above: The attacker never impersonates a big bank 
with p=reject, it only impersonates big universities with p=none. The foolish 
evaluator blocks nothing because it only acts on domains with p=reject. Again, 
the user is harmed. 

And we know the flip side: Safe and wanted messages get blocked because 
p=reject is enforced without investigation against mailing lists and other 
traffic. 

Security theory says that ANY unauthenticated message COULD be a malicious 
impersonation, and worthy of investigation. Experience says that malicious 
impersonations are a small percentage of all unauthenticated messages. As a 
result, the appropriate response to an authentication failure is to 
investigate, not to block. 

I don't know exactly how to communicate the difference between message blocking 
and sender investigation in DMARCbis, but I sure hope that we will try. 

Doug Foster 

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

Re: [dmarc-ietf] Updating ABNF for Next Rev?

[Olivier Hureau]

Hi,

> dmarc-record = dmarc-version dmarc-sep *(dmarc-tag dmarc-sep)

The problem there is the dmarc-sep must be present at the end. Indeed, 
as defined in RFC7489 it is not mandatory and a lot of current existing 
DMARC records do not ends with dmarc-sep : 74.05% of the valid DMARC 
records I found on the top 5m domain list tranco.Even if i don't like 
taking GAFAM as an example, look at google's dmarc.


If i remember well, it already has been discuss in April.

As it, I propose this rule :

dmarc-record = dmarc-version *(dmarc-sep dmarc-tag) [ dmarc-sep ]

> dmarc-fo = "fo" *WSP "=" *WSP ( "0" / "1" / ( "d" / "s" / "d:s" / 
"s:d" ) )


What about domain owner that have a value that is not listed there ? ex: 
"1:d" or even "1:d:s" ? (4.59% of explicit fo tags, from my measurements)


Do you also want to talk about ABNF for aggregate report in 
https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/ ? 
(or RFC7489) ?


From the passive measurements that i did for dmarc aggregate report (48 
monitored domains ,7135 aggregate report from 206 different reporting 
org  ) : only 4 organization strictly follow the formal definition for 
the name of the subject, the attachment or the rapport itself.


Best regards,

Olivier Hureau

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

Re: [dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07

[Olivier HUREAU]

>For those, who do not work at the IETF, the spec comes before the 
>implementation. If the spec defines a grammar that looks as 
>authoritative as the one in section 5.4, then an implementation might just 
>solve a decision problem whether a string matches 
>the grammar or not. This is a yes or no question. But as you have pointed out, 
>the authors have an implementation in mind that 
>leaks back into the spec: 

As an example libopendmarc [1] is willing to be "generous" : 

>/* 
>* Be generous. Accept, for example, "p=r, p=rej, or any 
>* left match of "reject". 
>*/ 
>if (strncasecmp((char *)vp, "reject", strlen((char *)vp)) == 0) 
> pctx->p = DMARC_RECORD_P_REJECT; 


[1] 
https://github.com/trusteddomainproject/OpenDMARC/blob/2aafb015a56d40e8a1949dc6d2ab0057aaf8b32f/libopendmarc/opendmarc_policy.c#L1009
 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07

[Olivier Hureau]

Hello,

Todd pointed out that the  with the "v=DMARC1" txt records for external 
verification explain why 'dmarc-request' is optional but we can still 
modified the rules in this way.


I also found out that on the with current rules : tags can be in 
uppercase (the only strings that are "hardcoded" are the "DMARC1" from v 
tag) and it also allow whitespace between the tag, the "=" and the value.


As it the above TXT records are valid :
- "V=DMARC1;P=REJECT"
- "v=DMARC1; p=ReJeCt"
- "v=DMAR1; p =    reject"

A lot of dmarc libraries out there says that the records is not valid, 
but according to the RFC7489 : it is.
Doing some active measurements on some email service provider i also 
found that some are case/whitespace sensitive.


I am currently writing a paper and want to submit it at the Applied 
Networking Research Workshop - IETF-114. I hope I will share all my 
results with you in a near future.


Regards,

Olivier

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

[dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07

[Olivier Hureau]

Hello,

I am doing some research related to DMARC and I found some errors in the 
RFC7489 and dmarcbis-07 for ABNF rules

- dmarc-percent RFC7489 :
The rule 'dmarc-percent = "pct" *WSP "=" *WSP 1*3DIGIT' allow '999' as a value.
a corretion could be : 'dmarc-percent = "pct" *WSP "=" *WSP ("100" / 1*2DIGIT)'

- dmarc-record RFC7489 :
The rule 'dmarc-record = dmarc-version dmarc-sep
   [dmarc-request]
   [dmarc-sep dmarc-srequest]
   [dmarc-sep dmarc-auri]
   [dmarc-sep dmarc-furi]
   [dmarc-sep dmarc-adkim]
   [dmarc-sep dmarc-aspf]
   [dmarc-sep dmarc-ainterval]
   [dmarc-sep dmarc-fo]
   [dmarc-sep dmarc-rfmt]
   [dmarc-sep dmarc-percent]
   [dmarc-sep]'
have dmarc-request as optional but in 6.3 it says that p is "required"

Then i did take a look at draft-ietf-dmarc-dmarcbis-07 and the problem is still 
there :

- dmarc-record dmarcbis-07 !
'darc-record= dmarc-version dmarc-sep *(dmarc-tag dmarc-sep)
 dmarc-tag   = dmarc-request /
   dmarc-test /
   dmarc-psd /
   dmarc-sprequest /
   dmarc-nprequest /
   dmarc-adkim /
   dmarc-aspf /
   dmarc-auri /
   dmarc-furi /
   dmarc-fo /
   dmarc-rfm'

Should be replaced by :

'dmarc-record= dmarc-version dmarc-sep dmarc-request dmarc-sep *(dmarc-tag 
dmarc-sep)
dmarc-tag   =  dmarc-test /
   dmarc-psd /
   dmarc-sprequest /
   dmarc-nprequest /
   dmarc-adkim /
   dmarc-aspf /
   dmarc-auri /
   dmarc-furi /
   dmarc-fo /
   dmarc-rfm'

Moreover, On rfc7489 the last "dmarc-sep" is optional meaning that for all txt 
records
such as the one for gmail.com"v=DMARC1; p=none; sp=quarantine; 
rua=mailto:mailauth-repo...@google.com; the system administrator must 
add a ";" at the end. To avoid this source of error i suggest to change 
the ABNF as :
dmarc-record = dmarc-version dmarc-sep dmarc-request *( dmarc-sep 
dmarc-tag ) [ dmarc-sep ]

- dmarc-fo dmarcbis-07 :
the rule '  dmarc-fo = "fo" *WSP "=" *WSP ( "0" / "1" / ( "d" / "s" / "d:s" / 
"s:d" ) )' does not allow the user to have both DMARC failure report
and DKIM/SPF failure report at the same time as '0:d', '1:d' is not allowed.

Best regards,

Olivier HUREAU
---
PhD Student
Laboratoire Informatique Grenoble - UGA - Drakkar
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc