On December 3, 2024 9:07:01 PM UTC, Tero Kivinen <[email protected]> wrote: >Alessandro Vesely writes: >> > Yes, and the point being? If you claim to support DMARCbis RFC after >> > it has been published, you need to support all MUSTs it lists. >> >> >> IMHO, supporting MUSTs serves for interoperability. IOW if you don't >> you won't interoperate. >> >> Claiming to support DMARC, per se, doesn't bring any goods. And >> organizations imposing to support DMARC and pushing to use p=reject >> seem to be doing more damage than good. > >Unfortunately there is lots of places which do say that you need to >support DMARC to be safe/secure/whatever, thus requiring other places >to implement and support DMARC. It would be good to at least have >those who are required to support DMARC to actually implement someting >that is useful. > >> > I would be quite happy to only require DKIM, but people wanted to keep >> > support for SPF also. >> >> >> SPF is a policy in its own right. An operator can honor both SPF and >> DMARC policies, independently of each other. The fact that DMARC >> re-uses SPF results (for message that were not rejected beforehand) >> does not prevent to apply SPF policies as an operator deems fit. >> >> DMARCbis /strongly suggests/ to not discard before also evaluating DKIM, but >> that is not even a SHOULD. > >I think we need to add "Conformance requirements" section to the >dmarcbis that clearly states which parts of the document are mandatory >to implement. We can't leave it in just "strongly suggesting" things. > >I.e., add after section 7, before section 8 new section listing >conformance requirements:: > >---------------------------------------------------------------------- >8. Conformance Requirements > > This section summarizes the minimal required features. The > requirements are different for the validators and for the domain > owners. > > Requirements for DMARC validators: > > - MUST implement mailto url for reports (4.7) > - MUST check SPF and store preserved result (5.3.3) > - MUST check DKIM and store preserved result (5.3.3) > - MUST store authentication results for eventual presentation back > to the domain owner. (5.3.7) > - MUST NOT reject incoming messges solely on the basis of a > p=reject. (7.4) > > Requirements for Domain owners: > > - MUST send mail so it produces an SPF-Authenticated identifier (to > configure SPF for DMARC) (5.1.1) > - MUST send mail that has DKIM signatures that produce a > DKIM-Authenticated identifier (to configure DKIM for DMARC) > (5.1.2) > - MUST use DKIM if domain publishes p=reject (7.4) >---------------------------------------------------------------------- > >The section 5.3.3 is not very clear that it requiers both SPF and >DKIM, but it do say "For each Authentication Mechanism underlying >DMARC, perform the required check", which means you loop through all >authentication methods (currently SPF and DMARC), and check them. > >The old text in version -30 was clear as it said: > >---------------------------------------------------------------------- >5.7.2. Determine Handling Policy > > To arrive at a policy for an individual message, Mail Receivers MUST > perform the following actions or their semantic equivalents. >---------------------------------------------------------------------- > >and the steps 3 was DKIM, step 4 was SPF, so both were mandatory. > >I would actually like to say that for DMARC implementations SHOULD do >SPF, and MUST do DKIM, but current text seems to require both. > >For domain owners it is optional to use either SPF or DKIM (or both) >as the section 5.1.1 and 5.1.2 start with "to configure xxx for >DMARC". It seems to bit useless to say that to use xxx you MUST do >xxx :-)
IETF RFCs are interoperability specifications, not conformance standards. DMARCbis can specify how to use DKIM/SPF results in a correct/interoperable way within DMARC. That's as far as it goes. Mandating how to set up either is out of scope. Scott K _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
