Some observations on the IM2000 proposal and spam

as documented at

Author: Brian Candler
Last updated: 2005-04-13

1. Costs?

JdeBP's IM2000 proposal claims to shift the cost burden associated with spamming: "recipients no longer bear the costs of receiving and storing unwanted mail ... Senders bear the costs of storing the mail that they send." The implication is that in an IM2000 world, spamming will be a signficantly more costly activity than it is now.

However, this assertion doesn't stand up to scrutiny. Remember that spammers are free to write their own IM2000-compliant spam senders (just as they write their own 'pump and dump' SMTP senders now).

It appears to me that the IM2000 world actually makes spamming much cheaper than it is today. If I were a spammer, I would create an IM2000 mail store which holds just one copy of my message. It would then send out notification messages to many millions of recipients (using different sender IDs for each one, just to obfuscate things). Each recipient who got my notification could then choose to pull a copy of it from my mail store. My bandwidth costs have been minimised - by not sending out copies of the message which may end up never being read, for example because they arrive in inactive mailboxes.

Furthermore, by giving different opaque keys to each recipient I can track who exactly has received the mail, which will be very useful indeed for my followup spamming and when sharing lists of addresses with my fellow spammers.

Using a network of "0wned" machines, each containing one of these message stores, would reduce the bandwidth used even further, and make it much harder to trace the spamming back to me. The 0wned machines will typically have an account on the upstream ISP's message store, and will be able to send out messages via that too. From this point of view, IM2000 is positively a spammer's nirvana.

In any case, the primary cost associated with spamming is not really the storage and transfer. It's the annoyance factor of having to scan through and delete spams just to find the "good" messages in your inbox, and the ever-present danger of overlooking or deleting a good message because it was lost in a sea of spam. The other costs are the complexities and time wasted for setting up and maintaining filters, the damage that false positives do, and the damage done by badly-setup filters at other ISPs which you have no control over, when you are trying to communicate with someone at that ISP.

2. Actual advantages of IM2000

Having said that, the proposal does have some real advantages in the fight against spammers, which the author does not explicitly list.

2a. The current world depends primarily on ISPs handling abuse complaints promptly and correctly. If I see spam relayed via, I contact with a report of the spam. They read this, and should act on it. They should check the Received: headers (a manual process, because the spammer can add their own forged Received: headers) for the source IP address of the message. They then cross-reference to RADIUS logs to find out the user account ID of the sender. They should then cancel the account.

In practice, this process takes so long that the spammer has moved onto another account by then; or the ISP just gives them a "warning" because the ISP doesn't want to lose revenue. Most likely of all, the ISP cannot afford the resources needed to handle abuse complaints correctly, and so deals with them sporadically or not at all. Language difficulties communicating with ISPs in foreign countries make things worse.

In the IM2000 world, the [mailstore, sender ID] tuple is available to the message recipient, and therefore can be looked up in a blacklist. The "account cancellation" process can therefore take place by a trusted third party, that is the blacklist maintainer. Furthermore, you have a choice of which blacklist(s) you wish to subscribe to; unfortunately, you don't have a choice over which ISP the spammer uses, and the spammer is most likely to choose an ISP who doesn't deal with abuse complaints properly.

A well-run blacklist will block [mailstore, spammer-sender-ID] without blocking other accounts using the same (shared) mailstore, thus minimising collateral damage.

Of course, if the spammer is running her own mailstore (or is running multiple mailstores on 0wned machines), then the 'sender ID' can be faked up or new accounts created at will. In that case, you blacklist the entire mailstore by IP address, just as current RBL blacklists do for SMTP sources.

2b. Systems which allow you to signup for free accounts which are instantly able to send mail - such as "hotmail"-style webmail systems, or ISPs which offer free trial accounts or free dial-up accounts - are always likely to be abused by spammers.

However, IM2000 makes it easy for message stores to limit the number of outbound E-mail notifications sent in a period of time, or the total number of different recipients sent to in a day. A well-run free ISP service can therefore limit spammer activity to a trickle. A badly-run free ISP service will find its message store blacklisted.

2c. When a receipt notification arrives, in the IM2000 world you don't actually download the mail until the MUA connects. For those users who only check their mail periodically, this gives time for a spammer to get blacklisted. By the time they check their mail, the notification may already have been invalidated.

