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

[Matthäus Wander]

OLIVIER HUREAU wrote on 2024-04-02 18:41:

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


[...]


NEW
```

  
   
   
   
   
   
   
  

```


For the sake of consistency, either remove maxOccurs from each element 
under  or set maxOccurs="1" for each.


Regards,
Matt

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

Re: [dmarc-ietf] Aggregate Report Statistics

[Matthäus Wander]

Seth Blank wrote on 2024-03-28 02:09:
What is your point / the information you find relevant here to WGLC of 
the bis project?


To me, the data confirms that the schema matches with how the reports 
are being sent in practice. This includes in part the lesser known 
fields, which are all being utilized, except for the error field in my data.


The support for a DKIM none seems unnecessary to me and 
introduces two ways of encoding the same information. But as people are 
using it, so be it.


It's worth mentioning that the pre-RFC7489 schema is still being used 
and won't go away anytime soon.


I also find it interesting that the org_name is often being used as 
hostname, which for larger service providers can lead to dozens or 
hundreds of separate, deaggregated report sources.


We do many times this volume in a single day and are happy to share top 
line stats.


Do you have an indication what the error field is being used for, if at all?

Regards,
Matt

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

[dmarc-ietf] Aggregate Report Statistics

[Matthäus Wander]

Here is an evaluation of 84k aggregate reports in the timespan of 2020-2024.

  481 reporting organizations
  derived from 896 distinct  strings
  ---+---
   44 use Organization Names ("Example")
with min=1, median=1.0, mean=1.11, max=3 distinct names
  344 use Organizational Domains only ("example.net")
with min=1, median=1.0, mean=1.05, max=10 distinct domains
   93 use Hostnames and Domains ("mx1.example.net")
with min=1, median=2, mean=5.23, max=315 distinct hosts
  ---+---
  364 report version
2 report version__other
0 report meta_error
  450 report sp
  340 report sp__empty
   39 report fo__v1
0 report fo__v1empty
   69 report override_reason
   21 report envelope_to
  354 report envelope_from__v1
  119 report envelope_from__v1empty
   18 report envelope_from__v1missing
3 report dkim_selector__empty
   94 report dkim_selector__missing
   18 report dkim_result__none
   19 report dkim_human_result
   17 report dkim_human_result__copy
  357 report spf_scope__v1
  ---+---
Human-comprehensible result:
- 76% (364/481) of reporters announce the use of the RFC 7489 
1.0 schema.

- No one seems to use  below .
- 71% (340/481) report an empty  instead of the default value.
- 11% (39/364) of 1.0 reporters include the  element, although it's 
actually mandatory. Draft schema does not have .


:
-  4% (21/481) use .
- 97% (351/364) of 1.0 reporters use . Draft schema does 
not have .
- 33% (119/364) have used an empty  (i.e., reported a 
bounce) at least once.
-  5% (18/364) have omitted  at least once, even though 
it is mandatory in 1.0.
- The remaining 62% either did not receive a bounce or do not report 
bounces.


:
- 20% (94/481) have omitted the optional  in a DKIM result at 
least once.
-  4% (18/481) have reported a DKIM none, even though 
they could've instead omit the  element altogether.
-  4% (19/481) have used the DKIM , but only 2 used it for 
extra information that was not just a copy of .


Regards,
Matt

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

Alessandro Vesely wrote on 2024-03-27 10:00:
I changed that to /[0-9a-fA-F.:]{2,45}/, to allow "::", and inserted it 
in dmarc-xml-0.2-short.xsd[*].  At the same time, I added a pattern for 
"::1.2.3.4" in dmarc-xml-0.2.xsd[†].


I can live with either of these variants.

I'm not clear what will that schema be used for, if at all.  Personally, 
the only reason why I'd prefer the long regex is because it might have 
some value by itself.  The short one is cleaner and more grokkable.  The 
wrong one has none of those qualities.


I see the following use cases for the schema (sorted from most to least 
important):


1) Provide a precise description to implementers (of both report senders 
and receivers) how a report should look like.


2) Allow report senders to verify the correctness of their implementation.

3) Allow report receivers to perform input validation before ingesting a 
report.


Regards,
Matt

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

Alessandro Vesely wrote on 2024-03-26 19:30:
No.  To take several years and come up with a syntax which does not 
cover all valid addresses is a sign of incompetence that this WG doesn't 
deserve, IMHO. What do others think?


Let's rather switch to /[0-9a-fA-F.:]+/.  Terse and correct.


I'm in favor of a brief and coarse regex, which is suitable for 
detecting obvious junk. The above proposal looks good enough to me. I 
wouldn't mind adding an outer bounds check, e.g.: [0-9a-fA-F.:]{3,45}


