David Woodhouse <dwmw2(_at_)infradead(_dot_)org> wrote:
There's no problem with the current design. In general it's not hard.
Either the spammer is sending mail via the ISP of the zombie machine,
which ought
... to do a lot of things, but often doesn't.
to be doing some kind of check on outgoing mail from their
customers, or often they try to connect directly to an MX host of the
domain to which they're trying to send, which ought to reject anything
the primary MX would reject.
And what about relays? Forwarders?
You're assuming that messages go from source to destination in one
hop. While this is nice, the current design allows a message to
traverse multiple independent hops, all the while using the same "MAIL
FROM". This has a serious impact on the "blowback" problem, and any
possible solution.
This is why you should always have MX backups which are capable of
rejecting mail to unknown users at the domain, for example.
Ideally, yes. This can be difficult to do in practice.
Anything _can_ be difficult to do in practice, if you make enough stupid
decisions along the way. Setting up an MX backup competently can be
_trivial_ to do in practice too.
Yes, but sharing live information about all of your users with a
backup MX is difficult to do in practice. Spammers leverage the fact
that backup & primary MX's have different pools of information to
convince the backup MX to deliver messages that the primary might have
rejected.
If nothing else, the spammers are offloading some of their work onto
the backup MX, and using it to attack the primary. This attack has
serious consequences for the robustness of the email transport layer.
Alan DeKok.