[dmarc-ietf] Errata for Aggregate Reporting

[Brotman, Alex]

There were a few errata for the aggregate reporting.  I wanted to confirm with 
the list that these are still valid.

https://www.rfc-editor.org/errata/eid5440 :: I thought it had been determined 
the ";" was not necessary.

https://www.rfc-editor.org/errata/eid6485 :: We've since replaced this, so I 
don't believe this is relevant.

https://www.rfc-editor.org/errata/eid5774 :: There were a number of edits for 
clarification to this portion of the document.  The "otherwise specified" 
language is no longer there, and I believe all concerns have been addressed for 
this portion. 


Thanks folks.

-- 
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
 

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

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

[John Levine]

It appears that Murray S. Kucherawy   said:
>-=-=-=-=-=-
>
>This seems like it's probably legitimate.  Does it need to be fixed in the
>-bis document?

It's already fixed in the current markdown.

FYI, the XML pattern is silly.  It forbids harmless stuff like leading zeros in 
01.02.03.04
and doesn't allow some exotic but valid IPv6 forms like :::12.34.56.78.

It's not worth changing now, but when we do something like this in the
future it's more sensible to have a simpler over-general pattern and a
note saying it's semantically limited to valid values.


>
>-MSK
>
>-- Forwarded message -
>From: RFC Errata System 
>Date: Sat, Mar 23, 2024 at 8:04 AM
>Subject: [Technical Errata Reported] RFC7489 (7865)
>To: , , 
>Cc: , 
>
>
>The following errata report has been submitted for RFC7489,
>"Domain-based Message Authentication, Reporting, and Conformance (DMARC)".
>
>--
>You may review the report below and at:
>https://www.rfc-editor.org/errata/eid7865
>
>--
>Type: Technical
>Reported by: Fränz Friederes 
>
>Section: Appendix C
>
>Original Text
>-
>
>
>
>  
>
>  
>
>
>Corrected Text
>--
>
>
>
>  
>
>  
>
>
>Notes
>-
>The IPv4 regex contains a period "." that should be corrected to an escaped
>period "\." As stated in the follow up message of the one referenced in the
>IPv4 regex credit: "I just realized that there is a bug [...] The period
>(.) is a special character meaning 'any character'. To indicate that we
>want a period and not 'any character' the period must be escaped with a
>backslash, i.e., \." Following the XML schema provided in the original
>Appendix C, strings like "1a1a1a1" and "111" are considered valid IPv4
>addresses, although they are not usable.
>
>Instructions:
>-
>This erratum is currently posted as "Reported". (If it is spam, it
>will be removed shortly by the RFC Production Center.) Please
>use "Reply All" to discuss whether it should be verified or
>rejected. When a decision is reached, the verifying party
>will log in to change the status and edit the report, if necessary.
>
>--
>RFC7489 (draft-kucherawy-dmarc-base-12)
>--
>Title   : Domain-based Message Authentication, Reporting, and
>Conformance (DMARC)
>Publication Date: March 2015
>Author(s)   : M. Kucherawy, Ed., E. Zwicky, Ed.
>Category: INFORMATIONAL
>Source  : INDEPENDENT
>Stream  : INDEPENDENT
>Verifying Party : ISE & Editorial Board
>
>-=-=-=-=-=-
>[Alternative: text/html]
>-=-=-=-=-=-


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

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

[Matthäus Wander]

Murray S. Kucherawy wrote on 2024-03-23 19:04:
This seems like it's probably legitimate.  Does it need to be fixed in 
the -bis document?


It has been already fixed in aggregate-reporting:


  


Regards,
Matt

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

Re: [dmarc-ietf] Working Group Last Call on draft-ietf-dmarc-aggregate-reporting-14

[Matthäus Wander]

Brotman, Alex wrote on 2024-03-23 19:17:

Thanks for the feedback.  I believe I've corrected all except

- 2.1: "(...) while there MUST be one spf sub-element". At least one according to the XML Schema 
Definition (might be two, each with a different scope "helo" and "mfrom").

Can we talk about how this looks in a sample report?


Sure, sample follows. It's a rare sighting, but I believe it's valid.




195.201.14.36
3

none
pass
pass



wander.science
wander.science



wander.science
2023-05-rsa
pass
pass


