The Public/Private e-mail system sets SPAM and other unrecognized e-mail aside while passing private and recognized mail. Thus important mail is opened first and we can deal with the junk later.

It works by recognizing the user's "privately" addressed and "passlist" e-mail while SPAM and all others are held in a web page managed area (See figure). Later, when the user wants to deal with it, the holding area is checked to retrieve any legitimate e-mail and deal with the junk.

The "private" domain names are additional MX records that are shared only with trusted users (i.e., friends and family). These are setup by whoever administers the domain name server for the user. Although there could be as many private domains as trusted users, generally speaking, only one extra domain is needed (i.e., "nospam.advicom.net" or "surname.advicom.net"). If it is ever compromised, the DNS entry can be changed which invalidates it and a replacement entry put in its place (i.e., "secret_surname.advicom.net").

Not dependant upon DNS entries, the "passlist" exists to cover special cases of entries that show up in the holding area such as as mail-lists and USENET posting replies. To keep the "passlist" from growing forever, the entries age with each update although individual entries can be set to never expire.

The Web page controlled holding area lists the incoming mail so the most :

Risk,Attack Mechanism,Mitigation

Harvest "private" address from browser"

Netscape and Internet Explorer have an e-mail interface which if configured for the "private" e-mail address could be read either from visiting a page with "ftp://..../.html" links and/or from an inadvertant e-mail reply.


The user must use a non-integrated browser and e-mail program to post messages that have the private e-mail address as the reply. This avoids premature compromise of the private address. For example, use "Eudora" for private e-mail and have the browser e-mail address set to the "public" e-mail. Thus even if an e-mail message goes out from the browser, by default, it will always go to the holding area. A "passlist" update can be easily made to handle the extended conversation and switchover to the "private" e-mail address can be done later.

Harvest MX records from DNS

The spammer uses 'nslookup' to dump the DNS records and search for MX. Once the spammer verifies the port 25 MTA, they shotgun the publicly harvested usernames matched to the MX records.


If the number of MX records is large, then the combination of usernames that have to be tried is the product of the two. However, the spammer gets no feedback on successful combinations and instead makes what looks like a mailbomb, a type of denial of service attack.

The DNS server can be configured to not dump the list of records.

There could be an MX record for a "tripwire" MTA. Once activated, the whole site could become "mute" or go into "slow" mode connections. This increases the risk of early detection and network reaction.

The DNS server with the extra MX records does not have to be in the same subnet as the domain. It is perfectly OK to have an MX record "notme.hotmail.com" that points to the MTA in the address space of "advicom.net." This makes harvesting private MX records difficult.

Harvest passlist entries and forge headers

This requires the user making the passlist readable to others. It is simular to leaving /etc/passwd open. Unfortunately, many ISPs allow users to read the directories of other users which means one throw-away account could scan for passlists.


Protect the passlist and if compromised by a rogue user at an ISP, use new, unadvertised MX records.

Make sure the web page update requires a solid authentication. For example, limit the source IP range to those in the domain of the ISP. Use secure encryption of passwords.

Do not hardcode the passlist filename but have it generated by some key and a one-way algorthm. This makes automated harvesting of the passlist impractical.

Try to get ISPs to not let users read each others directories.