If an implementer sees merit in a comprehensive syntax check, they can 
add one to their software.


Regards,
Matt

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

[dmarc-ietf] Security Considerations in aggregate-reporting

[Matthäus Wander]

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://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Policy Override in aggregate-reporting

[Matthäus Wander]

RFC7489 contains a description of the possible PolicyOverrideType 
values: 


While aggregate-reporting-14 uses the same set of values, the 
description is missing. I suggest to add it back as a new section into 
the main body. "sampled_out" needs an update due to the replacement of 
the "pct" tag. Text suggestion follows.


OLD 2.1.1
There MAY be an element for reason, meant to include any notes the 
reporter might want to include as to why the disposition policy does not 
match the policy_published, such as a Local Policy override (possible 
values listed in Appendix A).


CHANGED 2.1.1
There MAY be an element for reason, meant to include any notes the 
reporter might want to include as to why the disposition policy does not 
match the policy_published, such as a Local Policy override (see Section 
2.1.5).


NEW 2.1.5 Policy Override Reason

The reason element, indicating an override of the DMARC policy, consists 
of a mandatory type field and an optional comment field. The type field 
MUST have one of the pre-defined values listed below. The comment field 
is an unbounded string for providing further details.


Possible values for the policy override type:

   forwarded:  The message was relayed via a known forwarder, or local
  heuristics identified the message as likely having been forwarded.
  There is no expectation that authentication would pass.

   local_policy:  The Mail Receiver's local policy exempted the message
  from being subjected to the Domain Owner's requested policy
  action.

   mailing_list:  Local heuristics determined that the message arrived
  via a mailing list, and thus authentication of the original
  message was not expected to succeed.

   other:  Some policy exception not covered by the other entries in
  this list occurred.  Additional detail can be found in the
  PolicyOverrideReason's "comment" field.

   sampled_out:  The message was exempted from application of policy by
  the testing mode ("t" tag) in the DMARC policy record.

   trusted_forwarder:  Message authentication failure was anticipated by
  other evidence linking the message to a locally maintained list of
  known and trusted forwarders.

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]

Matthäus Wander wrote on 2024-03-21 23:23:
- 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."


This paragraph could use some more explanation. The following text 
proposal is consistent with the XML schema in the appendix and with 
actual reports received.


OLD:
Within the identifiers element, there MUST exist the data that was used 
to apply policy for the given IP. In most cases, this will be a 
header_from element, which will contain the 5322.From domain from the 
message.


NEW:
Within the identifiers element, there MUST exist the data that was used 
to apply policy for the given IP address. There MUST be a header_from 
element, which will contain the RFC5322.From domain from the message. 
There MAY be an optional envelope_from element, which contains the 
RFC5321.MailFrom domain or the RFC5321.Helo domain that the SPF check 
has been applied to. This element MAY be existing but empty if the 
message had a null reverse-path ([RFC5321], Section 4.5.5). There MAY be 
an optional envelope_to element, which contains the RFC5321.RcptTo 
domain from the message.


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]

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://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC result for DKIM testing and policy

[Matthäus Wander]

Alessandro Vesely wrote on 2024-03-20 15:42:

what is the result of DMARC on having, say

     dkim=pass (testing key)
or
     dkim=policy (512 byte key)

is that akin to SPF neutral, i.e. dmarc=fail?


dkim=pass results in dmarc=pass (if the domain is aligned). The comment 
in brackets is for human eyes and does not change the DMARC result.


dkim=policy is like spf=neutral, i.e. dmarc=fail.

Regards,
Matt

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

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

[Matthäus Wander]

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

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

[Matthäus Wander]

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 )


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.


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.


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.


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


Regards,
Matt

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

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

[Matthäus Wander]

