Re: [dmarc-ietf] Errata for Aggregate Reporting

[John Levine]

It appears that Alessandro Vesely   said:
>On Sun 24/Mar/2024 18:06:53 +0100 John Levine wrote:
>> It appears that Brotman, Alex  said:
>> 
>>>https://www.rfc-editor.org/errata/eid5774 :: There were a number of edits 
>>>for clarification to this portion of the document.  The "otherwise specified"
>language is no
>>>longer there, and I believe all concerns have been addressed for this 
>>>portion. 
>> 
>> I think you're right, but checking that schema makes one's eyes glaze.
>
>
>Redundant «minOccurs="1"» certainly don't help the eye.  I'm not particularly 
>happy with them, but can accept that concern for those who don't know what's 
>the default for minOccurs dictates redundancy.

There's a lot of

minOccurs="1" maxOccurs="1"

which add nothing and if it were up to me, I'd delete.  But at this point
if we think the XML is correct, let's not mess with it.

R's,
John

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

Re: [dmarc-ietf] Errata for Aggregate Reporting

[Alessandro Vesely]

On Sun 24/Mar/2024 18:06:53 +0100 John Levine wrote:

It appears that Brotman, Alex  said:


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


I think you're right, but checking that schema makes one's eyes glaze.



Redundant «minOccurs="1"» certainly don't help the eye.  I'm not particularly 
happy with them, but can accept that concern for those who don't know what's 
the default for minOccurs dictates redundancy.



Best
Ale
--





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

Re: [dmarc-ietf] Errata for Aggregate Reporting

[John Levine]

It appears that Brotman, Alex  said:
>There were a few errata for the aggregate reporting.  I wanted to confirm with 
>the list that these are still valid.
>
>https://www.rfc-editor.org/errata/eid5440 :: I thought it had been determined 
>the ";" was not necessary.

It was required in 7489 but not in the cleaned up ABNF we have now.
Since the examples in 7489 were missing the semicolon this was
adjusting the spec to agree with reality.

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

The new grammar makes the abgle brackets optional so we've addressed it.

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

I think you're right, but checking that schema makes one's eyes glaze.

R's,
John

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

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

[Alessandro Vesely]

On Sat 23/Mar/2024 19:53:39 +0100 John Levine wrote:

It appears that Murray S. Kucherawy   said:

-=-=-=-=-=-

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


It's already fixed in the current markdown.

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



How about:
"(:::)?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3}([01]?\d?\d|2[0-4]\d|25[0-5])"/>


Best
Ale
--







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

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

[Alessandro Vesely]

On Fri 22/Mar/2024 19:22:10 +0100 John R. Levine wrote:
While I generally agree, DMARC for the last decade didn't have a testing 
flag.  That's new in DMARCbis, so I don't think that's really germane. This 
particular thing is on us as a working group.


RFC 6376 makes it quite clear on page 28 that DKIM verifiers ignore signatures 
with a t=y flag, and treat them as though they're not there. What else is there 
to say?  If they're not there, the message isn't signed, at least not with that 
signature.



I think it depends on the verifier's configuration whether it reports dkim=pass 
or dkim=policy for test signatures.  And also for small keys, unsigned header 
fields which are considered important and the like.


So, for DKIM, DMARC results depend on tweaking receiver's configuration. 
That's very different from SPF, where it is the sender who tweaks its 
configuration by setting adequate qualifiers.  One more reason not to mix the two.



Best
Ale
--








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

Re: [dmarc-ietf] Policy Override in aggregate-reporting

[Alessandro Vesely]

On Fri 22/Mar/2024 23:23:55 +0100 Matthäus Wander wrote:
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.



+1, for this text.

Best
Ale
--







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

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Mar 24 06:00:04 2024

[John Levine]

   Count|  Bytes |  Who
++---
 56 ( 100%) | 437345 ( 100%) | Total
  9 (16.1%) |  63038 (14.4%) | Scott Kitterman 
  9 (16.1%) |  54473 (12.5%) | Alessandro Vesely 
  9 (16.1%) |  50879 (11.6%) | John Levine 
  8 (14.3%) |  54502 (12.5%) | Matthäus Wander 
  5 ( 8.9%) |  64043 (14.6%) | Todd Herr 
  3 ( 5.4%) |  44069 (10.1%) | Brotman, Alex 
  3 ( 5.4%) |  30822 ( 7.0%) | Murray S. Kucherawy 
  3 ( 5.4%) |  16278 ( 3.7%) | Benny Pedersen 
  2 ( 3.6%) |  18695 ( 4.3%) | Dotzero 
  2 ( 3.6%) |  11139 ( 2.5%) | John R. Levine 
  1 ( 1.8%) |  17142 ( 3.9%) | Douglas Foster 

  1 ( 1.8%) |   9409 ( 2.2%) | Mark Alley 
  1 ( 1.8%) |   2856 ( 0.7%) |  

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