This is a real advantage over the SMTP world, where the spam has already been delivered into inboxes. If it takes 4 hours to send a million spams, but 6 hours to notice that the spam has occured and to track it back to source, the damage has already been done. However, in the IM2000 world if the source is blacklisted in 6 hours, anyone who checks their mail after that point won't see it.

2d. Suspected spam sources can be "greylisted" - that is, receipt notifications from unknown senders are held in quarantine for, say, a few hours. This could be done by local policy at the MUA (for messages from an unknown sender), or as a response from a blacklist. This gives time for a spam attack to be detected and analysed and the sender blacklisted, which will always require some human intervention to be 100% accurate.

2e. If you subscribe to a blacklist, you will send it lookups for [mailstore, sender ID] tuples for each message you receive. This will give the blacklist excellent quality information to assess the number of messages sent from each mailstore, and sent from each sender account on that mailstore.

This can be used to trigger systems which automatically detect a potential new source of spam, rather like 'spamcop' or 'DCC' in the current world, but in a much more reliable manner.

The IM2000 world eschews public mailing lists in favour of 'pull' message stores. Therefore, there are much fewer legitimate sources of bulk E-mail; a shopping service sending out receipts to the sales it handled that day would be one. The blacklists can learn who these legitimate bulk senders are, and penalise anyone else who suddenly starts sending in bulk.

2f. Perhaps most importantly of all, blacklists can have real, undeniable proof of spamming, straight from the horse's mouth so to speak.

It would work like this: if you get a receipt notification for something which you suspect is spam, then (without downloading the message) you forward the receipt notification to a blacklist agency, including the opaque key which will allow it to download the message. The blacklist can download it, and apply some preliminary automatic filtering to assess if it's likely to be spam. If so, a human being at the blacklist agency can read it, decide if it is spam or not, and add to the blacklist if it is.

The blacklist agency downloaded the message directly from the spammer's message store, and did it using an opaque key which could only have been created by the spammer's message store. This is undeniable proof that the spam originated at this message store account. As a result, blacklists and law-enforcement agencies have real proof that they can use in court, and blacklists will be more reliable. Furthermore, you can't send a faked abuse report to attempt to blacklist an innocent third-party.

Notice I said that the recipient cannot download the message before passing the notification onto the blacklist agency. This is because a spammer's message store could be written to delete the message as soon as it has been downloaded - without waiting for an 'un-pin' request from the recipient as the protocol requires - thus destroying the evidence. Or worse, an offensive or illegal message could be replaced by an innocuous one after the first download has taken place. (Including a hash of the message in the notification would counter this, and has other advantages outlined below).

This means that you can only reliably submit a particular spam incident to one blacklist. However I don't see that as a problem - the whole point of spam is that there's plenty of it to go around :-) Besides, blacklists are free to share this information with each other.

It also means that you can only reliably report a spam using the information available to you in the receipt notification itself and/or the message headers if you download just these, but not the message body.

These constraints only apply if the mail comes from a mailstore set up specifically for spamming. If the message was deposited in a trustworthy ISP's mailstore, then simply reading it will not cause it to be unpinned or altered.

To work properly though, the MUA needs a "report spam" button which will forward the original receipt notification/opaque key to a spam collector.

2g. Just as now, "spamtrap" mailboxes can be set up to detect a spam attack. The idea is that these are not real mailboxes, but their addresses are publicised in the hope that spammer will add them to her E-mail address list.

However, if you don't mind the privacy implications, you could pass on all your incoming receipt notifications to a blacklist agency to scan before retrieving them yourself. This might be because:

Blacklists who process notifications in this way will get early warning of the start of a new spamming attack, so they can respond quickly. In principle they could also generate statistical information on mailstores and senders which generate NON-spam, thus making them less likely to be blacklisted wrongly. Building up trust in this way, however, depends on spammers not being able to abuse the system (e.g. by setting up two domains of their own and sending mail back and forth between them). So I think it's better to analyse the message sources by hand, using DNS, IP registry information and out-of-band communication to establish whether a particular IP address really is (for example) a shared message store at a legitimate ISP.

