The fundamental problem with SMTP electronic mail and unsolicited bulk
mail is that it is cheap for senders to make copies of and to transmit
messages, putting senders at an advantage with respect to recipients.
The SMTP mail architecture is confounded by this.

It is interesting to note that the SMTP electronic mail architecture
inherits this weakness from the postal mail architecture, and that were
copying and transmission as cheap for postal mail as they are for SMTP
electronic mail the postal mail system would also suffer from the very
same problem of unsolicited bulk mail.

(Indeed, it is worth noting that when computer telecommunications are used
to distribute the cost of generating and transmitting postal mail across
large numbers of senders, effectively reducing the costs to the same
levels as with SMTP electronic mail, this very problem is readily
demonstrable with postal mail,
as Alan Ralsky found out
.)

By contrast, the IM2000 mail architecture takes advantage of
the fact that senders have low copying and transmission costs, by
having an architecture where messages are sent to recipients from
message stores on demand, and where message notifications to recipients
are discardable.

Some IM2000 proposals contain the assumption that everyone will want their
message stores and their recipient notification agents to be run by the
same company that provides their IP connectivity. Such assumptions have
knock-on design consequences that make public mailing lists unfeasible.
They also prevent both the existence of "roaming" users and the
possibility of users shopping around amongst multiple service providers to
get the best services, by locking people into their ISPs.

Some IM2000 proposals have recipient notifications carrying all sorts of
stuff that is specified by the message originator, such as the message
subjects and other headers. This provides a trivial covert channel for
the senders of unsolicited bulk mail to subvert the system, by (for
example) simply moving the entire message into the subject.

In these proposals, nothing in the recipient notification that
reaches the recipient MUA is directly specified as part of the message by
the message originator.

To achieve the same ends that the other proposals attempt to achieve by
their inclusion of message headers in recipient notifications, these
proposals provide a mechanism for recipient MUAs to fetch only the
"summary" headers for a message from message stores.

(Collusion between message stores and malicious originators to send all of
a message anyway, when only summary headers are requested, can only waste
bandwidth, since good recipient MUAs will only process the "summary"
headers and ignore any others sent, and will only do so where recipients
actually decide to find out more about the message from the message store
in the first place, which will not occur often for malicious message
stores given that the the primary weapon against them is to have recipient
notification agents ostracise them.)

Computers speak protocols, not humans. Humans use tools to translate
protocols to human-readable form. The IM2000 protocols are designed to be
simple and unambiguous for computers to parse.

The design of SMTP was influenced by the concept of using the TELNET
program as an SMTP client. This lead to such mistakes as the
help and quit verbs, and the initial greetings
banner. Also, the protocol was specified in terms of human-readable
commands and responses, leading to such problems as

ambiguity over the inclusion of whitespace in commands,

difficulty in the imposition of structure on responses when needed,

ambiguity over whether providing arguments to commands that had no
defined parameters was erroneous, and

high internationalisation hurdles.

TELNET is not intended to be a client for any of the IM2000 protocols.
The protocols are designed primarily to be machine-readable, using
encoding rules designed for simple, flexible, and unambiguous binary
protocols.

If it's good enough for the DNS protocol and LDAP, it's good enough for
IM2000.