On 6/28/08, Rich Kulawiec <rsk@gsp.org> wrote:
On Sat, Jun 28, 2008 at 06:18:44PM +0200, Phil Regnauld wrote:
Rich Kulawiec (rsk) writes: ... And given that any estimate of hijacked systems under 100 million is laughably out-of-date, it's a best practice to blacklist ALL such IP space and namespace pre-emptively. There's no point in waiting for evidence of abuse to show up: it's inevitable. End user systems should either be using their designated outbound mail relays *or* submitting on other ports with authentication.
Probably bounces will be the next thing to disappear.
Bounces *should* disappear, since it's a best practive to always reject (during the SMTP conversation) and never bounce. Failure to do so leads to outscatter, which is spam, and to blacklisting of the emitting hosts.
Those two statements of yours directly contraindicate each other. If end user systems should use outbound mail relays, then the relay system is the one accepting the mail from the mail client, and will be responsible for sending out to the end system; it cannot make a determination as to whether the mail will be deliverable or not during the SMTP conversation with the client machine; it will only find out if the mail is actually deliverable when it in turn goes to establish an SMTP conversation with the receiving system, at which point if the receiving system indicates the message will not be deliverable, there is no way other than by generating a bounce message for the relay system to notify the original sender that the mail was undeliverable. Or, are you proposing that outbound mail relays hold the *client* connection state in limbo until they establish an outbound connection to the final destination, determine the deliverability of the final recipient, and *only then* acknowledge receipt of the message back to the client machine? If so, I think you may hear the distributed sound of every operator of outbound mail relay systems for ISPs of any scale *plonk*ing you in their "clueless" bucket. ^_^; In case it wasn't clear, a relay system like that simply won't scale at all, as the number of simultaneous pass-through connections required would increase as the ability to batch-process sending to common recipient systems would drop to near zero, End users would quickly cry foul and abandon operators who attempted such a system, as it would mean a slow-responding MTA box at the recipient end would hang their mail client as it waited to hear back from the relay host as to whether their attempt to send mail had succeeded or not. Until the entire concept of SMTP is replaced with something drastically different, along the lines of a real-time message passing system closer to IRC or IM, bounces are the only means for notifying a sender that a message could not be delivered. Matt