On Wednesday, January 27, 2021 12:25:59 PM EST Alessandro Vesely wrote: > On Wed 27/Jan/2021 15:00:29 +0100 Scott Kitterman wrote: > > On Wednesday, January 27, 2021 4:49:02 AM EST Alessandro Vesely wrote: > >> On Tue 26/Jan/2021 23:36:19 +0100 Scott Kitterman wrote: > >>> On Tuesday, January 26, 2021 11:47:51 AM EST Alessandro Vesely wrote: > >>>> On Tue 26/Jan/2021 14:14:45 +0100 Scott Kitterman wrote: > >>>>> On Tuesday, January 26, 2021 6:54:56 AM EST Alessandro Vesely wrote: > >>>>>> I doubt that SPF filters report envelope-from=postmaster@HELO; more > >>>>>> likely they write helo=HELO. In that case, the paragraph quoted > >>>>>> above > >>>>>> is deceptive. > >>>>>> > >>>>>>> I believe the proposed text is clear enough about not using > >>>>>>> separate HELO identity results and that's appropriate. >>>> > >>>>>> > >>>>>> My filter collects SPF results recorded from an upstream SPF filter. > >>>>>> It writes Received-SPF: lines for each identity. For NDNs, it writes > >>>>>> a Received-SPF: for the HELO identity only. Am I allowed to use that > >>>>>> result for DMARC? > >>>>> > >>>>> No. You should only use Mail From results. > >>>> > >>>> So NDNs having only an aligned HELO will never pass DMARC? > >>>> > >>>> And what is a <scope>helo</scope> element in aggregate reports provided > >>>> for? > >>>> > >>>> The spec says: > >>>> [SPF] can authenticate either the domain that appears in the > >>>> > >>>> RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/ > >>>> HELO domain, or both. > >>>> > >>>> And then: > >>>> In relaxed mode, the [SPF]-authenticated domain and RFC5322.From > >>>> domain must have the same Organizational Domain. In strict mode, > >>>> only an exact DNS domain match is considered to produce Identifier > >>>> Alignment. > >>>> > >>>> So, consider the following message without DKIM signatures: > >>>> > >>>> HELO example.org > >>>> MAIL FROM:<u...@example.com> > >>>> > >>>> Received-SPF: pass (domain example.org > >>>> > >>>> designates 192.0.2.1 as permitted sender) > >>>> identity=helo; helo=example.org; > >>>> > >>>> Received-SPF: fail (domain of u...@example.com > >>>> > >>>> denies 192.0.2.1 as permitted sender) > >>>> identity=mailfrom; envelope-from="u...@example.com"; > >>>> > >>>> Subject: Not using a mail client for this example > >>>> From: different-u...@example.org > >>>> > >>>> Does it pass DMARC? > >>> > >>> No. > >> > >> Let's not be silly, Scott. We have example.org as the SPF-authenticated > >> domain and it is aligned with From:. Are you saying that the message > >> would pass if it had an empty bounce address, but since it can bounce it > >> does not pass?!? > > > > > All I'm saying is that DMARC only uses mail from results and that's > > appropriate. I don't think the case of HELO name being aligned, but mail > > from domain is not is one to worry about. > > That's abnormal, not appropriate. > > AFAIUI, there's no reason why SPF would work with a logic substantially > different than DKIM's. DKIM can provide n identifiers, if one of them is > aligned and "pass", then DMARC is "pass". SPF can provide 2 identifiers but > one of them is of class B. WTF? > > Can anyone explain why we have a <scope>helo</scope> element in aggregate > reports? > > Can we fix this aberration? > > The spec needs a fix anyway, because from the text I quoted above I > understood that the example message passes DMARC. Am I the only one? > > In addition, as I said, SPF filters are likely to report HELO as helo and > MAIL FROM as mailfrom. If we want to carry over this quirk, the spec must > say that a DMARC filter which gathers SPF authentication status from an > upstream filter MUST make sure that mailfrom is empty before validating > based on an aligned helo. > > Dropping that absurd discrimination between SPF identifiers would make for a > smoother spec. Since non-null mailfroms are in most cases aligned with > either From: or helo, the differences between existing compliant > implementations and the smoother spec would be limited to a hardly > noticeable set of test messages.
Your absurd is my eminently reasonable. I can't explain why it was added, but it makes sense, IMO, to have it there to aid in reconstructing the exact situation for trouble shooting purposes. DMARC has always (for the SPF related portion) been about alignment of mail from and from. I don't think adding HELO has appreciable value and is certainly not worth the added complexity to implement DMARC to include. There are lots of ways that DMARC could have addressed SPF. Personally I thought it might make sense to skip using the mail from SPF result and just check if the from address would pass if it were subjected to an SPF check, but that's not the existing design. I don't think it should be changed now. That said, I agree it's not 100% clear. I too am interested in what others think. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
