Re: A new SMTP "3821" [Re: FTC stuff...........]
"Alan DeKok" <[email protected]>
| Newsgroups | gmane.ietf.mxcomp |
|---|---|
| Message-ID | <[email protected]> |
David Woodhouse <[email protected]> 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.