Murray S. Kucherawy wrote on 2023-10-20 21:35:
(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?


I'm a strong proponent of including human-understandable error messages 
in DMARC reports. More than once, I puzzled over whether the outgoing 
message stream or the report sender is broken.


In the above case, the already existing (but not prominently known) 
optional  field in the  section can be used to 
include an error message, e.g., "syntax error in sp tag".


Text suggestion:
The Mail Receiver MAY utilize the optional "error" field in aggregate 
reports to announce syntax errors identified in the DMARC policy record.


Regards,
Matt

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

[Matthäus Wander]

OLIVIER HUREAU wrote on 2023-07-24 11:20:

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


[...]

According to XML definitions, the position cannot be swapped and 
theDKIMAuthResultType (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 
where
 SPFAuthResultType appears before DKIMAuthResultType.

Are you talking about the same error?


Good catch. These are two different issues, though.

In the issue I mentioned, the mail receiver performs DMARC validation 
and sends an aggregate report, but does not perform DKIM verification 
even though the mail has a DKIM-Signature.


I think the following screenshot offers an explanation of what causes 
the issue:


The admin GUI of a mail gateway offers the option to deactivate DKIM 
verification (next to DKIM signing), thus some people click it by 
accident or by lack of understanding. Not an issue that can be fixed by 
the DMARC spec.


Regards,
Matt

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

[Matthäus Wander]

Murray S. Kucherawy wrote on 2023-07-24 00:10:
On Sun, Jul 23, 2023 at 1:06 PM Matthäus Wander 
<mailto:40wander.scie...@dmarc.ietf.org>> wrote:


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.


Why is the signer claiming to sign a header field ("Date", in this case) 
that isn't there?  This seems like a bug.


The signer uses a fixed set of header fields to sign, which usually 
exist or should be oversigned if nonexistent (one size fits most). The 
signer is not tailored towards this specific mail source. But yes, it's 
a bug in the system.


Regards,
Matt

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

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

[Matthäus Wander]

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

Re: [dmarc-ietf] Another p=reject text proposal

[Matthäus Wander]

Murray S. Kucherawy wrote on 2023-07-08 02:44:
"SHOULD" leaves the implementer with a choice.  You really ought to do 
what it says in the general case, but there might be circumstances where 
you could deviate from that advice, with some possible effect on 
interoperability.  If you do that, it is expected that you fully 
understand the possible impact you're about to have on the Internet 
before proceeding.  To that end, we like the use of SHOULD [NOT] to be 
accompanied by some prose explaining when one might deviate in this 
manner, such as an example of when it might be okay to do so.


The elaborated Interoperability Considerations in Barry's proposal gives 
the implementer guidance to understand the impact. In my understanding, 
SHOULD is ought to be followed, unless the implementer has good reasons 
not to. The burden of justification is on the implementer, not on the spec.


Does anyone have such an example in mind that could be included here?  
Specifically: Can we describe a scenario where (a) a sender publishes 
p=reject (b) with users that post to lists (c) that the community at 
large would be willing to accept/tolerate?


The scenario I have in mind is a business domain with a high demand for 
protection from exact domain spoofing and a low to no demand for list 
communication. Note the wording in Barry's proposal: "users who *might* 
post messages to mailing lists" (not: "users that post to lists").


I wouldn't include such an example in the RFC, because I don't see a 
discussion to this extent for any of the other SHOULD requirements in 
the document.


Regards,
Matt

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

Re: [dmarc-ietf] [EXTERNAL] Re: I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt

[Matthäus Wander]

On Tue 25/Apr/2023 21:08:56 +0200 John R Levine wrote:
Looks mostly good to me.  By the way, that bit about a malicious 
Doamin Owner is not hypothetical, and I don't think I'm malicious.  
Just make it A Domain Owner ...


Agreed, just Domain Owner then.

Alessandro Vesely wrote on 2023-04-26 09:25:
No, wait.  Domain owners can only add something when users posts via 
their domain's MSAs.  In that case, the information that can be gathered 
by aggregate reports is a blurred image of what can be obtained from 
internal logs.  One can find out who is using external MSAs by matching 
connections in small domain to small domain correspondence only.


The Domain Owner may not learn anything new by putting in tracking IDs 
into messages, but the privacy leak creeps into the aggregated report 
and becomes visible to third-party report processors or organizational 
units that have access to the rua mailbox but not the internal logs.


Regards,
Matt

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt

[Matthäus Wander]

Scott Kitterman wrote on 2023-04-26 21:05:

I think if a non-encrypted transport is used there's a privacy issue with 
sending the report.  I think that's one approach.

Currently we have nothing about it in any document.  I think the latest 
revision introduced an undocumented privacy issue.  I'm less bothered about how 
we document it than that it be documented in some manner.

I think it's about sending a report, so the reporting document makes sense as 
the place to document it.  I think the easiest way to do so is just put the old 
text back, but I'm open to alternatives.


Are you asking to enforce TLS on the reporter side or does opportunistic 
TLS suffice?


I interpreted the requirement as: SHOULD employ a secure transport 
mechanism, *if supported by the report receiver*.


Regards,
Matt

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

Re: [dmarc-ietf] [EXTERNAL] Re: I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt

[Matthäus Wander]

Brotman, Alex wrote on 2023-04-25 19:32:

I'm not disagreeing with the idea below, just that by omitting this in the 
draft, we could leave it open to interpretation that it *always* will be a 
privacy violation.  This could justify decisions by some receivers to decline 
to send reports.

Otherwise, I'll remove 6.3.


I see some merit in 6.3 by pointing out what is *not* included in a 
report and that the identifiers disclosed are on domain level. The 
wording "Mail Receivers / Domain Owners should have no concerns in ..." 
is not optimal. Let's leave that to them to decide.


I suggest to merge those parts of 6.3 into 6.1. Proposed text:

6.1.  Data Exposure Considerations

   Aggregate reports are limited in scope to DMARC policy and
   disposition results, to information pertaining to the underlying
   authentication mechanisms, and to the domain-level identifiers
   involved in DMARC validation.

   Aggregate reports may expose sender and recipient identifiers on
   domain level, specifically the RFC5322.From domain.  No personal
   information such as individual email addresses, IP addresses of
   individuals, or the content of any messages, is included in reports.
   However, low-traffic reports may allow a mapping of 'record' elements
   to individuals due to a lack of aggregated data.  A malicious Domain
   Owner might add a unique user identifier to messages (e.g., as DKIM
   selector) that allows a tracking of individual users in aggregate
   reports.

   [remaining section unchanged]

Regards,
Matt

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

[dmarc-ietf] General-purpose domains with users from the general public MUST NOT use p=reject

[Matthäus Wander]

Barry Leiba wrote on 2023-04-14 03:52:

As to "what constitutes general purpose", if you are providing email
addresses to the general public, that qualifies.  If your domain is
sending email only from employees, and you have policies about
employees using their email addresses to conduct business, then that's
a different issue.  Of course, if their business involves posting to
mailing lists, you have some decisions to make.


How about this?

   5.5.6.  Decide If and When to Update DMARC Policy

   Once the Domain Owner is satisfied that it is properly authenticating
   all of its mail, then it is time to decide if it is appropriate to
   change the p= value in its DMARC record to p=quarantine or p=reject.
   Depending on its cadence for sending mail, it may take many months of
   consuming DMARC aggregate reports before a Domain Owner reaches the
   point where it is sure that it is properly authenticating all of its
   mail, and the decision on which p= value to use will depend on its
   needs.

   It is important to understand that the Domain Owner may never use
   a policy of p=quarantine or p=reject, and that these policies are
   intended not as goals, but as policies available for use when they
   are appropriate.  In particular, domains with users from the general
   public, where the Domain Owner has no overview about and no
   intention to govern with who their users communicate with, MUST NOT
   deploy a policy of p=reject to preserve interoperability.  In such
   scenarios, the deployment of a policy other than p=none can disrupt
   indirect mail flows and cause damage to the operation of mailing
   lists and other forwarding services that are incompatible with
   DMARC.  This is discussed in [RFC7960] and in Section 5.8, below.

Regards,
Matt

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Matthäus Wander]

John Levine wrote on 2023-04-09 15:55:

When someone sets a DMARC policy for mail from people, it's hard to
think of a time when they asked at wll whether that was what the
people wanted. Or if they did, they asked something like "do you want
your mail to be more secure?" which misses the point.


A domain owner can set their policy without asking their users for 
permission. Not every sender with mail from people is a mail service 
provider catering to the general public.



PS: I can make anyone's mail 100% secure by unplugging your mail
server but I'm pretty sure that's not what you want.


You can also ensure interoperability by demanding they MUST NOT use any 
type of authentication, because all it does is impairing mail flows, 
while the security benefit is nothing that IETF standards should mandate 
about.


Neither of these extremes is helpful to actually achieve 
interoperability or security.


Regards,
Matt

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Matthäus Wander]