The benefit to the individual passing on their message notifications in this way is that they get their mailbox swept; the benefit to the net as a whole is that the blacklists get updated much more quickly in response to new spamming incidents.

Blacklists can run their own spam-filtering rulesets to identify potential spam attacks, which can then be flagged to a human for an action decision: blacklist the message store, blacklist the [message store, sender ID] tuple, or accept. These filtering rulesets are private to the blacklist maintainer, invisible to the spammer, and most likely different for each blacklist. This is a huge advantage over the world where everyone runs programs like 'SpamAssassin' on their inbox; the source code to SpamAssassin is publicly available, and therefore spammers can tailor their messages to pass the spam tests.

2h. Sending spam from a message store on a dynamic IP address is likely to be less effective, given that the message store must be on-line at the the time the recipient decides to collect the mail. To make it work you would need your message store SRV records to be held in a dynamic DNS hosting provider. Any DNS provider which did that, and which allowed spammers to sign up for unlimited subdomains, would likely find itself blacklisted too.

This is a consideration for blacklist design though: if I receive spams from sender message stores, and, I may wish to blacklist those three message stores separately, or just blacklist *

2i. Given the efficacy of sender blacklists in an IM2000 world, I would hope that content filtering (the most unreliable of tools for identifying spam and the one most easily bypassed by spammers) should become completely unnecessary.

In summary: all the ways being used to try to deal with spam today are still available in the IM2000 world, but each is made more effective. As long as IM2000 includes the ability to use blacklists from day one, it should be a difficult environment for spammers to work in, and the damage they do can be minimised.

IM2000 will still rely on the good people who run public or pay-for blacklist services if we want our mail to remain relatively spam-free. Those blacklist services will still be at risk of legal threats, violence and bullying from spammers, and lack of funds, just as they are now.

However, spammers will be hard pressed to deny that they sent the spams in the first place. The question then boils down to one of consent: "these people all agreed that we could send them bulk E-mail". Many spammers buy in lists of E-mail addresses, believing that simply the presence of the address on a list means that consent has been obtained. Hopefully, legislative regimes will mean that it will be up to each individual spammer to prove that consent was obtained for each and every address on the list - which most spammers will be unable to do.

3. Separate sender and recipient identities

IM2000 separates the identities of a sending entity and a receiving entity (the latter being the well-known "E-mail address"). I can see a number of problems with this in practice, which will very much weaken the case for switching to this protocol.

3a. An incoming message notification is a tuple of [user ID, message store ID, notification source address]; using one of JdeBP's examples, we have

from toby on says
     ^^^^    ^^^^^^^^^^^^      ^^^^^^^^^
The tuple <toby,> is what people are likely to associate as a "sender E-mail address", i.e., even though the new architecture specifically divorces sender message store accounts from E-mail addresses for receiving mail.

There is also the likelihood that operators of VISP services will include domains within message store user IDs. e.g.

  from on says
       ^^^^^^^^^^^^^^^^^^^^^^    ^^^^^^^^^^^^^^^^^