wander.science
2023-05-ed25519
neutral
invalid (unsupported algorithm 
ed25519-sha256)


mail.swznet.de
helo
pass


wander.science
mfrom
pass





Regards,
Matt

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

Re: [dmarc-ietf] Working Group Last Call on draft-ietf-dmarc-aggregate-reporting-14

[Brotman, Alex]

Thanks for the feedback.  I believe I've corrected all except

- 2.1: "(...) while there MUST be one spf sub-element". At least one according 
to the XML Schema Definition (might be two, each with a different scope "helo" 
and "mfrom").

Can we talk about how this looks in a sample report? 

-- 
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
 

> -Original Message-
> From: dmarc  On Behalf Of Matthäus Wander
> Sent: Thursday, March 21, 2024 6:23 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Working Group Last Call on 
> draft-ietf-dmarc-aggregate-
> reporting-14
> 
> Barry Leiba wrote on 2024-02-29 16:03:
> > This document is also ready for our final look, so this message starts
> > a working group last call for the aggregate reporting document, with
> > the same timing as for the DMARC spec.
> >
> > 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.
> 
> Editorial and nits:
> 
> - Would it be useful to add a reference to dmarc-bis?
> - 2.1: Bullet point "A separate report should be generated (...)"
> appears to be a requirement, not an enumeration of data included in the 
> report.
> - 2.1: Bullet point "The DMARC policy discovered and applied, if any" is 
> redundant
> with "The policy requested by the Domain Owner and the policy actually applied
> (if different)".
> - 2.1: Write out "IP" as "IP address".
> - 2.1: The terminology of having two sections and two subsections may be
> misleading, as this is not reflected in the XML structure. Suggestion:
> replace "subsection" with "element", which is a term used in XML.
> - 2.1: "In most cases, this will be a header_from element, which will contain 
> the
> 5322.From domain from the message." Add: "There may be an envelope_from
> element, which contains the RFC5321.MailFrom domain."
> - Multiple instances: Replace "5322.From" with "RFC5322.From".
> - 2.1: "the 'record' element". Only instance where the element name is 
> enclosed
> in quotes.
> - 2.1: "(...) while there MUST be one spf sub-element". At least one 
> according to
> the XML Schema Definition (might be two, each with a different scope "helo" 
> and
> "mfrom").
> - 2.1: "(...) the value is one of
> none/neutral/pass/fail/softfail/temperror/permerror." Would it make sense to
> add a reference to RFC 8601?
> - 2.1.3: "Specified below, the reader will see a msg-id, Report-ID, 
> unique-id." msg-
> id is not specified below. "5322.Message-Id" is briefly mentioned in 2.6.2.
> - 2.3: "(...) regardless of any requested report interval." The report 
> interval (ri tag)
> has been removed from dmarc-bis.
> - 2.6: "Any reporting URI that includes a size limitation exceeded by the 
> generated
> report (...) MUST NOT be used." The size limitation has been removed from
> dmarc-bis. However, leaving the text as-is offers the option to re-introduce 
> a size
> limitation in future URI schemes.
> - 2.6: "(...) the Mail Receiver MAY send a short report (see Section 7.2.2)"
> Dangling reference: error reports have been removed.
> - 2.6.2: "This transport mechanism potentially encounters a problem when
> feedback data size exceeds maximum allowable attachment sizes for either the
> generator or the consumer. See Section 7.2.2 for further discussion." Dangling
> reference.
> - 3: "(...) after conversion to an A-label if needed." Add reference to 
> definition of
> an A-label. Dmarc-bis references Section 2.3 of [RFC5890].
> - 3: "the same overall format as the policy record (see Section 5.3)."
> Section 5.3 (or 5.4) of dmarc-bis.
> - 8: "report_id: UUID, specified elsewhere". Change to: "report_id:
> Unique Report-ID".
> - 8: "error: ?". Change to: "error: Optional error messages when processing
> DMARC policy".
> - 8: "The percent declared in the DMARC record". Change to: "Whether testing
> mode was declared in the DMARC record."
> - 9: The policy_evaluated in the sample report evaluates to pass,
> but still results in quarantine. Is that an 
> adequate
> example?
> Suggestion: change to pass.
> 
> Regards,
> Matt
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!C
> Ql3mcHX2A!Bnuiz20ACdarSauiLSk8IQ3CRyWbItwpq20m0AgtFVIA2mRNyWeQMb
> -h_WUJsrvmtSbtJROBvnxFUdm0-HW0MvTSHXxGxoFC-BA$
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

