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

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message <564e68e5-c121-45f1-afef-3770b7377...@tana.it>, Alessandro
Vesely  writes

>On Sun 12/Nov/2023 09:26:32 +0100 Richard Clayton wrote:
>> In message <55dc7b67-e48a-4eb3-9cdc-4e4319cc7...@marmot-tech.com>, Neil

>> AIUI, Yahoo only sends failure reports when there is a formal agreement 
>> in place (which addresses data protection and privacy issues).
>
>
>That would depend on 

I think you might reasonably assume that Yahoo's lawyers have paid
attention to the complexity inherent in providing the data

I am less certain that some of the other senders of failure reports
(mainly Chinese in my recent experience) are in jurisdictions that have
to concentrate so much

The substantive point for the WG is that continuing to standardise the
format of these reports remains useful, even if many people will never
see an example.

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZVDs7N2nQQHFxEViEQKK0gCfXFDcrH8VQ1NJm47seMClIUzM0rAAoKe8
ahpl1WdS1Zayhrd3Nv8ussKJ
=7n4z
-END PGP SIGNATURE-

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

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

[Alessandro Vesely]

On Sun 12/Nov/2023 09:26:32 +0100 Richard Clayton wrote:

In message <55dc7b67-e48a-4eb3-9cdc-4e4319cc7...@marmot-tech.com>, Neil
Anuskiewicz  writes

   I have a feeling the die is cast for failure reports from MBPs. I’m 
   curious to learn if they sent legit failures, which has scared off 
   the major MBPs except for Yahoo.


AIUI, Yahoo only sends failure reports when there is a formal agreement 
in place (which addresses data protection and privacy issues).



That would depend on how the MBP's end-user agreement is worded.  End users are 
what the GDPR calls /data subject/s, the ones who should give consent to treat 
their PII.  The agreement should spell out if user's data can be disclosed just 
to MBP's partners or to mail operators at large.  (IANAL.)




Yahoo also operates an FBL (for which you need to apply)... DKIM passes
are required for this data to be sent.



Same issue.  The Original-Rcpt-To: field contains the email address of the 
complainant, which is PII (not known to the sender in case of forwarding.)



Best
Ale
--






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

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

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message <55dc7b67-e48a-4eb3-9cdc-4e4319cc7...@marmot-tech.com>, Neil
Anuskiewicz  writes

>I have a feeling the die is cast for failure reports from MBPs. I’m 
>curious to learn if they sent legit failures, which has scared off 
>the major MBPs except for Yahoo.

AIUI, Yahoo only sends failure reports when there is a formal agreement
in place (which addresses data protection and privacy issues).

Yahoo also operates an FBL (for which you need to apply)... DKIM passes
are required for this data to be sent.

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZVCMON2nQQHFxEViEQJm5gCg/NAKLeMpPvVwuf/duV3eI7ngjkUAoLoV
gEI41kPWQq67WD7a0FczLAkj
=m0r1
-END PGP SIGNATURE-

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

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

[Steven M Jones]

On Nov 12, 2023, at 1:02 PM, Neil Anuskiewicz 
 wrote:
> 
> Eventually, I’d reckon, Yahoo will stop sending failure reports, rendering 
> them worthless as nobody you’ve heard of will send them.

Even if that were to happen, the standardized format may continue in use / 
continue to be useful. And if I can scrape together enough spare minutes, I’ll 
get a reflector running again so that people implementing DMARC can send to an 
address that will definitely send failure reports when there’s a problem.

—S.


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

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

[Neil Anuskiewicz]

