Re: [dmarc-ietf] WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

[Alessandro Vesely <[e-mail]>]

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
--