Murray S. Kucherawy wrote on 2023-04-09 09:50:
Since one of the IETF's main goals in producing a technical 
specification is interoperability, and since improperly deployed 
"p=reject" results in the very essence of non-interoperability in the 
deployed email base, I'm having trouble imagining why the standard 
should leave operators with any choice here.  That is, in direct reply 
to the cited definition of "SHOULD NOT", I claim there do not exist 
valid reasons in particular circumstances when the particular behavior 
is acceptable, even when the full implications are understood and the 
case carefully weighed.


Earlier in the discussion, the term high-value domain has been used 
(along with transactional email domain) in opposition to domain for 
general-purpose email. The proposed text leaves it to the discretion of 
the domain owner to decide whether they have a general-purpose email 
domain or, say, a special-purpose business domain with a high need for 
protection from email spoofing. The risks are outlined, thus enabling 
the domain owner to weigh the implications, and the proposed text 
acknowledges that ...


> ... the decision on which p= value to use will depend on its needs.

Isn't that having a choice?

Regards,
Matt

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-03.txt

[Matthäus Wander]

Scott Kitterman wrote on 2021-08-26 17:41:

Why would a report be sent more than once?


Happens regularly with Google as reporter. Seems to be a design choice.


Other than error cases, the only thing I can immediately think of is the case 
where the report was sent, but the SMTP session doesn't properly terminate so 
it's unknown if they entire report was received.

