On Mon 01/Apr/2024 11:20:06 +0200 Tero Kivinen wrote:
Alessandro Vesely writes:
On Sun 31/Mar/2024 14:22:04 +0200 Douglas Foster wrote:
On SPF, our document should say simply,
" a DMARC-compliant evaluator MUST NOT reject a message, based on SPF result,
prior to receiving the Data section and checking for aligned and verifiable
signatures."
Nonsense. Rejecting at RCPT TO is much quicker than waiting for the whole
message. People who publish -all know what they do.
I also reject based on RBLs and private IP lists; does that affect DMARC
compliance?
Yes, either one of those practices are not using DMARC to validate the
messages.
Of course you are allowed to do whatever extra checks you want for the
incoming emails, you can even reject ever email coming in from
ip-address is even number, but that is not DMARC.
To implement DMARC you have to follow the rules set in the DMARC.
Yes.
I.e. if you are implementing DMARC you MUST follow the rules set in
section 5.7.2 and the step 3 requires you to do DKIM signature
verifications checks, which you can't do if you reject email before
the you even see the body that contains DKIM signatures. Actually you
can't do steps 1 and 2 of the 5.7.2 if you reject email before body as
you do not know RFC5322.From domain, so how can you claim to be
implementing DMARC if you do not even load DMARC policy record.
Section 5.7 starts by saying (my enhancement):
This section describes receiver actions _in the DMARC environment_.
All the following mustard covers the case you enter DMARC environment.
I could also apply DMARC processing to an email message that someone typed by
hand directly on the server console (more realistically, bringing in an USB
key.) This doesn't mean I shall allow server access to anyone asking for it.
So you can do whatever extra checks you want, but those are not part
of DMARC, and should not be considered here.
Agreed.
If you actually implement DMARC, you already MUST NOT reject a message based
on the SPF results prior to receiving data section, as that is already
mandated by the section 5.7.2 dmarc, so saying that again in the draft is
not adding any new requirements, it is simply restating the same requirement
in different words for implementors just in case they did not properly
understand the section 5.7.2.
See above. Mechanisms outside DMARC can prevent access to the DMARC
environment.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
