These are some of the major visible architectural differences (aside from the differences relating to inhibiting unsolicited bulk mail) between SMTP-based Internet mail and IM2000 Internet mail.
Forwarding in SMTP-based Internet mail is described in RFC 1123 section 5.3.6. Forwarding takes one of two forms, one which retains the original envelope sender mailbox and one that does not.
Forwarding in IM2000 is different in three ways:
IM2000 is not a "push delivery" system. The common SMTP-based MTS mechanism of having "system aliases" and "~/.forward files", where a receiving MTS pushes received mail back out to other mailboxes, has no direct equivalent in IM2000. (The common uses for these mechanisms are achieved in other ways. A simple "exploder" mailing list implemented as a "system alias" in an SMTP-based MTS is implemented as an ordinary mailing list in IM2000 using the mailing list mechanism that IM2000 explicitly has.) In IM2000 MTSes don't have mail "pushed" onto them that they then forward by "pushing" onto other MTSes.
In IM2000 the "source" information in a message envelope indicates where (i.e. in what message store) the message is located. In SMTP-based Internet mail it is possible to rewrite the envelope sender mailbox of a message during transport. In IM2000 Internet mail, rewriting the envelope "source" information of necessity implies submitting the message to a new message store.
IM2000 is not a "store and forward" system. In SMTP-based Internet mail it is possible for intermediaries to rewrite the envelopes of messages as they transit the system, changing the sender and recipients. IM2000 does not permit intermediaries to rewrite message envelopes, because there are no intermediaries in IM2000.
In IM2000 forwarding is thus done by user agents. In order to forward mail to other mailboxes recipient MUAs either
SMTP-based Internet mail is a "store and forward" system, and the envelope sender mailbox of a message is the reverse path to which transport and pre-delivery processing errors are sent. Delivery status notification messages ("bounce messages") are sent by intermediaries and by delivery agents. Originators rely upon these others to send "bounce messages" back to them, which they do in a variety of formats.
IM2000 Internet mail is not a "store and forward" system. Mail does not traverse a path to be delivered, and there are no such things as "bounce messages" that travel back along that path.
In IM2000, delivery status information is maintained directly at the originator's message store without reliance upon any parties at the recipient end, is available in a standard form, and is inherently maintained as part of the communications protocols.
SMTP-based Internet mail is a "recipient stores" system. Recipients maintain, and pay for, the storage for their mailboxes. Recipient mailboxes are stored in one single central place.
IM2000 Internet mail is a "sender stores" system. The storage for each individual part of a recipient's mailbox is maintained, and paid for, by the originator of the particular message involved. Recipient mailboxes are distributed across one or more message stores.
Expressing these in terms of a folder-based MUA:
In SMTP-based Internet mail, every recipient provides their own In box and a sender's Out box is distributed across the storage paid for by all of the various recipients for each message.
In IM2000 Internet mail, a recipient's In box is distributed across the storage paid for by the various senders of each message and every sender provides their own Out box.
In SMTP-based Internet mail, the actual communications protocols, SMTP Relay and SMTP Submission, require several round trips per mail transaction. (The "pipelining" extension ameliorates this to some extent, but in its turn complicates the implementations of both servers and clients, which have to deal with complex rules for response batching and deadlock avoidance, respectively.) Further round trips are incurred by largely useless protocol chaff, and by the client having to wait for the server's greeting banner.
In IM2000 Internet mail, there's no "relay" protocol at all (of course); the message submission protocol usually incurs just two round trips, one for the message envelope and one for the message data (reducing to one round trip in the event of an envelope error), per message submission; and there is no greetings banner, allowing the client to start sending a command immediately after the connection has been opened.
SMTP-based Internet mail is a "store and forward" system, with each "hop" on the path that a message traverses from originator to recipient recorded in one or more "trace" header.
IM2000 is not a "store and forward" system. Mail does not traverse a path to be delivered, so there is no path to be traced in the first place.
Only in two places are trace headers even appropriate in IM2000:
Recipient MUAs may add trace headers, indicating whence the message was obtained from, when they take over storage responsibility for messages by copying them to their local storage.
Message stores may add trace headers, indicating the location of the originator, when they accept submitted messages.
In SMTP-based Internet mail, mailing lists are mailboxes; mailing list subscriptions are not handled by MUAs; and there is no distinction, directly visible to an originator, between a mailbox that is a mailing list and any other type of mailbox. Originator MUAs can do useful things (such as pick appropriate default Mail-Followup-To: values) if they know which mailboxes are actually mailing lists. But originator MUAs have no guarantee that they will be told this information.
In IM2000 Internet mail, mailing lists are not mailboxes, and mailing list subscriptions are handled by MUAs. Recipient mailboxes indicate recipient notification agents, whereas mailing lists indicate message stores. Originator MUAs know, because they have to know (in order to know which message store to submit any mailing list messages to), about all of the mailing lists to which an originator is subscribed for writing. Mailing list names and recipient mailbox names are two distinct and separate namespaces.
On MTSes for multi-user systems, such as Unix and Linux, parts of SMTP-based MTSes have to have superuser privileges:
SMTP-based Internet mail is a "recipient stores" system. Storage for recipient mailboxes is owned by the individual user accounts on the system. The part of the MTS involved with delivery has to have superuser privileges in order to be able to switch to running under the aegis of the appropriate user when delivering to his/her mailbox storage and invoking his/her delivery instructions.
SMTP-based Internet mail also uses TCP port numbers in the "privileged" range, with well-known numbers. Only privileged user accounts may bind sockets to such ports. The parts of the MTS involved with providing TCP services have to have superuser privileges, at the very least until they have opened a socket and bound it to the well-known port number.
On MTSes for multi-user systems, such as Unix and Linux, no part of an IM2000 Internet mail system requires superuser privileges:
IM2000 Internet mail is a "sender stores" and a "pull delivery" system. Recipient mailboxes are not stored in local storage at all, and there is no separate part of the MTS with the task of performing operations on mail, that has been "pushed" to it, under the aegis of individual users. There is therefore no part of the MTS that requires superuser privileges in order to switch user accounts. Moreover, the transfer of mail from a recipient's mailbox to local storage is done by the recipient's MUA, which is invoked by the recipient and thus already runs under the aegis of the correct user account for accessing the user's storage space and invoking the user's delivery instructions.
IM2000 Internet mail does not use well-known port numbers, and imposes no requirements that the TCP port numbers for its various services be in the "privileged" range. IM2000 simply has no need for well-known port numbers:
Therefore the parts of the MTS that provide services need not have the superuser privileges required to bind sockets to TCP port numbers in the "privileged" range.