Douglas Otis wrote:
Those publishing SPF records risk causing their mail being
forwarded by various recipients to be blocked or lost,
They don't "risk" this, they _want_ it, it's the idea of RMX
or SPF -all that "mail from A" must come from an IP allowed
by the sender policy of A. If "mail from A" arrives at C
from another IP B, then C would reject it.
If B was a spammer or mail worm the spam or worm is in fact
"lost", again that's the very idea of RMX or SPF FAIL. If B
was a legit MTA it would create a bounce message to A, and
the mail is not lost.
Either A screwed up, maybe he forgot to include B in his
sender policy, or B screwed up, maybe a secondary MX forwarded
mail to a primary MX, and the latter tested SPF without
white-listing the secondary MX. SPF tests work as expected
at the border defined by A, but not later.
You can say that you don't like this one and only feature of
SPF, but you can't say that it's a bug, because it's the idea.
SPF however can not indicate which identity checking is
desired by the sender. Is it the Sender-ID PRA, the SPF
MAILFROM, or now the SPF MAILFROM and HELO in combination?
Not only "now", HELO was "always" mandatory for MAIL FROM:<>
and otherwise optional. It's not a new idea. And it's not
necessarily a good idea, actually it was one of the things I
hoped to solve in the former MARID WG, but unfortunately it
wasn't allowed to discuss 2821 and CSV. [The SPF overhead
for simple HELO checks is IMHO too big]
Sender-ID PRA has nothing to do with classic SPF policies, it
only uses a somewhat similar syntax for Sender-ID policies.
This gets even worse with use of this same TXT RR by more
than one faction.
If somebody abuses a protocol for a completely different
purpose, and it breaks, then he owns the pieces. As far as
SPF and I'm concerned the goal is a SPF RR replacing TXT in
the future. One of the reasons why I wanted an RfC.
The other reason was to get an "official" document which can't
be modified only because the authors have a new idea. That's
now solved by the formation of the SPF council.
The new SPF processing limits are stated differently
They are just clear and better. The handling of all errors is
now much more predictable. Minus DNS timeout errors the same
policy should now have the same effect with all conforming SPF
This compares poorly to CSV which uses a single lookup to
obtain the CSV-CSA record.
Depends, many policies need only ip4 and all, and that causes
no additonal lookup. a, include, exists, and redirect need one
lookup. Ignoring the discouraged ptr only mx is "difficult",
but OTOH looking up MX is something any MTA knows. Yes, there
is a significant potential overhead, that's the price for its
great flexibility like per-user policies.
s/great/too great/ as you see fit. An SMTP where nothing but
the IP is reliable doesn't work. An SMTP where the IP and the
MAIL FROM and the HELO make sense again is a huge step forward.