Maybe a small note on this one!:

With https://github.com/internetstandards/Internet.nl/pull/2080, t=y is treated the same as p=none.

The spec says the following about t=y:

The Domain Owner
         is currently testing its specified DMARC assessment policy and
         has an expectation that the policy applied to any failing
         messages will be one level below the specified policy.  That
         is, if the policy is "quarantine" and the value of the "t" tag
         is "y", a policy of "none" will be applied to failing messages;
         if the policy is "reject" and the value of the "t" tag is "y",
         a policy of "quarantine" will be applied to failing messages,
         irrespective of any other special handling rules that might be
         triggered by the "t" tag having a value of "y".

So a t=y p=reject is effectively a p=quarantine. Not sure if we actually treat it this way in the test as well, but I just wanted to make sure people were aware of this. It that sense it works different than pct=0 p=reject

My preferred solution would be this:

rf en ri -> Warning (you don't want to use these anymore even if you still use the old DMARC spec) considering it adds no value. DMARCbis removes these.
pct values other than 0 and 100 (values in between are unreliable) should be a warning/error. DMARCbis removes this. I think we should still allow this tag for backwardscompatibility (only with values 0 and 100).
maximum report size syntax (i.e. !10m): Many mailreceivers don't look at this and it is removed in DMARCbis. It also creates issues with partial reports.
Maybe a warning if np or sp are not specified? I think it's a good practice to specify these. I cannot really think of legitimate cases where you wouldn't want np not to be reject either.
psd=u (default) or not present: Maybe we can do an informational for this since it causes extra DNS queries (it's only there for backwards compatibility).

What do you think about this?

Uh oh!

DMARCbis new terms not accepted in DMARC test #2045

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions