Alan DeKok wrote:
I have a hard time seeing how any of them solve the problem
of relays which accept mail that they cannot deliver, and
that they cannot bounce to the correct entity.
SPF does this either directly or indirectly:
If a zombie uses a forged MAIL FROM protected by SPF, and the
receiver checks the sender policy, then it rejects this spam.
The zombie won't create a bounce, it's a minimal SMTP script.
If the zombie sends to an old-style forwarder (= no SPF check),
and the spam is rejected by the next hop, then this old-style
forwarder creates a bounce. But that's the same what happens
if the real MAIL FROM sends mail to this forwarder, and the
next hop rejects it, because the IP of the forwarder is not
listed in the sender policy.
The old-style forwarder is out of business as soon as the real
sender and the next hop do SPF -all : _all_ mails are rejected
by the next hop, and the sender will stop to send any further
mail to the corresponding forwarded address, until the receiver
has fixed his mail setup.
Therefore all further bounces from this "forwarded address" are
caused by forgeries. They go to nanas and abuse(_at_)forwarder, it
is his problem, if he refuses to fix it he will be blacklisted.
And if the forwarder supports SPF we're back at square one, the
zombie can't send mail to the forwarded address, no bounce, no
problem.
Of course the zombie can use its own throw-away domain with a
sender policy resulting in +all. But then a potential bounce
won't hit any innocent bystander.
It can be deployed any way anyone wants. Whether there will
be side effects is another story.
"SPF breaks forwarding to third parties" is only the executive
summary. The truth is that a sender policy simply lists IPs of
border MTAs used for HELO domain resp. MAIL FROM:<user(_at_)domain>.
It's IMHO obvious that the receiver can check these IPs only at
one of his border MXs, not later in his routing. "Forwarding
to third parties" is only one special case of any "later in his
routing". The essence of SPF is KISS.
to be pedantic, that's the whole *point* of MAIL FROM
checking: to know who is using your domain name in MAIL FROM,
and to control their use of that name.
Ideed. And it's the receiver who can control it, if he wishes
to control it. But he can only control it at his border, not
somewhere else in his routing (= later in his forwarding).
EHLO validation is orthogonal to MAIL FROM validation, for
the simple reason that they're separate fields, and there's
not requirement for the same domain name to appear in both.
If the HELO domain is also used in a MAIL FROM:<user(_at_)domain> -
not necessarily by the same MTAs - then it makes sense to join
the sets of corresponding IPs in one SPF sender policy for all
receivers using SPF to control their borders.
You could also combine it with other schemes, and if the other
scheme says "bad HELO" skip all SPF tests and reject all mails.
If the other scheme says "good HELO" you could skip SPF HELO
tests (that's not explained in the SPF draft, it's obvious ;-)
but still do SPF MAIL FROM tests.
Bye, Frank