In
<16611(_dot_)15427(_dot_)708207(_dot_)855024(_at_)giles(_dot_)gnomon(_dot_)org(_dot_)uk>
Roy Badami <roy(_at_)gnomon(_dot_)org(_dot_)uk> writes:
Meng> mta1.domain.com. TXT "v=spf1 a -all"
Meng> domain.com. TXT "v=spf1 include:this include:that a mx ?all"
Which (almost) boils down to CSV, but using SPF syntax instead of SRV
records.
Correctly, although the SPF syntax allows for more flexibility and
extensibility.
As it stands, your example still allows anyone to forge a HELO domain.com
Sort of.
For whitelisting purposes, the only people who can "forge" domain.com
in the HELO are those that are allowed by the domain.com SPF record.
While this SPF record is not as tight as it could/should be, in
practice I don't see much of a problem. Anyone that you trust enough
to send email using your domain in the 2821.FROM or 2822.From: would
almost certainly be trusted not to forge your 2821.HELO.
However, you are right that because the domain.com SPF record ends in
?all, people can't immediately reject random zombie machines that
use HELO domain.com.
There are two ways to "fix" this:
1) domain.com can transition from using ?all to using ~all or -all
2) if the scope macro variable is allowed (it was suggested as part of
the Unified-SPF), then you would need to have something like this:
mta1.domain.com. TXT "v=spf1 a -all"
domain.com. TXT "v=spf1 include:this include:that a mx
redirect=%{scope}._spf.%{d}"
helo._spf.domain.com. TXT "v=spf -all"
*._spf.domain.com. TXT "v=spf ?all"
The extra DNS lookup would only be required if the email didn't pass
the other tests. For most domains, this will usually happen only in
the case of spam.
Actually, there has also been a third suggested way for Unified-SPF to
fix this. Use a different version tag, such as:
domain.com. TXT "v=spf1 include:this include:that a mx ?all"
domain.com. TXT "v=spf1-helo -all"
Gain, the complicated cases are only needed for domains that are
waffling about their email policies, but want a tight email policy in
certain scopes.
Personally, I think something like the scope macro-variable needs to
be done in Sender-ID anyway since the current SPF records have all
been published under the assumption that they apply to 2821.FROM and
2821.HELO scopes and the 2822.From: scope is not always going to be
the same.
-wayne