> On Nov 11, 2023, at 7:11 PM, Steven M Jones  wrote:
> 
> 
>> On 11/12/23 04:56, Dotzero wrote:
>> 
>> Our original intent (I'm one of the folks behind DMARC) was that failure 
>> reports would be provided to senders just like aggregate reports. This was 
>> before GDPR and privacy concerns did a number on the practice. The companies 
>> that provide the service of managing these FBLs for you typically allow you 
>> to view and/or download the reports.
> 
> +1 on the original intent - we were on the cusp of having a network of paid 
> services and bi-lateral information sharing agreements, but instead the group 
> decided an open system anybody could participate in would be better. Not that 
> it would be effortless to participate and benefit, it obviously takes a lot 
> of work, but it would be possible if one put in the effort and resources.
> 
> +1 on the general decline due to a changing PII landscape.
> 
> There are still some sources sending failure reports, but they tend to be 
> smaller operators.
> 
> And even in a world of "private failure reports," having the format 
> standardized is a useful thing.
> 
> --Steve.
> 

I have a feeling the die is cast for failure reports from MBPs. I’m curious to 
learn if they sent legit failures, which has scared off the major MBPs except 
for Yahoo.  So if others were using a third party, it’d be sort of interesting 
to know what they sent and how it assuaged those worried about the PII.

Eventually, I’d reckon, Yahoo will stop sending failure reports, rendering them 
worthless as nobody you’ve heard of will send them. This issue isn’t a five 
alarm fire. I figure maybe adjust this next WG. I think the train has left the 
station and there’s no brake to pull.

Thanks.

Neil




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

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

[Neil Anuskiewicz]

> On Nov 11, 2023, at 11:56 AM, Dotzero  
> Our original intent (I'm one of the folks behind DMARC) was that failure 
> reports would be provided to senders just like aggregate reports. This was 
> before GDPR and privacy concerns did a number on the practice. The companies 
> that provide the service of managing these FBLs for you typically allow you 
> to view and/or download the reports.
> 
> Michael Hammer 

Mike, thank you for explaining that. It makes total sense now. And, on the face 
of it, it does sound like a good idea. Did this third party sanitize the data 
or send straight up failure reports?

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

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

[Steven M Jones]

On 11/12/23 04:56, Dotzero wrote:


Our original intent (I'm one of the folks behind DMARC) was that 
failure reports would be provided to senders just like aggregate 
reports. This was before GDPR and privacy concerns did a number on the 
practice. The companies that provide the service of managing these 
FBLs for you typically allow you to view and/or download the reports.



+1 on the original intent - we were on the cusp of having a network of 
paid services and bi-lateral information sharing agreements, but instead 
the group decided an open system anybody could participate in would be 
better. Not that it would be effortless to participate and benefit, it 
obviously takes a lot of work, but it would be possible if one put in 
the effort and resources.


+1 on the general decline due to a changing PII landscape.

There are still some sources sending failure reports, but they tend to 
be smaller operators.


And even in a world of "private failure reports," having the format 
standardized is a useful thing.


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

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

[Neil Anuskiewicz]

On Nov 11, 2023, at 1:21 PM, Dotzero  wrote:On Sat, Nov 11, 2023 at 3:45 PM Neil Anuskiewicz  wrote:Michael, I’m realizing I started this discussion thinking we were talking about failure reports and a bit about aggregate reports when I think we might have pivoted to Feedback Loops and I was so focused on reports, I failed to register the change. Or just as likely it was FBL’s the whole time. Either way I apologize for the back and forth. I see what you were saying when I notice the word FBL that I somehow missed.NeilThese reports are a type of FBL (feedback loop).
Yes sir. It’s all clear to me now.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dotzero]

On Sat, Nov 11, 2023 at 3:45 PM Neil Anuskiewicz 
wrote:

> Michael, I’m realizing I started this discussion thinking we were talking
> about failure reports and a bit about aggregate reports when I think we
> might have pivoted to Feedback Loops and I was so focused on reports, I
> failed to register the change. Or just as likely it was FBL’s the whole
> time. Either way I apologize for the back and forth. I see what you were
> saying when I notice the word FBL that I somehow missed.
>
>
> Neil
>

These reports are a type of FBL (feedback loop).

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

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

[Neil Anuskiewicz]

On Nov 11, 2023, at 11:56 AM, Dotzero  wrote:On Sat, Nov 11, 2023 at 1:47 PM Neil Anuskiewicz  wrote:
The fact that you aren't seeing failure reports doesn't mean they aren't being generated. My experience has been that they are being made available through 3rd parties where there is a contractual relationship.
> 
> Michael Hammer 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

Michael, then if you say that’s how it works via third parties then I believe you. I’m surprised I never knew that somehow. I always thought that the major MBPs sent their own aggregate and failure reports. I do learn something new every day but this one caught me off guard. What I have heard of is companies you could hire to manage your feedbacks for you as a service. The part I missed was these companies actually generating and sending failure reports receivers. I’ve not found a company with a quick web search but I’ll try again later. They don’t also send the agg reports for their clients to only failure reports? I will do a deeper web search later as now I’m feeling a bit of cognitive dissonance and so want to read up on how this service works.Our original intent (I'm one of the folks behind DMARC) was that failure reports would be provided to senders just like aggregate reports. This was before GDPR and privacy concerns did a number on the practice. The companies that provide the service of managing these FBLs for you typically allow you to view and/or download the reports.Michael, I’m realizing I started this discussion thinking we were talking about failure reports and a bit about aggregate reports when I think we might have pivoted to Feedback Loops and I was so focused on reports, I failed to register the change. Or just as likely it was FBL’s the whole time. Either way I apologize for the back and forth. I see what you were saying when I notice the word FBL that I somehow missed.Neil___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dotzero]

On Sat, Nov 11, 2023 at 1:47 PM Neil Anuskiewicz 
wrote:

>
> The fact that you aren't seeing failure reports doesn't mean they aren't
> being generated. My experience has been that they are being made available
> through 3rd parties where there is a contractual relationship.
> >
> > Michael Hammer
> > ___
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmarc
>
> Michael, then if you say that’s how it works via third parties then I
> believe you. I’m surprised I never knew that somehow. I always thought that
> the major MBPs sent their own aggregate and failure reports. I do learn
> something new every day but this one caught me off guard. What I have heard
> of is companies you could hire to manage your feedbacks for you as a
> service. The part I missed was these companies actually generating and
> sending failure reports receivers. I’ve not found a company with a quick
> web search but I’ll try again later. They don’t also send the agg reports
> for their clients to only failure reports? I will do a deeper web search
> later as now I’m feeling a bit of cognitive dissonance and so want to read
> up on how this service works.


Our original intent (I'm one of the folks behind DMARC) was that failure
reports would be provided to senders just like aggregate reports. This was
before GDPR and privacy concerns did a number on the practice. The
companies that provide the service of managing these FBLs for you typically
allow you to view and/or download the reports.

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

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

[Neil Anuskiewicz]

The fact that you aren't seeing failure reports doesn't mean they aren't being 
generated. My experience has been that they are being made available through 
3rd parties where there is a contractual relationship.
> 
> Michael Hammer 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

Michael, then if you say that’s how it works via third parties then I believe 
you. I’m surprised I never knew that somehow. I always thought that the major 
MBPs sent their own aggregate and failure reports. I do learn something new 
every day but this one caught me off guard. What I have heard of is companies 
you could hire to manage your feedbacks for you as a service. The part I missed 
was these companies actually generating and sending failure reports receivers. 
I’ve not found a company with a quick web search but I’ll try again later. They 
don’t also send the agg reports for their clients to only failure reports? I 
will do a deeper web search later as now I’m feeling a bit of cognitive 
dissonance and so want to read up on how this service works.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dotzero]

On Sat, Nov 11, 2023 at 9:17 AM Neil Anuskiewicz  wrote:

>
>
> On Oct 25, 2023, at 3:57 AM, Olivier Hureau <
> olivier.hur...@univ-grenoble-alpes.fr> wrote:
>
> 
> 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
> record MUST comply with the formal specification found in Section 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.
>
> Email is not dead! Now the bad news: error reports (commonly called
> failure or forensic reports are not long for this world. The only major MBP
> that I see failure reports from is Yahoo. I’m not advocating eliminating
> failure reports altogether as when one of these mythical creatures appears
> they can be very useful. But I wonder if Yahoo discusses stopping failure
> reports then failure reports would be far less useful. I do understand the
> PII concerns.
>
> My point is that the concept of failure reports sounds good in theory but
> I’d say we are in irons now with a decent chance of running aground. It
> might be an opportune time to rethink the failure report. I don’t know.
>

The fact that you aren't seeing failure reports doesn't mean they aren't
being generated. My experience has been that they are being made available
through 3rd parties where there is a contractual relationship.

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

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

[Neil Anuskiewicz]

On Oct 25, 2023, at 3:57 AM, Olivier Hureau  wrote:

  

  
  
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 record MUST comply
with the formal specification found in Section
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.Email is not dead! Now the bad news: error reports (commonly called failure or forensic reports are not long for this world. The only major MBP that I see failure reports from is Yahoo. I’m not advocating eliminating failure reports altogether as when one of these mythical creatures appears they can be very useful. But I wonder if Yahoo discusses stopping failure reports then failure reports would be far less useful. I do understand the PII concerns.My point is that the concept of failure reports sounds good in theory but I’d say we are in irons now with a decent chance of running aground. It might be an opportune time to rethink the failure report. I don’t know. 
  

___dmarc mailing listdmarc@ietf.orghttps://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] 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.

[John Levine]

It appears that Steven M Jones   said:
>> 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.
>
>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. ...

At this point the only significant site that sends failure reports is Linkedin.
But it is my impression that there are a lot of places that exchange them by
private agreements that deal with the PII issues.

I wouldn't put a lot more work into them but there's no reason to take them out.

R's,
John

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

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

[Steven M Jones]

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 )


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.


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.


GDPR and similar regulations are generally cited as causing the decline 
five years ago. There are still senders out there, but they tend to be 
small domains.


--S.

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

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

[Alessandro Vesely]

On Wed 25/Oct/2023 15:19:36 +0200 Matt V wrote:

What if we were to look at re-writing this in a way that says something like 
this:

In the case of optional DMARC flags (ex: sp, adkim, aspf, pct) that are
malformed, the processing system SHOULD ignore them as invalid inputs, and 
MUST
utilize the valid flags that are mandatory (ex: v, p) and properly 
formatted.
Where an RUA tag exists and the mandatory flags are invalid the processor
SHOULD default to p=none as the policy and indicate the change in the RUA 
report.

Example:
"V=DMARC1; p=reject; sp=quarter; rua=mailto:t...@sample.com 

The DMARC processor would evaluate that sp= is a bad value and ignore it 
completely, defaulting to just the valid p= record, and treat it accordingly 
under the DMARC process.


We could possibly suggest a notation for RUA reports as none 
(assumed) or use the existing override reporting options to indicate 
that this was the 'assumed/best guess' operation due to bad record formatting.



+1.  The example should be part of the text, obviously (although the above 
indentation doesn't suggest so).



Best
Ale
--



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

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

[Murray S. Kucherawy]

On Tue, Oct 24, 2023 at 11:11 PM Steven M Jones  wrote:

> On 10/20/23 12:35 PM, Murray S. Kucherawy wrote:
>
> (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.
>
> It's not so much changing the handling as changing the reporting.
>

Yes, I think that was probably the intent of the logic branch here, but
that's not how it reads.


>
> So then, maybe we wind up with something like this:
>
> PROPOSED versus draft 28 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:
>
>*  The Mail Receiver MUST act as if a record containing "p=none" was
>   retrieved and continue processing;
>
>*  The Mail Receiver MAY note the invalid "p", "sp", or "np" tag
>   in the optional "error" field of the informative section of the
>   DMARC aggregate report [I-D.ietf-dmarc-aggregate-reporting];
>
>*  If there is no "rua" tag, or if it does not contain at least one
>   syntactically valid reporting URI, the Mail Receiver effectively
>   applies no DMARC processing to this message.
> 
>
> And if somebody wants to argue against including the third point, I would
> offer that it may be better to be explicit that to repeat this exercise in
> a future WG.
>

I think the first bullet should include the word "only", otherwise it looks
like you're replacing a faulty "p" tag but not the others.

I think the MAY in the second bullet should be a lowercase "should".

I think the third bullet after the comma should read more like "the Mail
Receiver does not include this message in reporting in any way", because
the current language ties it back to handling which, as you said, is
already decided.

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

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

[Matt V]

What if we were to look at re-writing this in a way that says something
like this:

In the case of optional DMARC flags (ex: sp, adkim, aspf, pct) that are
malformed, the processing system SHOULD ignore them as invalid inputs, and
MUST utilize the valid flags that are mandatory (ex: v, p) and properly
formatted. Where an RUA tag exists and the mandatory flags are invalid the
processor SHOULD default to p=none as the policy and indicate the change in
the RUA report.

Example:
"V=DMARC1; p=reject; sp=quarter; rua=mailto:t...@sample.com;;

The DMARC processor would evaluate that sp= is a bad value and ignore it
completely, defaulting to just the valid p= record, and treat it
accordingly under the DMARC process.

We could possibly suggest a notation for RUA reports as none
(assumed) or use the existing override reporting options to
indicate that this was the 'assumed/best guess' operation due to bad record
formatting.

Just a thought.

~
Matt

On Wed, Oct 25, 2023 at 7:32 AM Olivier Hureau <
olivier.hur...@univ-grenoble-alpes.fr> wrote:

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

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

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

[Alessandro Vesely]

On Wed 25/Oct/2023 08:10:33 +0200 Steven M Jones wrote:


PROPOSED versus draft 28 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:

*  The Mail Receiver MUST act as if a record containing "p=none" was
   retrieved and continue processing;



If it were not for the appositive condition bringing about "sp" and "np", these 
two clauses would have a sound meaning.  Acting as if p=none after an invalid 
sp= clashes.  Let me try a different wording:


If, in a retrieved policy record, the policy to be applied, "p", "sp",
or "np", is specified with an invalid value, then:

*   The Mail Receiver MUST act as if said policy had the value "none";



*  The Mail Receiver MAY note the invalid "p", "sp", or "np" tag
   in the optional "error" field of the informative section of the
   DMARC aggregate report [I-D.ietf-dmarc-aggregate-reporting];
  
*  If there is no "rua" tag, or if it does not contain at least one

   syntactically valid reporting URI, the Mail Receiver effectively
   applies no DMARC processing to this message.



I agree to mention the error field here.  Yet, in such event, it is not 
possible to report the value of the policy, so minOccurs should be 0.


The order of the last two bullets is beter reversed.


Best
Ale
--



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

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

[Steven M Jones]

On 10/20/23 12:35 PM, Murray S. Kucherawy wrote:
(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.


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.


Olivier's language comes close to this. But then Matt and Ale have 
continued with reporting...



Matt Wander wrote:

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.


+1


So then, maybe we wind up with something like this:

PROPOSED versus draft 28 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:

   *  The Mail Receiver MUST act as if a record containing "p=none" was
  retrieved and continue processing;

   *  The Mail Receiver MAY note the invalid "p", "sp", or "np" tag
  in the optional "error" field of the informative section of the
  DMARC aggregate report [I-D.ietf-dmarc-aggregate-reporting];
 
   *  If there is no "rua" tag, or if it does not contain at least one

  syntactically valid reporting URI, the Mail Receiver effectively
  applies no DMARC processing to this message.


And if somebody wants to argue against including the third point, I 
would offer that it may be better to be explicit that to repeat this 
exercise in a future WG.



--S.

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

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

[Brotman, Alex]

Not that I’m aware of.  But even if we leave it unstructured, including 
examples about what may be useful could be of assistance.

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

From: Murray S. Kucherawy 
Sent: Monday, October 23, 2023 3:12 PM
To: Brotman, Alex 
Cc: Matthäus Wander ; dmarc@ietf.org
Subject: Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

On Mon, Oct 23, 2023 at 12:04 PM Brotman, Alex 
mailto:40comcast@dmarc.ietf.org>>
 wrote:
I should note that generally, while there's an "error" field available, there's 
no guidance about what should go in there. (not in 7489 either that I could 
find in a brief search)

Has there ever been any push for structured content there?  I think if there 
has been, that might be valuable input.  If not, then although structured is 
probably better than unstructured, unstructured is almost certainly better than 
none.

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

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

[Murray S. Kucherawy]

On Mon, Oct 23, 2023 at 12:04 PM Brotman, Alex  wrote:

> I should note that generally, while there's an "error" field available,
> there's no guidance about what should go in there. (not in 7489 either that
> I could find in a brief search)
>

Has there ever been any push for structured content there?  I think if
there has been, that might be valuable input.  If not, then although
structured is probably better than unstructured, unstructured is almost
certainly better than none.

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

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

[Brotman, Alex]

I can add this.

I should note that generally, while there's an "error" field available, there's 
no guidance about what should go in there. (not in 7489 either that I could 
find in a brief search)

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

> -Original Message-
> From: dmarc  On Behalf Of Matthäus Wander
> Sent: Monday, October 23, 2023 2:51 PM
> To: dmarc@ietf.org
> Subject: 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 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!C
> Ql3mcHX2A!GcbuMEjhafXK7OEhrWB70xSYAvSFVGT776G7Rd9JLN_8FJuuyBCEfJJ
> wkqzM64HD4KC46q0fl4NgesMsfXj22Jxg6gI7MWpfWutCZrad$
___
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] DMARC policy discovery and invalid tag exception.

[Alessandro Vesely]

On Fri 20/Oct/2023 21:35:48 +0200 Murray S. Kucherawy wrote:
(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?



The PolicyPublishedType includes entries for reporting the policy:

  
  
  
  

They are defined as follows:



 
  
  
  
 



np= is missing.


In order to allow to report errors, I see two possible ways.  One is to add an 
"error" to the enumeration.  An other, better way, is to set minOccurs to 0, 
saying in the text or comments that the element has to be omitted when it 
cannot be determined, not even applying defaults; that is, when it is invalid. 
In addition, we should add a generic element, possibly free text/ enum like 
policy overrides, to signal parsing errors or bad settings in the published record.



Best
Ale
--





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

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

[Alessandro Vesely]

On Fri 20/Oct/2023 21:09:29 +0200 Neil Anuskiewicz wrote:

On Oct 20, 2023, at 8:43 AM, Alessandro Vesely  wrote:
On Fri 20/Oct/2023 15:50:29 +0200 OLIVIER HUREAU 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 )


I think it means:
   if ( retrieved policy record does not contain a valid "p" tag' ||
(the applicable policy would be that of an "sp" or "np" tag &&
 such tag exists but is not valid)
  ) then:

  if a rua exists use it
  otherwise forget that record.

The tricky point is that, although sp= or np= default to p= if they are 
missing, if they are present but not valid a valid p doesn't help.


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


That's the case if From: referred to a subdomain.  In that case sp= would be 
applicable, but it is not valid, so treat is as if it had sp=none.  p= doesn't 
play.  Would have played if sp= was missing.


That’s my interpretation, too, but Olivier has a point that the wording isn’t 
as clear as it could be.



Agreed.  Adding this example, which shows how the interpretation depends on the 
From: domain, is probably more direct than attempting a formal logic explanation.



Best
Ale
--







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

[Douglas Foster]

Offlist

Do you support the notion that DMARC evaluation is only possible if a
record is found?

Doug Foster


On Fri, Oct 20, 2023, 11:16 AM OLIVIER HUREAU <
olivier.hur...@univ-grenoble-alpes.fr> wrote:

> 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 <
> 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Fri, Oct 20, 2023 at 12:05 AM OLIVIER HUREAU <
olivier.hur...@univ-grenoble-alpes.fr> 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.
>
> 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
>

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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Neil Anuskiewicz]

> On Oct 20, 2023, at 8:43 AM, Alessandro Vesely  wrote:
> 
> On Fri 20/Oct/2023 15:50:29 +0200 OLIVIER HUREAU 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 )
> 
> 
> I think it means:
>if ( retrieved policy record does not contain a valid "p" tag' ||
> (the applicable policy would be that of an "sp" or "np" tag &&
>  such tag exists but is not valid)
>   ) then:
> 
>   if a rua exists use it
>   otherwise forget that record.
> 
> The tricky point is that, although sp= or np= default to p= if they are 
> missing, if they are present but not valid a valid p doesn't help.
> 
> 
>> '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.
> 
> 
> That's the case if From: referred to a subdomain.  In that case sp= would be 
> applicable, but it is not valid, so treat is as if it had sp=none.  p= 
> doesn't play.  Would have played if sp= was missing.
> 
That’s my interpretation, too, but Olivier has a point that the wording isn’t 
as clear as it could be.

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

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

[Alessandro Vesely]

On Fri 20/Oct/2023 15:50:29 +0200 OLIVIER HUREAU 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 )



I think it means:
if ( retrieved policy record does not contain a valid "p" tag' ||
 (the applicable policy would be that of an "sp" or "np" tag &&
  such tag exists but is not valid)
   ) then:

   if a rua exists use it
   otherwise forget that record.

The tricky point is that, although sp= or np= default to p= if they are 
missing, if they are present but not valid a valid p doesn't help.




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



That's the case if From: referred to a subdomain.  In that case sp= would be 
applicable, but it is not valid, so treat is as if it had sp=none.  p= doesn't 
play.  Would have played if sp= was missing.



Best
Ale
--





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

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

[Dotzero]

On Fri, Oct 20, 2023 at 11:14 AM OLIVIER HUREAU <
olivier.hur...@univ-grenoble-alpes.fr> wrote:

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

There is no "p" if the syntax is incorrect. It really is as simple as that.
"p" isn't changed because there was no valid "p" in the first place. I'm
surprised you aren't asking for any string including a "q" to be considered
valid.

Michael Hammer

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

[Dotzero]

On Fri, Oct 20, 2023 at 10:39 AM OLIVIER HUREAU <
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

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.

[Dotzero]

On Fri, Oct 20, 2023 at 9:51 AM OLIVIER HUREAU <
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: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
>  
>

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

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

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

[Alessandro Vesely]

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