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

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

Re: [dmarc-ietf] Aggregate Report Statistics

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

[dmarc-ietf] Aggregate Report Statistics

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

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

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

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

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

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

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

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

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

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

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"

[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

[dmarc-ietf] Policy Override in aggregate-reporting

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"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

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

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

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

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

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.

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

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.

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

Re: [dmarc-ietf] Tranco Toplist?

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

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

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

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

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,

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

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

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

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 d

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

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

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

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.

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

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

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

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 lon

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

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

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

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