Opened 2 years ago

Last modified 13 months ago

#48 assigned defect

Remove sp= tag

Reported by: seth@… Owned by: todd.herr@…
Priority: major Milestone: Deliverable #3 (changes to DMARC base spec + DMARC Usage Guide
Component: dmarc-bis Version:
Severity: - Keywords: nit tag-update


sp= appears to be more trouble than it's worth. Once a domain puts sp=none into a record, it rarely ever gets removed. Instead of being a meaningful ratchet on the way to blocking/spamming all unauthenticated mail, sp=none appears to delay this process materially.

More data and discussion is needed here, as there is obviously value here, too, for those who know how to effectively use the flag.

Change History (6)

comment:1 Changed 2 years ago by seth@…

  • Component changed from rfc7601bis to dmarc-bis
  • Owner draft-ietf-dmarc-rfc7601bis@… deleted
  • Status changed from new to assigned

comment:2 Changed 17 months ago by todd.herr@…

I don't think we as a design team can undertake what's arguably a significant design change by ourselves. Recommend holding this for on-list discussion post-design team.

comment:3 Changed 17 months ago by todd.herr@…

Valimail data on 22 March 2021:

74790 DMARC records examined
  936 with sp= specified and sp= different from p=

comment:4 Changed 16 months ago by todd.herr@…

  • Owner set to todd.herr@…
  • Status changed from assigned to accepted

comment:5 Changed 16 months ago by todd.herr@…

  • Status changed from accepted to assigned

comment:6 Changed 13 months ago by dpa-ietf@…

We have the records: 7122 IN TXT "v=DMARC1;p=none;sp=reject" 7103 IN TXT "v=DMARC1;p=reject"

so essentially, must be DKIM-signed, while must not be signed, and is forbidden. If sp= is removed, messages from cannot be forbidden anymore. Whether this is a problem, is subjective. The sp= tag here is not an intermediate, but a final state.

But in other scenarios, 'p=none;sp=reject' can be an intermediary step before sealing the upper domain.

Note: See TracTickets for help on using tickets.