I wrote earlier:
I think what you intend is the following:
gardener.com = v=spf1 +all
In fact, gardener.com should publish (the IP4: equivalent of)
"v=spf1 a:out45.us4.outblaze.com"
That's it. No ending "all".
This tells the world that it's not known if the "gardener.com" email
they just received is real or not. So anyone receiving mail from
Rose(_at_)gardener(_dot_)com will get NEUTRAL.
But it tells the domain whose user receives the Rose(_at_)gardener(_dot_)com
(comcast, in my example) that mail to ab299321(_at_)chicago(_dot_)comcast(_dot_)com that
comes from gardener.com for sure (PASS). And it does this service to all
the other users who use the forwarding through gardener.com, too (of
course). That's brownie points for gardener.com :)
This setup reflects well the fact that the desire of
ab299321(_at_)chicago(_dot_)comcast(_dot_)com to receive ALL the mail via
Rose(_at_)gardener(_dot_)com is much higher than his/her desire to guarantee that
his own mail is delivered elsewhere. Also, one of these two direction he
can control (incoming), but not the other. Also, he knows that delivery
of his mail sent as Rose is not guaranteed to be delivered. Mail.com
tells him so, based on the fact that an SPF record that ends with -all
cannot be published at gardener.com
These are subtle details, but I think extremely important to think about
them with respect to forwarders, since forwarders are SPF's weakest point.
I think trying to strengthen the weakest point is better than ignoring it.
Hence my forwardmaster idea, which allows individual users to tell their
postmaster what forwarded email they would like to except from SPF
scrutiny (ie, permit incoming mail via gardener.com to be treated as
PASS instead of FAIL). Of course the forwardmaster would know that mail
via gardener.com that resolves with NEUTRAL is not mail via gardener.com.
Maybe I'll draw a picture if some people would find it difficult to
understand what I'm saying, but would like to :)
Sorry about diverting back to forwardmaster, but the issue of HELO
checking and forwarders are related a little bit.
To tie in the %{l} bone I'm picking:
It would not help for the gardener.com to publish:
"v=spf1 a:out45.us4.outblaze.com %{l}.gardener.com -all"
and then allow all its users to specify their own sources, because one
bad apple would spoil the reputation of the entire gardener.com domain.
Already other receiving domains treat mail from gardener.com as NEUTRAL
(ie, high spam score). Allowing the domain to have a bad reputation
would be equivalent to making the domain name useless for email.
Daniel Taylor wrote:
The question remains.... what should out45.us4.outblaze.com publish
as a TXT record, and how will this work when the user at comcast
gets mail from Rose and from the Lawyer?
That TXT record will be fetched when comcast checks the HELO with
SPF.
What flavor is the sky?
The domain for the From: is irrelevant to checking HELO or MAIL FROM.
In fact, the domain for MAIL FROM is irrelevant to the SPF check for
HELO, since HELO is only checked for MAIL FROM <>.
Well... that's not what Wayne's draft says. There's no mention of the
HELO check being conditional.
In fact, it vaguely alludes to the opposite (MAIL-FROM check after HELO
check)
SPF clients MUST check the "MAIL FROM" identity unless HELO testing
produced a "Fail". SPF clients check the "MAIL FROM" identity by
applying the check_host() function to the "MAIL FROM" identity as the
<sender>.
but speaking of the order ... what's the problem with checking MAIL-FROM
first, and then HELO (if necessary)? I think both orders are equivalent,
unless one is conditional on the other.
Which also begs the question... What would it mean if MAIL-FROM gives
PASS, but HELO gives FAIL, or PermError or TempError?
Ok... I'm done unifying theories for today. Thank you for putting up
with it. :)
Radu.