ICANN opens up Pandora's Box of new TLDs
mpetach at netflight.com
Sat Jun 28 15:12:39 CDT 2008
On 6/28/08, Rich Kulawiec <rsk at 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
More information about the NANOG