On Mon 02/Dec/2024 18:09:23 +0100 Tero Kivinen wrote:
Alessandro Vesely writes:
On Mon 02/Dec/2024 03:49:31 +0100 Tero Kivinen wrote:
Richard Clayton writes:
(b) some small mailbox providers believe in the value of SPF to do
early stage filtering of mailflows and may penalise your domain for
not having any SPF at all.
Doing early SPF filtering is against DMARCbis document, as DMARCbis
document do require checking both DKIM and SPF, and those who do early
filtering of the emails based on the SPF, usually do it before
actually seeing the email, thus they do not even know if the emails
have DKIM headers or not.
I don't think so. There are several things that can occur to prevent
message reception besides SPF, including DNSBLs. DMARC protocol
begins /in case/ a message is received. Discarded messages don't
count.
And all of those things are outside the scope of DMARCbis, thus they
can be ignored when we are talking with DMARCbis.
Exactly.
Anybody doing early stage filtering of mailflows based on the SPF, and
not checking DKIM is not following the DMARCbis document, thus they
are out of scope of the DMARCbis discussion.
Issue #66 "Describe what it means to have implemented DMARC #14" eventually
resulted in Appendix C.6. There is no DMARC medal.
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.
[...] I assume the text:
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.
is trying to say that all mechanisms (DKIM and SPF) need to be
supported, even when it does not say MUST.
An operator can only verify both mechanisms on the messages it actually
receives.
You are allowed to do SPF only separately. You are not allowed to do
SPF only when you claim to do DMARCbis.
What would one claim to do DMARCbis for?
There is lots of places which have requirement for supporting DMARC
now, and I want to make sure that when DMARCbis gets added to those
lists, implementations claiming to support DMARCbis do what DMARCbis
says, and do support DKIM at least (there are lots of currently
deployed systems claiming to do DMARC and only have SPF in use).
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.
Best
Ale
--
_______________________________________________
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org