(where domain "" has SRV records pointing to's message store); or else
  from on says
       ^^^^^^^^^^^^^^^^^^^^^^    ^^^^^^^^^^^
Putting the mailbox ID in that form is attractive because it gives a separate user ID namespace for each virtual domain. I think it's almost certain that this practice would occur, but then I think the typical end-user is unlikely to be able to interpret this information in a way to avoid phishing attacks, especially given that receipt notifications can identify the message store by IP address:port and not by domain. For example:
  from on says
or worse,
  from on [] says
It seems to me that we are actually doing a disservice to most users by presenting the information in this way. That information is hardly any better than what we have now, which is a combination of Return-Path:<> and Received: from In other words, IM2000 is not really any more immune to "phishing" attacks that the current mail system.

At very minimum, I believe the option to send a receipt notification in [IP:port] format should be removed. This forces you to at least own and control a domain (or a sender mailstore account at a domain) if you are going to send an E-mail. It also means that a spammer with a network of 0wned machines is going to have to list them in the DNS:

  from on says
This allows blacklisting message stores *, which may be more effective and faster to respond than blacklisting by IP address alone. It might ultimately force a spammer to register a whole new domain for each bot, pushing up her costs.

However there are other, stronger options. One I considered was to present instead a hash of the user ID and message store ID, and call it a "sender fingerprint":

from unknown [f8:1e:26:80:96:c9:54:e4:60:8f:32:bd:78:ee:5d:53] says
(that's an MD5 hash of "\")

Once you've received a particular message and believe it's genuine, e.g. by successfully sending a reply, you could tell your MUA to remember the fingerprint and associate it with a label to display instead of the fingerprint in future. These fingerprints could be included on business cards, letterheads etc. They might also be used in blacklist lookups, as they reduce the privacy implications of showing the blacklist the actual sender identities of everyone you receive mail from.

Another alternative might be to publish, in the DNS for example, bindings between E-mail addresses and sender accounts. For example, if you receive a mail purporting to be "From:", you would do a lookup on
and find a list of [message store, account ID] tuples that I use to send mail. If you find a list but the originating message store account isn't among them, then you know the message is forged. Unfortunately, you won't see "From:" until you've downloaded at least the sender's message store, and that retrieval already gives information to the spammer that your account is active.

However, unless it becomes common practice to set up such bindings, most IM2000 E-mail will be of questionable origin and an MUA will not be able to flag forged mail reliably.

3b. It should be noted that a single message store account may be shared between several people who send you mail, and therefore the identity of the sending message store account may not be enough to uniquely identify the person sending you the mail.

I can think of three common cases where this may happen:

(i) As a migration measure, you have an incoming SMTP MX gateway to allow you to receive mail from the rest of the Internet (that is, those who are not IM2000-capable).

In this case you would point MX records for your own domain at a gateway message store; it will receive the incoming mail, store it, and then start sending notifications to your receipt notification agent. They will probably look like:

   from smtpgateway on says
i.e. all non-IM2000 mails will appear to originate from the same message store in the notification messages you see.

(ii) If you are a business running an internal SMTP mail system (let's say a Microsoft Exchange server for the sake of argument), and you configure it to send all outgoing mail via your own IM2000 SMTP shim, or via your ISP's mailstore shim authenticated using SMTP AUTH and a fixed username and password. In that case, it's probable that all outgoing mail from everyone in your organisation will appear to originate from a single IM2000 mail store.

(iii) People may choose to share a mailstore, for ease of configuration. For example, a family living in the same house may set up all their outgoing mail to go via the same mailstore account at their ISP.

So actually, the sender mailstore ID is not always usefully tied to a single individual.

3c. At the end of the day, the receipient is not interested in "which message store account did this message originate from", but

I'm coming to the conclusion that although IM2000's separation of sender identities and recipient identities has an appeal to those who like the world to be orthogonal, it's not actually useful to real world users. For them, it would be better if the sender mailstore ID and the recipient mailstore ID (i.e. E-mail address) were the same thing. What use is it to receive a mail from account 'brian123' on message store '', if that doesn't tell you reliably what address to send a response to?

It would be straightforward enough to combine the two. Instead of sending notifications which say

  from toby on says
they could say
  from says
The sender's mailstore would be found using a DNS SRV lookup on, and '' plus the opaque key would be used to retrieve the message. Using the proposed IM2000 protocols it would still be up to the ISP to ensure that the receipt notification agent account for "" was accessed by the same person as the mailstore account "" - e.g. by using the same database of usernames and passwords.

There's an end-user concern here. If when you send a message it publicises your return address, you want to be reasonably confident that anti-spam provisions in IM2000 are strong enough so that doesn't cause you a problem; that is, if someone harvests your address, they are unlikely to abuse it. Otherwise people will end up setting up throw-away accounts just for posting to mailing lists etc (which of course happens now).

4. Mailing lists

In the IM2000 world, it's proposed that mailing lists are held on a shared message store, with either public (fully anonymous) write access to add new messages, or with a requirement that you login to the mailstore with a username/password to write new messages.

If you want the public to participate in your discussions, then even if you require a username/password then you will have to have a signup page which lets new accounts be created, so this is effectively the same as full anonymous access. There are some very obvious flaws to this model.

4a. Spammers will fill these message groups with spam, just as USENET is now. Although there is not a central repository of group IDs as USENET has, spammers will easily be able to collate lists of anonymous-write mailing list message stores, and of signup pages (or usernames/passwords) for other public message stores. They are bound to fill up with spam, as surely as USENET is crippled by spam.

4b. As anyone who has run an FTP server with public-write 'incoming' directory will know, these services will also be discovered by people distributing warez and porn.

I used to work at a large ISP, which allowed signups for free Internet accounts with POP3/webmail mailboxes. Those mailboxes had small quotas (10MB each). However, once people on the Internet discovered this service, they wrote scripts to sign up in bulk for accounts; they broke their CD ISO images into 10MB chunks, mailed them to each of the accounts, and then distributed the POP3 usernames and passwords to their friends. Hey presto, we were unintentionally providing a free file distribution service.

IM2000 mailing lists will need protection against this sort of abuse, at least until a human being can come in and cancel all the crap. It may be that the workload of cancellation may become too high for a human to deal with, in which case the list becomes useless.

4c. IM2000 mailing lists make both sorts of abuse far too easy, and the reason (IMO) is that the senders are completely unauthenticated and therefore essentially anonymous. They can keep coming back and spamming again.

I think to make mailing lists work in the IM2000 world, they have to come from authenticated senders, which means a two-step posting process: the poster submits the message to the mailing list as a personal mail, and then the mailing list copies it to a local message store.

That is: if I am, sending to, then:

  1. I put the message in my own message store (
  2. It sends out rcpt notifications to
  3. The list robot downloads the mail from my message store, and inserts it into its own message store, from where people can read it.
Using this approach, the sender is authenticated, and can therefore be blacklisted. Greylisting (= moderation) can be used for senders who have not been seen before.

4d. The IM2000 central-store mailing list also doubles as a mailing list archive of course, but such archives are not particularly useful unless they are searchable. Unless the IM2000 protocol provides for server-side searching (and ideally threading), then there will still be a requirement to make such mailing list archives available through a database-backed web interface.

5. Write-only mailstores

The IM2000 message store is (by design) a "write only" mailstore. However, there is an entirely separate requirement in the real world for having server-side storage of mail folders, for users who roam between different client machines but wish to have access to their previously-received mail. In current practice this is fulfilled by IMAP servers, by webmail services (some of which are front-ends to IMAP servers), and by proprietry mail store protocols.

IMAP is an extremely nasty protocol, and if an IM2000 message store could replace it, that in itself would be a big plus for IM2000.

To do this would involve making IM2000 message stores read-write, allowing messages to be associated with folders, and adding searching/threading as already suggested in (4d). I outline this proposal some more below.

6. Junk receipt notifications

Some thought is needed to the problem of junk receipt notifications. These will be just an annoyance, but could become a very large one (firstly because you will have to filter through them, and secondly because the receipt notification agent may be filled up with them)

6a. It is possible for the RNA to check the existence of the message by performing a callback to the sending message store, before recording the notification. That is probably the best solution, although an attacker could still cause wasted resources of callbacks to random third-party message stores. Some people seem to be opposed to the concept of callbacks in the first place, saying it's "too expensive" in the SMTP world.

6b. It would also be possible to associate a list of possible notification senders with the sending domain in the DNS, a la SPF. I'm not sure I like this, and there are advantages in being able to forward receipt notifications on to third parties such as spam or virus scanning agencies.

6c. It would be possible to maintain separate blacklists of receipt notification senders, but they would be unlikely to be effective in a dynamic IP world.

6d. Otherwise, I cannot see a solution except using public key cryptography to sign the receipt notifications, with the keys held in the DNS. Generating and checking signatures on these notifications is likely to be more expensive (in CPU rather than bandwidth) than callbacks.

7. Forwarding addresses

As a user of one of those "E-mail address for life" forwarding services (, I was wondering how these type of services might work in an IM2000 world.

I can see at least six distinct alternatives for what happens when someone sends mail to, which in today's world I want to be forwarded to

1. Nothing is forwarded at all; I configure my MUA to subscribe to a Receipt Notification Agent service at In today's world, that would be a bit like providing me with a POP3 mailbox instead of a forwarding service.

2. An RNASP notification arrives at the server, which replies with a message saying "not here: resend to instead". The sender then starts sending notifies to that new address too. (Note: potentially could send back a list of more than 1 address to forward to). However the current IM2000 proposal doesn't have a feature to do that.

3. An RNASP notification arrives at the server, which modifies it (changing "" to "") and resends it to the recipient notification agent for - or potentially several RNAs if I wanted the mail forwarded to several places. This would happen for each RNASP packet coming in; no state would be kept.

This relies on the RNA accepting incoming receipt notifications from any IP address, and might collide with some of the mechanisms needed to cope with junk notifications listed above.

4. An RNASP notification arrives at the server, which then downloads the message from the sender's message store using MSRAP, and then sends it on as a fresh message; that is, sending out RNASP packets to the new recipient(s) notification agent(s), who would then retrieve the message from the server. Note that the message itself has actually gone through a layer of forwarding here, so this seems against the spirit of im2000 (we get into the field of Received: headers for debugging this sort of stuff, mail loops, and so on)

5. As in (4), an RNASP notification arrives at the server, which then downloads the message from the sender's messages store using MSRAP. Then the message remains in that store, for me to connect to later and find (like browsing a private mailing list). That's even more like providing me with a POP3 service; furthermore, the messages end up getting pulled down and stored on pobox's server, even if I'm not interested in them.

6.The protocol could be changed so that the sender does not lookup "" in the DNS, but looks up "". This could return a [receipt notification agent, user ID] tuple - or a list of them. Then individual users under a domain could have their mail delivery controlled separately, and the forwarding service would be nothing more than a DNS hosting service.

Note that it's not sufficient for the DNS to list only the RNA which you want to send to, because that server will have a mailbox called "" but it won't know that incoming notifications for "" should be associated to that mailbox (unless it is configured to do so, which means forwarding won't work unless you configure it at the receiver as well as in the DNS)

Mechanisms 2-4 could apply to traditional .forward files. And each of these mechanisms could be used to set up ad-hoc mailing lists which rather break the model of how mailing lists were intended to work in IM2000 (i.e. receiver pulls, rather than sender notifies).

Probably option 3 is the closest to the existing forwarding service, and appears to be blessed by the IM2000 spec. I guess also option 1 is feasible, since running an RNA server should be a lot cheaper than a POP3 server. I guess also that the IM2000 architecture obsoletes the concept of a .forward file; a Unix user has no local mailbox, but just configures their MUA with a list of receipt notification agent accounts, and pulls messages from the sending message stores when needed.

Forwarding is used in other cases too. What about role contact addresses, like <>? In the current world, I may have this set up to forward to several members of staff, or I may have one shared mailbox which several members of staff all have read and delete access to. Now, if a potential customer wants to send a mail to <>, the last thing they want to have to do is configure their MUA to subscribe to a write-only mailing list on the server. Clearly, this has to go out like a personal mail: the message goes into the sender's message store, and a notification goes to <>

Now, let's say we want and to be able to view and act on these messages. How should it be handled?

It's basically the same. One option is that both bob and freda log into the receipt notification account (i.e. option 1 above). Another is that that notifications which arrive for are re-sent to and (option 3 above). That would be the equivalent of 'shared inbox access'; the sending message store will believe that the message has been sent to <>, but it will end up seeing read and un-pin requests from <> and/or <>. Since they both have a copy of the same opaque key, the first one to un-pin the message will delete it. That makes sense I guess; if freda has dealt with the message, bob doesn't need to see it.

Another approach is like options 4 and 5, where is a robot message store which pulls down the message from the sender's message store. It could then either start sending notifications to and, or it could just wait for them to poll the mailstore (as would be the case if they were reading a public mailing list).

I think some guidelines should be produced on the intended way of handling these scenarios under IM2000, to give a some consistent practices, or at least to say that certain practices are equally blessed.

8. Additional advantages of IM2000

It is perhaps worth noting in passing some additional advantages of IM2000 or an IM2000-like solution over SMTP.

8a. Since there are no bounces, the problem of "joe jobs" from forged envelope senders is gone.

8b. "Mail bombs" can be dealt with more easily. A sender cannot fill up a recipient's mailbox. They *can* fill up the receipt notification agent, but it could be configured to accept no more than a certain number of messages from one particular sender.

8c. Users can "unsend" messages which have not yet been retrieved - a function which many closed E-mail systems have and which is missed on the Internet.

8d. At the moment, many mail clients remove external images from HTML mail, because it acts as a cookie that gives information to the sender that the message has been received. Since IM2000 already gives this information to the sender, then you might as well allow mail clients to access external images again. (Whether you consider IM2000 to have privacy problems from the way it works needs wider discussion, but it seems to me that if you receive a message that someone has sent you, they are entitled to know about it)

8e. As an observation: the IM2000 protocol gives the opportunity for "notarised" E-mail conversations to take place; that is, conversations which are logged by an independent third party and could be used as subsequent proof of the content of the conversation. This would be the E-mail equivalent of "your phonecall may be recorded for training and monitoring purposes". It would be especially useful for negotiating contracts via E-mail, or if you started to receive threatening or otherwise illegal mails from someone. It's an expansion of the "proof of spamming" concept outlined in (2f) above.

It might work like this. If you receive a message notification from someone that you want notarised, you don't download the message, but you pass the notification onto the notary. The notary would then download the message into its own message store, perhaps adding a timestamp and cryptographic signature, and give you a new receipt notification. You would then download the message from the notary's mailstore.

Clearly, it's possible for the remote party to learn that the communication is being notarised in this way: they can detect the IP source address from where the message is downloaded. The remote party might choose to blacklist the notary's IP address; that's fine. They're just refusing to communicate with you on these terms, which they're entitled to do, so you just don't communicate. An evil remote party might choose to reveal one version of the message if it's retrieved from your own IP address, and a different version if it's retrieved from the notary. That's why you have to let the notary store the message, and then retrieve it from there, not directly from the sender's mailbox.

You can log your outgoing mail in the same way, by passing on an extra copy of the sending notification to the notary. However in this case the notary has no way of knowing that you're not revealing one version of the message to the notary and a different one to the end recipient, so to be properly secure the end recipient should also be using a notarisation service of their own. (Or else, in a court, you'd have to convince a judge that you were using a reputable message store which you have no way to make behave in such an evil manner, for example one hosted at your ISP). If notifications included a cryptographic hash of the message itself, that would prevent messages being changed in-situ after the notification had been sent. Note that actually the cryptographic hash can be the opaque key required by the protocol, rather than an adjunct to it.

The big advantage of IM2000 over SMTP here is that individual messages can be notarised or not as you wish; with SMTP you'd have to point your MX records at the notary, meaning that all incoming mail for all users at your domain would be notarised.

9. Retransmission of notifications

The IM2000 spec assumes that Receive Notification Agents will not have reliable persistent storage. For this to be a safe assumption, it requires sending message stores to retransmit their notifications periodically (at intervals of at least 24 hours)

The problem here is that these notifications may go on for a month or more if the recipient is not checking their mail, wasting bandwidth and CPU resources. But perhaps more importantly, I don't believe that anybody is really going to make the RNA not have persistent storage; rebooting an RNA and losing a day or more's worth of notifications would be far too serious an event in terms of the delays caused to incoming mail. But if the notification data is going to be stored persistently in RNAs, then the periodic retransmission algorithm is not needed in the first place.

There's an argument that perhaps the RNA will have persistent but unreliable storage (e.g. a hard drive which may fail). However, if the majority of people end up building resilient RNAs, then probably the retransmit features of IM2000 will not end up being properly tested, and won't work when they are actually needed.

10. Dynamic equilibrium?

Finally, let's go back to spam. It's pretty clear that IM2000 is easy to use for sending spam; it's also clear that there can be effective reactive countermeasures (blacklisting) to keep it manageable, and better evidence for law-enforcement.

However you could argue that for these countermeasures to remain effective, there will always have to be some spam getting through. If there were no spammers, then the countermeasures would no longer be maintained - remember that the blacklists require human intervention, and hence cost time and money to maintain. However if that were to happen, it would be an open invitation for spammers to start up again; and so the cycle repeats.

So I believe there will always be a balance between spammers and countermeasures, with spammers continually kicking the tyres. The various forms of blacklisting need spam to keep them effective; and equally, spammers will need to get some of their spam through to make it worth their while. As a result, I don't think our mailboxes will ever be completely spam-free, even if we all switch from SMTP to IM2000.

Suggested alternative architecture

Here's just an idea. Imagine a world where an IM2000-style message store is divided into folders.

Points for discussion and further thought