Which leaves me wondering what the receive side processing should be?



Should partial reports be discarded? (draft is silent on this)


CRC would break with compressed files in this case, i.e. the report 
would be clearly invalid.


If the reporter generates a partial report but with valid syntax, then 
the report consumer will have no way to detect it. Re-sending the full 
report may fix the issue (if the consumer implements an overwrite logic) 
or make it worse (if the consumer doesn't deduplicate).



If a complete message has been received, then I think deduplicating based on 
the Report-ID makes sense (don't have to open up the MIME parts to do it).


Yes.


It's not clear to me from skimming the draft if one message can have multiple 
XML files or not (I'm less familiar with the details of the feedback part of 
DMARC).  If there can be only one, that's probably sufficient.  If there can be 
more than one, then there may be a case where one file was successfully 
received and stored, but another wasn't.  In this case, you would need to 
examine the MIME parts, so filename consistency would be important.


The definition of one Report-ID in the subject line implies that a 
message carries no more than one report. This could be clarified in the 
RFC, though.


Regards,
Matt

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-03.txt

[Matthäus Wander]

Alessandro Vesely wrote on 2021-08-19 13:18:

I'd swap SHOULD and MUST between the following sentences:

     If a report generator needs to re-send a report, the system
     SHOULD use the same filename as the original report.


The paragraph is justified by deduplication:

   If a report generator needs to re-send a report, the system SHOULD
   use the same filename as the original report.  This would allow the
   receiver to overwrite the data from the original, or discard second
   instance of the report.

But this works only if the sender ensures to leave the filename 
unchanged. So it's either a MUST or the paragraph can be omitted altogether.



and

     The RFC5322.Subject field for individual report submissions
     MUST conform to the following ABNF:

For the subject, alternatively, "Report-Id" msg-id could be optional, as 
it is with the filename.  It is very noisy and doesn't seem to be much 
useful if it doesn't match the filename, let alone its uniqueness.


The Report-ID is also justified by deduplication:

   The purpose of the Report-ID: portion of the field is to enable the
   Domain Owner to identify and ignore duplicate reports that might be
   sent by a Mail Receiver.

1. So Report-ID is either a MUST to allow deduplication,
2. or Report-ID is not required for deduplication,
(In the filename it's optional, but the filename has a mandatory time 
range, which the subject has not. Deduplication requires one of these 
two information. You might use the RFC5322.Date, but this introduces 
another dependency.)

3. or deduplication via subject is not supposed to be supported.
Is there another use case for a formal ABNF spec of the subject?

Regards,
Matt

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

Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99

[Matthäus Wander]

Alessandro Vesely wrote on 2021-07-21 19:41:
Some lists operate the evasion hack, a.k.a. From: munging, only if the 
sender has p=quarantine or p=reject, some do it unconditionally, some 
only if the mail is outbound, some only if the receiver is mail.ru.  
Behavior doesn't seem to be settled yet.


We should add a section on From: munging in the spec.


It's explained as mitigation in RFC7960:


What's seems to be missing is a recommendation to not change DMARC 
validation behavior subject to p= or other conditions. A conditional 
validation makes p=none less useful for monitoring of potential delivery 
problems.


Regards,
Matt



smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[Matthäus Wander]

Alessandro Vesely wrote on 2021-06-04 11:26:
Second, I'm not sure we need an  container.  
I'd go for an example like, say, so:


[...]
    xmlns="http://ietf.org/xml-namesapaces/bimi-xml?/1.0;>

> [...]
   xmlns="http://ietf.org/xml-namesapaces/bimi-xml??/1.0;>


If we use an attribute for the extension name, then we don't the 
container section.
As the current schema does not use attributes at all, I'm more inclined 
to define the extension name in a different way for consistent non-use 
of attributes. But that's a minor detail.


1) Extensions in their own section (as it is now) or within each  
element



Both, and both optional.  An extension can have some data to add in some 
, but not necessarily in all of them.


+1

Regards,
Matt



smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[Matthäus Wander]

ARC shows the need for extension data within  elements:


Example from RFC 8617:

 none
 fail
 fail
 
  local_policy
  arc=pass as[2].d=d2.example as[2].s=s2
as[1].d=d1.example as[1].s=s3
remote-ip[1]=2001:DB8::1A
 


With proper extension support, this example could look like this:

  
none
fail
fail

  extension
  arc=pass

  

...

  
pass

  
2
d2.example
s2
  
  
1
d1.example
s3
2001:DB8::1A
  

  


An IANA registry could serve as repository of IETF-approved extensions.

It's worth considering whether certain elements should be defined as 
extensible. In the above example, the  element could be placed 
below  next to the existing  and  elements. 
Implementations support this behavior by simply ignoring unknown 
elements. XML Schema supports extensibility in well-defined places with 
the  element.


Regards,
Matt

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

Re: [dmarc-ietf] Tranco Toplist?

[Matthäus Wander]

Todd Herr wrote on 2021-05-21 22:56:
I'm seeing recent comments on a number of tickets attributed to "mail at 
wander dot science" and referencing something called "Tranco Toplist".


That's me.

Tranco is a list of most popular web sites (similar to the Alexa 1M Top 
Sites): 
I've queried the top 1M Tranco domains for their _dmarc DNS record, 
which resulted in 152k records with "v=DMARC1".


Regards,
Matt

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

Re: [dmarc-ietf] [EXTERNAL] DMARC XML grammar

[Matthäus Wander]

Here's some data that might be helpful to consider.
Data comprises about a year of reports for one domain.

  229 reporting organizations
  derived from 369 distinct  strings
  ---+---
   20 use Organization Name ("Example")
  161 use Organizational Domain only ("example.net")
   48 use Hostnames ("mx1.example.net", ...)
with min=1, median=1.0, mean=3.92, max=116 distinct hostnames
  ---+---
  193 report version
0 report meta_error
  227 report sp
  179 report sp__empty
   20 report fo__v1
0 report fo__v1empty
6 report override_reason
   12 report envelope_to
  191 report envelope_from__v1
   41 report envelope_from__v1empty
6 report envelope_from__v1missing
0 report dkim_selector__empty
   25 report dkim_selector__missing
7 report dkim_result__none
   10 report dkim_human_result
9 report dkim_human_result__copy
  191 report spf_scope__v1

Human-comprehensible result:
- 84% (193/229) of reporters announce the use of the RFC 7489
1.0 schema.
- No one uses  below .
- 78% (179/229) report an empty  instead of the default value.
- 10% (20/193) of 1.0 reporters include the  element, although it's
actually mandatory. Draft schema does not have .

:
-  5% (12/229) use .
- 99% (191/193) of 1.0 reporters use . Draft schema does
not have .
- 21% (41/193) have used an empty  (i.e., reported a
bounce) at least once.
-  3% (6/193) have omitted  at least once, even though
it is mandatory in 1.0.
- The remaining 75% either did not receive a bounce or do not report
bounces.

:
- 11% (25/229) have omitted the optional  in a DKIM result.
-  3% (7/229) have reported a DKIM none, even though
they could've instead omit the  element altogether.
-  4% (10/229) have used the , but only 1 used it
for extra information that was not just a copy of .

Regards,
Matt

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

Re: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)

