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 :-)
--
kivi...@iki.fi
_______________________________________________
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org
