Richard Clayton writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In message <26447.29429.714935.943...@fireball.acr.fi>, Tero Kivinen
> <kivi...@iki.fi> writes
>
> > Requirements for DMARC validators:
> >
> > - MUST implement mailto url for reports (4.7)
>
> I do not believe that 4.7 says that
It says:
... A Mail Receiver MUST implement
support for a "mailto:"; URI, i.e., the ability to send a DMARC
report via electronic mail.
both for rua and ruf tags, so I think that is supposed to mean that
mailto urls are mandatory to implement for sending reports.
It does not seem to say that sending reports is mandatory, but if you
support sending them you MUST be able to do those over mailto urls.
> > - MUST check SPF and store preserved result (5.3.3)
>
> it does not say that, it says it has to be preserved for future use,
> there is no requirement to store it
>
> > - MUST check DKIM and store preserved result (5.3.3)
>
> ditto
>
True, so the correct text is:
- MUST check SPF and preserve the result for later use (5.3.3)
- MUST check DKIM and preserve the result for later use (5.3.3)
> > - MUST store authentication results for eventual presentation back
> > to the domain owner. (5.3.7)
>
> you have missed out a conditionality.. there is no requirement in the
> document to create aggregate feedback results.
Ok, so the 5.3.7 MUST is wrong, it is SHOULD, not MUST, if there is
condition where it does not apply.
So changing 5.3.7 from:
----------------------------------------------------------------------
5.3.7. Store Results of DMARC Processing
If the Mail Receiver intends to fully participate in DMARC, then
results obtained from the application of the DMARC mechanism by the
Mail Receiver MUST be stored for eventual presentation back to the
Domain Owner in the form of aggregate feedback reports. Section 4.7
and [I-D.ietf-dmarc-aggregate-reporting] discuss aggregate feedback.
----------------------------------------------------------------------
to
----------------------------------------------------------------------
5.3.7. Store Results of DMARC Processing
The results obtained from the application of the DMARC mechanism by
the Mail Receiver SHOULD be stored for eventual presentation back
to the Domain Owner in the form of aggregate feedback reports.
Section 4.7 and [I-D.ietf-dmarc-aggregate-reporting] discuss
aggregate feedback.
----------------------------------------------------------------------
is needed.
If you have MUST with condition that is SHOULD. And having condition
of "intends to fully participate" is not very good condition...
> > - MUST NOT reject incoming messges solely on the basis of a
> > p=reject. (7.4)
>
> there is a SHOULD NOT in this section
There is SHOULD in 2nd block marked with '|', but the 3rd block
includes MUST NOT. The text I am referencing is:
----------------------------------------------------------------------
7.4. Interoperability Considerations
...
| It is therefore critical that Mail Receivers MUST NOT reject
| incoming messages solely on the basis of a "p=reject" policy by
| the sending domain. Mail Receivers must use the DMARC policy as
| part of their disposition decision, along with other knowledge and
| analysis. "Other knowledge and analysis" here might refer to
| observed sending patterns for properly-authenticated mail using
| the sending domain, content filtering, etc. In the absence of
| other knowledge and analysis, Mail Receivers MUST treat such
| failing mail as if the policy were "p=quarantine" rather than
| "p=reject".
----------------------------------------------------------------------
> > Requirements for Domain owners:
>
> these are NOT requirements for Domain owners ... we're not going to say
> that they MUST send mail !
If you are not sending any mail, all mails you sent are automatically
authenticated with all current and future means, as there is no mails
you are sending.
>
> > - MUST send mail so it produces an SPF-Authenticated identifier (to
> > configure SPF for DMARC) (5.1.1)
>
> You have that backwards (or at least you have failed to express the
> conditionality), it's IF you want to have validators consider whether
> there is a valid SPF pass for DMARC THEN you MUST ...
>
> 5.1.1 does not say that you need to publish any SPF at all
When you have MUSTs with conditions they are not really mandatory
anymore.
This MUST is actually completely inappropriate, as we can't really
mandate the domains owners to do anything. We can make feature
mandatory to implement, we can't make it mandatory to use.
So rewriting 5.1.1 and 5.1.2 to something that is not using MUST is
needed.
> > - MUST send mail that has DKIM signatures that produce a
> > DKIM-Authenticated identifier (to configure DKIM for DMARC)
> > (5.1.2)
>
> and that is backwards as well
Yes, 5.1.2 also needs rewrite.
> >The section 5.3.3 is not very clear that it requiers both SPF and
> >DKIM,
>
> I don't think that it has any such requirement -- and that is a good
> thing. Requiring SPF, rather than tolerating it, would not make this a
> useful document.
I agree. Unfortunately the text is written in such way that it says
so.
The current texts in 5.3.3 starts with:
----------------------------------------------------------------------
5.3.3. Determine If Authenticated Identifiers Exist
For each Authentication Mechanism underlying DMARC, perform the
required check to determine if an Authenticated Identifier
(#authenticated-identifier) exists for the message if such check has
not already been performed. Results from each check must be
preserved for later use as follows:
----------------------------------------------------------------------
So it does not say MUST directly but it just states that you loop
through authentication mechanism ("for each authentication
mechanicms"), and we have two authentication mechninisms, i.e., SPF
and DKIM.
I would understand that you need to go through all authentication
mechanims, and to be able to "perform the requiremd check" you need to
implement that, which means you need to implement both SPF and DKIM.
I would be very happy to say that for validators DKIM is REQUIRED
(i.e., MUST), and SPF is OPTIONAL (i.e., MAY).
This is the exact reason I think we DO NEED conformance requirements
section... We can't have this kind of ambiguity about mandatory to
implement features.
--
kivi...@iki.fi
_______________________________________________
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org