[Matthäus Wander]

Alessandro Vesely wrote on 2021-05-14 20:12:
> In my tiny MX I have a cache of 631 aggregate reports received
> recently.  121 reports from 31 unique org_names have a /feedback/version
> element, 510 from 37 organizations don't.  The latter group includes
> google.com, Yahoo! Inc., Verizon Media, Mail.Ru, ...

In my data, 84% (193/229) of reporters announce 1.0.
16% of reporters omit the version and seem to use the pre-IETF draft schema.

Regards,
Matt

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

Re: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)

[Matthäus Wander]

Alessandro Vesely wrote on 2021-05-10 18:29:
> On Mon 10/May/2021 17:28:20 +0200 Dave Crocker wrote:
>> If an new spec merely /adds/ to a previous spec, then the presence of
>> the new constructs is self-declaring.  The only requirement is to have
>> the base specification declare that unrecognized constructs are to be
>> ignored.  So, versioning adds the illusion of utility, but really only
>> adds unnecessary complexity.
> 
> 
> I think the format we'll end up with will be pretty compatible with the
> existing practice, meaning that existing report consumers that use a
> proper XML parser and ignore unknown tags can work unchanged.  I don't
> think any consumer parses reports "by hands".

Alright, introducing incompabilities is off the table and backward
compability is a must. This brings #51 into question, which may affect
backward compability.
https://trac.ietf.org/trac/dmarc/ticket/51


