I don't understand the reluctance to grapple with this problem. Consider:
- Example.com has a typical mail store server used to send and receive employee's personal messages. - I receive a message from [email protected], and it passes with SPF PASS and strict alignment.. The example.com domain is used for both the DMARC policy lookup and the SPF policy lookup. - I reply to [email protected] and receive an automatic reply about her upcoming vacation. The auto-reply uses the same outbound path as all other messages from Example.com. If we allow SPF on null sender, the auto-reply is evaluated using a different SPF policy, based on the HELO name, although the justification for doing so is vague. - If the HELO SPF policy exists and the HELO domain is within Example.com, and the domain DMARC policy specifies relaxed alignment, then I have DMARC PASS. - If the domain DMARC policy specifies strict alignment, I have DMARC FAIL. - If the server domain is a hosting service, I have DMARC FAIL. - If the HELO policy does not exist, I have DMARC FAIL. Upshot of the above: - For many organizations, auto-reply messages require DKIM signatures to obtain DMARC PASS. - For all organizations, strict alignment is not allowed unless all auto-reply messages have DKIM signatures. - Because auto-reply messages are expected to use the same infrastructure as originating messages, requiring DKIM for auto-reply is obliquely requiring DKIM for originating messages. The flip side: What if an attacker wants to impersonate the server of another organization? I am doubtful that this is a useful attack strategy for a bad actor, but assuming that the intent exists, is SPF on HELO an effective defense against this attack? - If the attacker uses an actual server name, such as " realserver.example.com", and the server has an SPF policy, and the policy ends with -ALL, then the attack will be detected with SPF FAIL, which may be actionable. - But the attacker can choose where he is going to attack, and the existence of an SPF record is easily checked. So the attacker can simply use a made-up name, such as "fakeserver.example.com", to ensure that the the SPF on HELO lookup will return NONE/NXDOMAIN. That result is a weak one. Even NONE is enough to prevent DMARC alignment, but it is not particularly actionable on its own. So I see SPF on HELO as an insufficient authentication method for DMARC, because it provides insufficient coverage. I also see it as an ineffective defense tool when considered separately from DMARC. If we want to require DKIM for auto-replies, then let's be consistent and require it for originated messages. We could say, "Domains MUST provide DKIM signatures before publishing p=reject. SPF alignment is provided as an evaluation factor when processing messages for domains that do not specify p=reject.' But if we want to stick with SPF alignment for everyone, we need to deal with the auto-reply problem. Doug On Sun, Jun 9, 2024 at 1:32 PM Richard Clayton <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In message <CAH48Zfwke97+H66f3+MRqGkmha=MhA7tbzoSzRj2ELsw93ZK- > [email protected]>, Douglas Foster <[email protected]> > writes > > > I would be happy to have you or anyone else explain to me > > (a) What data indicates that a non-trivial number of servers have > > SPF policies on their host name, and > > (b) How the answer to that lookup provides information useful to > > an evaluation decision. > > I looked at the data from $DAYJOB$ for last Wednesday UTC (a typical day > I believe) > > For email with a null "MAIL FROM" (which includes a certain amount of > spam as well as delivery status reports ...) > > I see > > dkim fail, spf fail: 11% > dkim fail, spf pass: 6% > dkim pass, spf fail: 14% > dkim pass, spf pass: 69% > > $DAYJOB$ is coy about absolute numbers but the smallest category there > is more than 10 million and less than 100 million messages. > > When I look at the spf=pass results I see more than 650,000 unique EHLO > strings. I think that qualifies as non-trivial. > > Evaluation decisions at $DAYJOB$ are very complex indeed; but that 11% > will not be an issue RSN (because of "no auth no entry" policies) > > YMMV ... but I would be interested in learning what sort of volume you > are drawing conclusions from. > > - -- > richard Richard Clayton > > Those who would give up essential Liberty, to purchase a little temporary > Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 > > -----BEGIN PGP SIGNATURE----- > Version: PGPsdk version 1.7.1 > > iQA/AwUBZmXmrd2nQQHFxEViEQJi/QCgqBl0/6ll/WSu+KKt7qNzE8LPJBAAoM6W > 4xmGfD6kE8ikBoD87vv1dvgq > =wD4z > -----END PGP SIGNATURE----- > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
