Re: IM2000 Won't Be Worth It

>The main arguments seem to be that it would somehow reduce spam,
>without there being any clear picture of precisely *why* it would do
>any such thing, and that message bounces are somehow inherently bad,
>again without any clear explanation of *why* bounces are bad and what
>we would have instead.

Bounces are bad because they are heavyweight responses to lightweight
stimuli.  Generally, any system with such a characteristic is highly
prone to breaking down under certain forms of stress; so, successful
systems with such a characteristic tend to employ it in very
restricted situations.  SMTP email does not do so.

It's easy to see how this is true for traditional bounces, which
contain the entire original message, plus some additional stuff.
*Any* email submitted to *any* arbitrary address, which is not
ultimately accepted for delivery, can therefore result in an even
*larger* message being generated and delivered.

So a system that, for reasons relating to being overwhelmed with work,
fails to deliver a given message, must somehow find the time and
energy to create and deliver an even-bigger message in response to
that failure.

Within the SMTP email paradigm, there are two practical ways to
mitigate this problem:

  1.  Reduce the size of the bounce message, by not including the
      entire original message.

  2.  Reject the email during initial submission via SMTP protocol.

#1 implies that the sender must keep a copy of the original message
anyway, and be able to easily correlate an incoming (incomplete)
bounce with that message in order to attempt redelivery by some other
means.

Since the simplest method of correlation involves generating a unique
(local) message ID when sending the message in the first place, and
getting that ID back in the bounce, the "ideal" SMTP bounce message
would contain little more than that ID.

Unfortunately, to my knowledge, there's no SMTP-ecosystem-wide
guarantee that a bounce will contain the original message ID.
Certainly I've received plenty of ID-free bounces for messages I did
not send (bounces that would say "virus detected and removed", and
little else).

Anyway, once senders understand that all they really want is a
notification with a message ID, and have MUAs that handle that sort of
thing, they'll be well along the path to wanting to make inquiries
based on an outgoing transmission ID as well.

#2 works only as long as important characteristics of the SMTP
store-and-forward mechanism (generally, beyond just the specifics of
SMTP-protocol-level store-and-forward) are no longer in play beyond
that initial submission.

But, with SMTP email, since there's no canonical way to inquire as to
the status of outgoing messages, there's no reliable way to determine
that any given message has actually reached the final MUA for a
recipient, since failure involving final delivery can always (though,
ideally, rarely) involve failure modes that prevent bounce generation.

In other words: relying on receiver-side notification of failure to
transmit or deliver a message is a poor design decision from the
get-go.  Allowing (versus relying on) receiver-side notification of
success or failure isn't so bad, as long as sender-side inquiry as to
status is always an option -- in that scheme, it's more of a push
vs. pull decision, and sometimes pushing status notifications back to
a sender can be more efficient than having the sender repeatedly
request (pull) them.

(Of course, delivery can succeed and yet the system can subsequently
fail to notify the sender of success, either via receiver-side push
notification a la DSN or sender-side pull a la tracking, but it's
usually better for a messaging system to use this "make before break"
approach to delivering before notifying than the SMTP's present "break
before make".  That is, I'd rather be erroneously under the impression
that a delivery failed than that a delivery succeeded, in most cases.)

-- 
James Craig Burley
Software Craftsperson
<http://www.jcb-sc.com>