Regarding the existing top-level  below :
Even if parsers don't require the version to function, it remains useful
for measuring the adoption of the different DMARC specifications (as
requested in #70). In fact, one implementation I looked at (parsedmarc)
uses it for only this purpose. A missing  is logged as "draft"
schema version.


Regarding the XML namespace declaration:
The XML schema serves not only as specification for developers, but can
be also used for automatic syntax checks of reports -- provided that the
namespace declaration is fixed. XSD validation is an immensely useful
tool for testing the output of report generators. It helped me to
discover two nasty bugs in an implementation, which appeared in 2 out of
~10k reports and would have gone unnoticed otherwise.
A version number within the schema is not necessary for this use case.

A different matter is whether automatic XSD validation on the report
consumer side is a supported use case. There is some value in it: two
lines of code suffice to perform input validation. However, the
validation is strict and does not allow for being liberal in what you
accept (might be handy for protocol police, though). Achieving upward
compatibility is not trivial, because there is no general "ignore all
unknown elements" statement in XSD. It is possible to define a 
placeholder in the schema, but this element must be inserted explicitly
into each place where extensibility is desired. This would require
careful foresight in the schema design.

Regards,
Matt

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

Re: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)

[Matthäus Wander]

John Levine wrote on 2021-05-10 17:21:
> It appears that Matthäus Wander  said:
>> 1) #33 suggests to add a versioned XML namespace declaration in the root
>>  element.
>> https://trac.ietf.org/trac/dmarc/ticket/33
>>
>> I support the use of the namespace declaration. 
> 
> 
>> 4) How does the report generator know which format version the consumer
>> supports?
> 
> It doesn't.  If we change the schema, a lot of report parsers will break.  
> What actual
> real world problem does this change solve?

The schema is broken already. See:
https://trac.ietf.org/trac/dmarc/ticket/44
https://trac.ietf.org/trac/dmarc/ticket/45
https://www.uriports.com/blog/dmarc-reports-ietf-rfc-compliance/

The point is to fix the schema.

> I haven't seen a lot of ill-formed reports.

You obviously haven't tried XSD validation.

Regards,
Matt

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

[dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)

[Matthäus Wander]

1) #33 suggests to add a versioned XML namespace declaration in the root
 element.
https://trac.ietf.org/trac/dmarc/ticket/33

I support the use of the namespace declaration. A report with namespace
declaration allows for automatic syntax checks with XML Schema
Validation. XSD validators refuse to work without the declaration. It
should be added to the examples in the I-D.

Example report:
  http://dmarc.org/dmarc-xml/0.2;>
  ...
  

A shorter variant is possible if we change the schema slightly:
  http://dmarc.org/dmarc-xml/0.2;>
  ...
  

Adapted schema with elementFormDefault:
  http://www.w3.org/2001/XMLSchema;
targetNamespace="http://dmarc.org/dmarc-xml/0.2;
xmlns="http://dmarc.org/dmarc-xml/0.2;
elementFormDefault="qualified">

Nit: I'd use 2.0 instead of 0.2.

2) #33 goes further and suggests to remove the  tag below
, because it is redundant with the namespace declaration.

I wouldn't recommend the removal. RFC 7489 has introduced tag
1.0 and existing implementations will rely on its
existence. Without , chances are the report consumer interprets
the report as pre-IETF draft version.

3) #70 introduces a new  field, but this one is below
 and seems to have the purpose to inform about which
DMARC standard has been used for validation.
https://trac.ietf.org/trac/dmarc/ticket/70

Is it useful to announce separate version numbers for the DMARC
algorithm and the report format? I imagine, the RFC 7489  would
do the job for both purposes.

4) How does the report generator know which format version the consumer
supports?

Ideas:
a) Send new format and don't care about old versions.
b) Send new format but avoid compatibility breaking changes in the XML
design. Add new fields, but do not change existing ones like
 (cf. #51, #75).
c) Consumer announces supported version in DNS record ("rua2=" or whatever).
d) Send both versions (... for how long?).

Regards,
Matt

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

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

[Matthäus Wander]

Laura Atkins wrote on 2021-05-08 13:59:
>> What happens to the existing "envelope_to"?
> 
> The proposal objected to was adding a new piece of information to pass
> along information that would allow reconstruction of a forwarding pathway. 
> 
> Case 1: Identify mail flows along forwarders.

This was not meant as a proposal. It is an explanation of what is
possible with the envelope_to that exists in the spec already:


> The current system does not allow for reconstruction of the forwarding
> pathway.

I agree in that envelope_to makes it easier for reconstruction of the
pathway, but disagree otherwise. DMARC reporting in principle allows for
reconstruction of the pathway, as noted in the privacy considerations:

Other proposals in the current I-Ds contribute to this privacy threat
and may be worth a separate discussion:
- #57 requires reporting of selectors, which can be exploited for tracking.
- #62 makes reporting mandatory, which leaves the mail receiver with no
means to mitigate the privacy threat.

Regards,
Matt

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

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

[Matthäus Wander]