This seems like it's probably legitimate.  Does it need to be fixed in the
-bis document?

-MSK

-- Forwarded message -
From: RFC Errata System 
Date: Sat, Mar 23, 2024 at 8:04 AM
Subject: [Technical Errata Reported] RFC7489 (7865)
To: , , 
Cc: , 


The following errata report has been submitted for RFC7489,
"Domain-based Message Authentication, Reporting, and Conformance (DMARC)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7865

--
Type: Technical
Reported by: Fränz Friederes 

Section: Appendix C

Original Text
-



  

  


Corrected Text
--



  

  


Notes
-
The IPv4 regex contains a period "." that should be corrected to an escaped
period "\." As stated in the follow up message of the one referenced in the
IPv4 regex credit: "I just realized that there is a bug [...] The period
(.) is a special character meaning 'any character'. To indicate that we
want a period and not 'any character' the period must be escaped with a
backslash, i.e., \." Following the XML schema provided in the original
Appendix C, strings like "1a1a1a1" and "111" are considered valid IPv4
addresses, although they are not usable.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
will log in to change the status and edit the report, if necessary.

--
RFC7489 (draft-kucherawy-dmarc-base-12)
--
Title   : Domain-based Message Authentication, Reporting, and
Conformance (DMARC)
Publication Date: March 2015
Author(s)   : M. Kucherawy, Ed., E. Zwicky, Ed.
Category: INFORMATIONAL
Source  : INDEPENDENT
Stream  : INDEPENDENT
Verifying Party : ISE & Editorial Board
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Security Considerations in aggregate-reporting

[Brotman, Alex]

Thanks, added as a list

-- 
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
 

> -Original Message-
> From: dmarc  On Behalf Of Matthäus Wander
> Sent: Friday, March 22, 2024 7:15 PM
> To: dmarc@ietf.org
> Subject: [dmarc-ietf] Security Considerations in aggregate-reporting
> 
> The Security Considerations section of aggregate-reporting-14 currently 
> consists
> of a placeholder. Suggested text follows.
> 
> 7. Security Considerations
> 
> Aggregate reports are supposed to be processed automatically. An attacker 
> might
> attempt to compromise the integrity or availability of the report processor by
> sending ill-formed reports. In particular, the archive decompressor and XML
> parser are at risk to resource exhaustion attacks (zip bomb or XML bomb).
> 
> The data contained within aggregate reports may be forged. An attacker might
> attempt to interfere by submitting false reports in masses.
> 
> See also the security considerations of [dmarc-bis] (Section 11).
> 
> Regards,
> Matt
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!C
> Ql3mcHX2A!DFefgrWpAI8yZl-vaXTMNo-
> w25DyauJ5lIv7PgXtLK8GuOehfQXU0cRr94m41JRipIHn7C-
> myd1B9T5zxeCUhXOszRZMN0b3Z6SfZIb4$

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

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

[Matthäus Wander]

Alessandro Vesely wrote on 2023-11-17 10:22:

On Thu 16/Nov/2023 16:47:48 +0100 Olivier Hureau wrote:
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.



That's right.  The only mention is in Appendix B. Sample Report, saying 
1.0.


[...]

The IETF XML Registry is defined by RFC 3688.[*]  IANA is supposed to 
insert our "dmarc-2.0" per IANA Considerations section.  Referencing 
that schema in the feedback element identifies the format more clearly 
than a version number. However, Matt suggested to keep  for 
compliance with RFC 7489[†].  In that case, is it correct to stick to 1,0?



[*] https://www.iana.org/assignments/xml-registry/xml-registry.xhtml
[†] https://mailarchive.ietf.org/arch/msg/dmarc/JdRxmT9Aw3HkWM7rr3Av9B3EwRc


Speaking from today, I think the presence or content of the  
field does not really matter. The "dmarc-2.0" XML schema declares it 
optional, which is probably the best choice.


In my data, 75% of reporters announce 1.0. They can 
continue to do so. Dave Crocker has argued that bumping the version 
number is of no use:



Omitting the  field might confuse the statistics of report 
analyzers, but most likely won't do any harm.


Regards,
Matt

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