Redundancy will be required for the higher levels of GoodMessaging.

Redundancy

Redundancy is an absolute necessity if e-mail is to be safe. Redundancy is one of the problem areas for currently implemented mail software.

SRV records

Any system claiming to be redundant must have SRV records for the redundant services. Most DNS servers currently allow for SRV records; certainly BIND does. To find out more about SRV records, see the Improving the Internet [7] page. For those who want the technical details, see RFC 2782 [8].

MAP?

The MAP or the data needs to support some way of identifying messages across servers. However, see below under MDA.

MDA

A redundant MDA can be done by naming the two mail servers A.mail and B.mail, and then pointing the MX record at both. If A receives mail for "mail", it forwards it to B.mail and stores it locally. Machine B is the reverse. It would also be ideal to put in a unique message identifier at this point to aid the MAP proxy in duplicate removal.

MAA

This is the difficult one. The MAA is not only responsible for the message pickup, but also for ensuring that the MUA receives only one copy of the message (unless it elects to leave it on the server, or some such). The only idea I've seen which seems to have some chance of success is to have a MAP proxy which interacts with various MAAs. To get true redundancy, it would be necessary to have multiple MAP proxies, so that if one goes down, the other can still pick things up from the servers. It's possible that UIDLs or Message IDs could be used to co-ordinate these. Also, something in the MAP system (the proxy?) would need to remember which messages were deleted (or whatever) so that if an MAA server went down, the relevant messages could be deleted when it came back up again.

Known MAP aggregating proxies:

• Cyrus IMAP has one (IMAP only): http://asg.web.cmu.edu/cyrus/ag.html [9] (does not allow duplicate removal, but it is on their future list)
• [../../OtherProjects/smunge/ smunge]: my understanding is that smunge still needs some work in the duplicate removal area.

RedundantMail

Site: Requires that all server MAs have duplicates in another location at least 10km from the first

Site: Requires that all server MA machines have hot-swappable mirroring (ie. RAID), and dual power supplies on different UPSs, and uses, where possible, two different pieces of software in the same MA category (ie. postfix and sendmail), so if some exploit comes out against one, the other has a fair chance of still working.