as documented at http://homepages.tesco.net./~J.deBoynePollard/Proposals/IM2000/
Author: Brian CandlerHowever, 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.
2a. The current world depends primarily on ISPs handling abuse complaints promptly and correctly. If I see spam relayed via smtp.example.net, I contact abuse@example.net 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:
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 foo.example.org, bar.example.org and baz.example.org, I may wish to blacklist those three message stores separately, or just blacklist *.example.org
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.
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 example.net. says 192.0.2.2
^^^^ ^^^^^^^^^^^^ ^^^^^^^^^
The tuple <toby, example.net> is what people are likely to associate as a
"sender E-mail address", i.e. toby@example.net, 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 toby@smallbusiness.com on smallbusiness.com says 192.0.2.2
^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
(where domain "smallbusiness.com" has SRV records pointing to example.net's
message store); or else
from toby@smallbusiness.com on example.net says 192.0.2.2
^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^
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 accounts@paypal.com on spammerdomain.com says 64.202.167.129or worse,
from accounts@paypal.com on [64.202.167.129:1234] says 64.202.167.129It 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:<accounts@paypal.com> and Received: from 64.202.167.129. 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 accounts@paypal.com on bot304.spammerdomain.com says 64.202.167.129This allows blacklisting message stores *.spammerdomain.com, 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 192.0.2.2(that's an MD5 hash of "toby@smallbusiness.com\0example.net")
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: B.Candler@pobox.com", you would do a lookup on
b.candler._at.pobox.comand 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: B.Candler@pobox.com" 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 example.net says 192.0.2.2i.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
It would be straightforward enough to combine the two. Instead of sending notifications which say
from toby on example.net. says 192.0.2.2they could say
from toby_sample@example.net says 192.0.2.2The sender's mailstore would be found using a DNS SRV lookup on example.net, and 'toby_sample@example.net' plus the opaque key would be used to retrieve the message. Using the proposed IM2000 protocols it would still be up to the example.net ISP to ensure that the receipt notification agent account for "toby_sample@example.net" was accessed by the same person as the mailstore account "toby_sample@example.net" - 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).
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 brian@example.net, sending to foo@lists.ietf.org, then:
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.
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.
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.
I can see at least six distinct alternatives for what happens when someone sends mail to b.candler@pobox.com, which in today's world I want to be forwarded to brian@example.com.
1. Nothing is forwarded at all; I configure my MUA to subscribe to a Receipt Notification Agent service at pobox.com. In today's world, that would be a bit like pobox.com providing me with a POP3 mailbox instead of a forwarding service.
2. An RNASP notification arrives at the pobox.com server, which replies with a message saying "not here: resend to brian@example.com 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 pobox.com server, which modifies it (changing "b.candler@pobox.com" to "brian@example.com") and resends it to the recipient notification agent for example.com - 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 example.com 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 pobox.com 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 pobox.com 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 pobox.com 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 pobox.com 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 "pobox.com" in the DNS, but looks up "b.candler._at.pobox.com". 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 pobox.com 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 "brian@example.com" but it won't know that incoming notifications for "b.candler@pobox.com" 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 pobox.com 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 <sales@example.com>? 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 <sales@example.com>, the last thing they want to have to do is configure their MUA to subscribe to a write-only mailing list on the example.com 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 <sales@example.com>
Now, let's say we want bob@callcentre.com and freda@callcentre.com 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 sales@example.com receipt notification account (i.e. option 1 above). Another is that that notifications which arrive for sales@example.com are re-sent to bob@callcentre.com and freda@callcentre.com (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 <sales@example.com>, but it will end up seeing read and un-pin requests from <bob@callcentre.com> and/or <freda@callcentre.com>. 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 sales@example.com is a robot message store which pulls down the message from the sender's message store. It could then either start sending notifications to bob@callcentre.com and freda@callcentre.com, 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.
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.
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.
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.
These would be very similar to IM2000 notifications, except the key you use to access the message is the mailbox E-mail address plus a cookie.
Therefore, the notifications contain an authenticated, phishing-proof sender identity; if you forge a notification from 'accounts@paypal.com', say, then the receiver will contact paypal.com's servers to try to retrieve the message from the accounts@paypal.com mailbox, and it won't be there.
However once we have a canonical hash of the message, it also becomes straightforward to add cryptographic signatures to a message. I will call these "attestations", and propose that the set of attestations is stored separately to the RFC2822 message (headers+body). This allows attestations to be added without changing the hash of the message itself, and I think is cleaner than putting the attestations in additional headers (which would have to be filtered out when recalculating the hash). I'd like to keep the mail transportation completely divorced from RFC2822 anyway, allowing different message structures in future - or unstructured file transfers, such as sending a fax as a MIME object rather than as an RFC2822 message with an attachment.
A message can accumulate attestations during its lifecycle. Some examples of these might be:
Each attestation would contain enough information to allow its signature to be checked (e.g. it references a key in the DNS, or follows an X509 chain of trust), allowing the MUA to display only genuine attestations.
When receiving a notification, your RNA can choose to download the attestations associated with a message and analyse them before deciding whether to accept, reject or greylist the message, based on policy stored in the RNA; or your MUA could apply such policies itself.
The format of attestations is not defined here, but I see no reason why ASN.1 should not be used as the transport protocol. Note that ASN.1 defines other ways in which these objects can be serialised, in particular an XML format. So a message store could keep attestations in XML format in the mailbox (making them easy to read, debug and tweak by sysadmins) whilst still being sent in ASN.1 format to the MUA.
(Having said that, it would also be useful to be able to attach a message, complete with its attestations, to another message and forward it. However until we get to a point where Content-Transfer-Encoding: binary attachments are widely used, the message risks being changed and therefore the hash being invalidated).
Furthermore, when someone sends you a receipt notification, and the MUA logs in, it could trigger a process whereby the message store itself fetches the outstanding messages and puts them in your INBOX, rather than the MUA having to do it. The advantage would be more orthogonal access to your mailbox; receiving new mail would no longer be a 'special case' for the MUA to deal with. It would also permit filtering to be done server-side (e.g. with Sieve), which IMO is where it belongs. If you retrieve your mail from several different places, you don't want to be applying different filter rules each time, so I think the filter ruleset belongs with the mailbox, not the client.
However, if it becomes common practice to keep newly-fetched messages in an INBOX folder in the message store, you might end up with a situation where many implementors would choose to retrieve the message as soon as the notification arrives, ending up with an architecture quite close to what we have now.
This nullifies several of the advantages of the IM2000 architecture: in particular it might be helpful to spammers for their messages to be transferred before blacklists have time to notice, unless they use greylisting. It also could waste storage space receiving messages into inactive accounts. The definite 'confirmation of reading' for the sender is lost, if it's not triggered by the MUA downloading a message, and the 'unsend' facility is lost too.
However, it could eliminate the necessity to resend notifications periodically; and it gives us the familiar world where messages in your Inbox are immediately available when you login (whereas with IM2000, message retrieval may fail if the remote message store is temporarily down or unreachable)
This may also dovetail with the user requirement for synchronisation of folders, e.g. between a laptop (often working in disconnected mode), a desktop PC, and/or a folder store at the ISP.
opaque key
.--------> message store <--------------------------
/ -------------------------->
v remote retrieval
MUA
^
\ outgoing notifications
`--------> message --------------------------->
broker <---------------------------
incoming notifications
However, the fact that I have an account on a particular message store (and
can generate opaque keys for it) doesn't prove that I own a particular
E-mail address, so we will have to involve the message broker in the
sending process too.
For A to send a message to B, it might work like this:
Although this might look like a complex exchange, it has some advantages.
That means that the same persistent storage could be used for storing received notifications too. And in that case, there is no need for the continuous periodic retry which IM2000 message stores need to do; once the receiving message broker has acknowledged safe receipt of the notification, the sender can stop notifying.
[message store hostname, opaque key, sender, size, hash]
This gives a lot more options for storing them safely: they could be
stored in a SQL database for example.
Or, lots of received notifications could be stored in a cyclic filesystem,
flushing to disk every 4K. The performance of such a system would be
immense.
The entire set of an ISP's incoming and outgoing notifications might be cacheable in RAM (e.g. 100 bytes * 1M messages = 100MB) which would give extremely high read performance, especially in the event of lots of junk notifications flying around.
On the minus side:
Hence it may be simpler for the message store and the notification service to be a single entity. Authentication to the message store is then also sufficient authentication to send out notifications which originate from that E-mail address.
For PDAs, the IMAP world is good for them, in particular because IMAP lets them choose which MIME parts to download or skip. Whether this feature needs incorporating in IM2000 is highly debatable, because up to this point, IM2000 servers have had no need to understand the content of a message.
But the RFC2822 headers and body are not discussed at all. Perhaps if mail is going to be replaced, then other outstanding issues in the current E-mail infrastructure should also be considered.
Since a message put into an IM2000 message store does not undergo any transformations between sender and receiver, then there is a clear opportunity to calculate a message hash in a way which won't be broken by forwarding, and then for this message hash to be signed. This could associate a cryptographic identity with a message and prevent man-in-the-middle attacks if checked. As mentioned above, it would also offer the opportunity for other signatures to be added: for example those useless appendages saying "this message has been scanned for viruses by Foo Message Scanners Inc" could be replaced with cryptographic signatures which asserted that the virus scanning had taken place, and could be checked as such.
Being 8-bit clean, there is the desirable benefit of encouraging people to move towards Content-Transfer-Encoding: binary (="BINARYMIME" in SMTP), thus offloading the legacy of quoted-printable and base64 encoding. As a bonus, attachment sizes should reduce by about a quarter.
There are probably many other opportunities which need to be considered too.