Barry Leiba wrote on 2021-05-06 16:16:
> Chair weighing in, as chair:
> 
> We're divided in the sense that there are some who want to add this
> information, but as I see it the rough consensus is not divided:
> - This is extra information that's being proposed... so, a new
> feature.  That requires rough consensus to add it.
> - Serious privacy issues have been raised with respect to adding that
> information.
> - No refutation of those privacy issues has been given, and no
> adequate mitigation has been proposed.  The suggestion of requiring a
> minimum level of aggregation is insufficient, as there's ample general
> evidence that privacy leaks survive aggregation.
> - We therefore do not have rough consensus to add this.

Allow me to ask for clarification.

- "receiving_domains" has been proposed in #23 as new metadata.
- "receiving_domains" is redundant to "envelope_to", which already
exists in RFC 7489 and is being used in practice by a small portion of
reporters.
- Privacy concerns have been raised, which apply to both elements.
- The proposed "receiving_domains" gets rejected.

What happens to the existing "envelope_to"?

Regards,
Matt

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

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

[Matthäus Wander]

John Levine wrote on 2021-05-02 22:30:
> It appears that Matthäus Wander  said:
>> envelope_to allows you to automatically correlate these reports and
>> reconstruct the forwarding path. This helps to identify the culprit who
>> is breaking DKIM signatures, especially with longer forwarding chains.
>> Without envelope_to, reconstructing the mail flow requires guessing and
>> manual work.
> 
> It is none of your business to whom I forward my mail.

I'm not quite sure what the problem is, but the solution may be to not
send DMARC reports and to not forward to systems that send DMARC reports.

It's worth noting that even without envelope_from and envelope_to
domains, RUA reports reveal forwarders.

Regards,
Matt

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

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

[Matthäus Wander]

I see the following use cases for the envelope_to.

Case 1: Identify mail flows along forwarders.

With an increased adoption of DMARC reporting, we will be getting
reports like this:

Report from $ForwarderOrg:
HeaderFrom=$OriginDomain + EnvFrom=$OriginDomain --> $ForwarderOrg
Report from $RecipientOrg:
HeaderFrom=$OriginDomain + EnvFrom=$ForwarderDomain --> $RecipientOrg

envelope_to allows you to automatically correlate these reports and
reconstruct the forwarding path. This helps to identify the culprit who
is breaking DKIM signatures, especially with longer forwarding chains.
Without envelope_to, reconstructing the mail flow requires guessing and
manual work.

Case 2: Get information for tracing errors.

Let's say you find a DKIM or SPF error from RUA reports and would like
to investigate, because you expect a different outcome. Two real-life
examples I've experienced:

a) We suspect a bug in either our DKIM signer or the recipient's DKIM
verifier (inferred from recipient's RUA report).
b) We are convinced a forwarder breaks DKIM signatures (inferred from a
third-party destination's RUA report).

If one of the involved parties is willing to investigate further, they
ask for the timestamp, sender address and recipient address to trace
their logs. I understand that this is the use case for RUF reports to
shine. I'm arguing that RUA reports suffice, if they contain the day,
sender domain and recipient domain.


Todd Herr wrote on 2021-04-29 14:44:
> I believe all of those things are already possible with the aggregate
> report as it is now, with no need to list the recipient domains. For any
> set of X domains hosted at provider Y, I would expect DMARC validation
> results (i.e., pass or fail) to be consistent across all X domains at
> that provider.

In theory, yes.

In practice:
a) Some forwarders (including large infrastructures) show a wildly
inconsistent behavior with DKIM signatures, which at least to some
degree seems to depend on the recipient domain. If these forwarders
start reporting, I'd need the recipient domain to make sense of their
reports. See also Case 1 above.
b) Some recipients report sporadic SPF or DKIM permerrors for some
messages, while other messages validate correctly. This behavior
probably does not depend on the recipient domain, but see Case 2 above.

Regards,
Matt

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

[dmarc-ietf] Recipient domain in aggregate reports (#23)

[Matthäus Wander]

Hello everyone,

I'm new to the party. I'd like to bring in some practical experience of
working with DMARC rua reports.

#23 introduces "receiving_domains" in the report metadata, justified by
large infrastructures that host a large number of domains (e.g. Google).

I think, this information would be more useful per-record rather than in
the global metadata. As large infrastructures tend to include many
different records in the report, the analyst needs a correlation between
record and recipient domain.

The  section has an optional "envelope_to" already:
>
>minOccurs="0"/>

Is there a benefit in the global "receiving_domains" over the per-record
"envelope_to"?

Most reporters don't include "envelope_to" (e.g. Google). This field
could be made more prominent in the draft. The main body mentions
"header_from" only, but neither "envelope_to" nor "envelope_from".

Regards,
Matt

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