Subject: [Asrg] 'Registered Email' and 'Trust-E-mail' proposals for both spam and viruses

From: "Joshua Leisk" <[email-masked]>
Date: Wed, 7 Apr 2004 10:28:16 +1000

In January, I came up with a technically feasible solution to spam and email
viruses, coined 'Registered-Email', the details of which, I have posted
here:
 
http://www.intechcomm.net.au <http://www.intechcomm.net.au/> 
 
As this requires a global change to the email system, it is fairly
ambitious, although technically sound.
 
Please read through the original post (at the address above) before reading
further.
 
Realising that any change to the existing email system, although sorely
needed, is going to be nearly impossible, I have devised a fairly workable
variation of the concept. 
 
This is an early draft, although I am hoping you will see merit in the ideas
behind the concept, rather than dismissing individual aspects. Having said
that, I would really welcome all comments, as this certainly will need
refining:

'Trust-E-mail' -  'Trust-Based Mail Server Ranking'
 
Introduction. 
 
The major hurdle faced by my 'Registered Email' concept is that it requires
active participation of the sender and effectively a global change to SMTP.
This variation of the 'registrar' component eliminates that problem.
 
Table of Contents
 
1.DNS Scan - The Innovation
2.Ranking System
3.Penalties
4.Database Usage
5.Procedures for New Mail Servers
6.Bonds
 
1. DNS Scan - The Innovation
 
This is performed to create an automated global white-list, for immediate
mail server trust ranking and immediate SMTP virus prevention for receiving
mail servers. This is done by creating an application that scans the DNS
Rootservers daily for:
            Domain Name
MX Records
Domain Creation Date
 
Using this information, a database is created, containing:
            Domain Name
MX Records
Domain Creation Date
Trust Level / Rank
Reset or 'Effective' Creation Date (for blacklist and spammers. For
permanent barring, this could be set 1000 years in advance and the Rank set
to "U" (see ranking system)
 
Trusted DNS blacklists, eg Spamhaus, should be applied against the resultant
initial database and the trust level / rank of blacklisted MX records should
be set to "U" (see ranking system).
 
2. Ranking system consists of:
            
"U" - Untrustworthy. 
Any domain that is less than 12 months old and has not applied for a "P"
provisional or "B" bonded ranking. New servers should follow the steps
detailed in section 5 if they don't want to be treated as untrustworthy by
receiving mail servers. 
"P" - Provisional.
Any domain that is more than 6 months old, but less than 12 months old, has
not been the subject of verified Spam complaints and has been sponsored /
vouched for by existing highly-ranked mail-servers (typically their ISP).
"B" - Bonded. 
Any domain that is less than 12 months old, but has paid a security bond
against spamming, does not relay mail from clients that are not using SASL /
TLS / SPA and blocks outgoing emails with dangerous attachments.
"N" - Neutral. 
Any domain that is more than 12 months old and has not been the subject of
verified Spam complaints.
"A" - Active.
Any domain that is more than 12 months old, has not been the subject of
verified Spam complaints and has been sponsored / vouched for by existing
highly-ranked mail-servers (typically ISPs).
"T" - Trusted. 
Any domain that is more than 12 months old, has paid a security bond against
spamming, has not been the subject of verified Spam complaints and does not
relay mail from clients that are not using SASL / TLS / SPA.
OR 
Any domain that is more than 36 months old, has not been the subject of
verified Spam complaints and does not relay mail from clients that are not
using SASL / TLS / SPA. 
"E" - Elite. 
Any domain that is more than 3 years old, has paid a security bond against
spamming and has not been the subject of verified Spam complaints and does
not relay mail from clients that are not using SASL / TLS / SPA.
 
3. Penalties:
 
Any mail server proven to send Spam will have its ranking lowered. 'Bonded'
mail servers could forfeit all or part of the bond supplied. Severe breaches
will result in a permanent "U" ranking being attributed.
 
4. Database Usage:
 
Receiving mail servers should perform a reverse DNS lookup and verify an
incoming mailserver is in the database. If not, the mail should be rejected,
as the sending mailserver is a virus. If used, the spoof-prevention
technique mentioned in my 'Registered-Email' concept notes will prevent mail
servers on private networks from being spoofed by viruses also residing on
the internal network. 
The mailserver can also choose to check the database and either reject,
stamp or filter mail from the various ranked mailservers. Messages received
from "U" should either be rejected with a non-delivery report sent stating
why it was rejected, OR heavily stripped, stamped as 'untrustworthy' and
cleaned. Messages received from "P" and "N" ranked mailservers should have
dangerous file attachments and dangerous HTML tags and all ActiveX controls
stripped. These messages should be filed separately from the remaining
ranks. Messages received from "A","B", "T" or "E" ranked mailservers are
trusted.
 
5. Procedures for New Mail Servers:
 
New mail servers register their MX details in the DNS as usual and then
choose to either:
a.	Forward all mail through their ISP, using SASL. Configure the mail
server for SASL clients only and block outgoing emails with dangerous
attachments. At 6 months, seek 'sponsorship' from another highly-ranked mail
server owner (typically your ISP) and apply for a "P" provisional ranking.
The mail server must also pass checks to verify SASL compliance and blocking
of outgoing emails with dangerous attachments. This is typically for a home
mail server or a small business.
 b. Apply for a "B" (Bonded) ranking.  This is predominantly for larger
businesses.
 
6. Bonds
 
To qualify for a "B" ranking, the mail server owner must supply enough
proof-of-ID, in person, to an authorised agent of the database owner. The
mail server must also pass checks to verify SASL compliance and blocking of
outgoing emails with dangerous attachments. 
 
After 12 months, the bond can be returned - to receive a "N" rating, or kept
to receive a "T" rating. Likewise, at 36 months the bond can be returned to
receive a "T" rating, or kept to receive an "E" rating.
 
Summary
 
This is an extremely easy-to-implement, automated 'whitelist' solution,
similar to my 'Registered Email' concept, that will prevent viruses and the
majority of Spam. Existing mailservers will already fall into the "U", "N",
"A" and "T" ranks. This requires no active participation of the sender or
end-recipient, although it will be rewarded, prevents SMTP virus replication
and allows for 'home' and 'hobby' email servers.

Thanks for your time. I welcome your comments and criticism.
 
Regards,

Joshua Leisk

---

From: der Mouse <[email-masked]>
Date: Tue, 6 Apr 2004 23:41:19 -0400 (EDT)

> In January, I came up with a technically feasible solution to spam
> and email viruses, [...]

This looks to me like another FUSSP.

Most briefly, it has severe scaling problems; if the stuff described is
done per recipient site, it has catastrophic scaling problems, whereas
if it's done through a central registry, it has central point of
failure/trust/pressure problems.  It also appears to have been designed
by someone who understands neither email (for example, the confusing
between MX hosts and outgoing mailservers, and the peculiar notion that
all domains that send mail appear directly in something like a root
server) nor the DNS (thinking the root servers hold MX records,
thinking that the DNS anywhere holds creation dates).

In more detail....

> This is performed to create an automated global white-list, for
> immediate mail server trust ranking and immediate SMTP virus
> prevention for receiving mail servers.  This is done by creating an
> application that scans the DNS Rootservers daily for:

(a) Instant scaling problems.  Every email site downloading the entire
root zones daily?  Or if a centralized site, why should everyone trust
it, what will be done to protect it against technological and legal
attacks?

(b) You're assuming the DNS root servers are the appropriate place to
check.  This is true for approximately no domains.  Even the
gtld-servers.net machines are good only for .com/.net/.org, and only
for second-level domains there.

> 		Domain Creation Date

The DNS does not contain domain creation dates.

The root servers do not have MX records for any significant number of
domains.  You have to ask the domains' servers themselves for that.

This also assumes all email domains will be @ domains that appear
directly in the roots.  This is false (eg, my own mailhost,
sparkle.rodents.montreal.qc.ca - only .ca appears in the roots; even if
you go to the .ca roots, only rodents.montreal.qc.ca appears there).

I also have trouble imagining why a receiving system cares about anyone
else's MX records.  Are you perhaps falling into the trap of thinking
that MX records have anything to do with outgoing mail?

> 		[...]

More scaling problems.  Every email site is going to recreate this
ginormous database daily?  Where will they store it?

> Trusted DNS blacklists, eg Spamhaus, should be applied against the
> resultant initial database

Most DNS blacklists do not list domain names (which are all you have at
this point, since you haven't described anything that involves any
addresses), only addresses.

More scaling problems - you're having every email site doing some huge
number of queries (on the order of the number of domains) to at least a
few DNSLs.  Daily.  If even a small fraction of the mailservers on the
net were to do this, it would amount to a DDoS on the DNSLs.

> "U" - Untrustworthy. 
> Any domain that is less than 12 months old and has not applied for

So domains must exist for a year before anyone will let them send mail,
unless they specifically negotiate an agreement of some kind with the
recipient?

This might help for a year; all it would do after that is mean that
spammers need a lag time of a year between registering domains and
using them.  It would raise their costs slightly, but that's about it.

On the other hand, it will severely cripple net.newcomers.  Looks to me
as though it causes trouble for the wrong people.

> Any domain that [...] does not relay mail from clients that are not
> using SASL / TLS / SPA and blocks outgoing emails with dangerous
> attachments.

Dangerous in whose opinion?  How can you prove whether a mailserver
(it's mailservers that relay mail, not domains) insists on
sasl/tls/etc?  (Don't forget, spamhauser _will_ lie about what their
outgoing mailservers do if they think it will help them.)

> Any domain that is less than 12 months old, but has paid a security
> bond against spamming,

Paid to whom?  If this isn't per-recipient, why should anyone trust
this entity?  Especially those in other countries than it?

> Any mail server proven to send Spam will have its ranking lowered.

Proven to whose satisfaction?

> 'Bonded' mail servers could forfeit all or part of the bond supplied.

Forfeit to whom?

This system sounds as though it's either got a single central point of
trust/failure, or it's nothing but a rather elaborate and
resource-hungry form of individual whitelisting.

> Severe breaches will result in a permanent "U" ranking being
> attributed.

Until the lawyers attack it.  (If your system becomes successful enough
to matter, this _will_ happen.)

> This is an extremely easy-to-implement, automated 'whitelist'

Doesn't sound easy to implement to me.  You need some big legal
defenses (or you will if it becomes at all effective), you need someone
trusted enough to handle the bonds, you need to somehow get permission
to DDoS the root nameservers plus whatever other servers you need to
hit up to find the information you (think you) need, and above all you
need buy-in from both senders and receivers.

> This requires no active participation of the sender or end-recipient,

Sounds to me as though it does; the sender has to apply for something
or post a bond of some sort or some such, and the recipient has to
check all this goop.

> [...], and allows for 'home' and 'hobby' email servers.

How?  A number (such as me) will refuse outright on principle.  Most of
the others, any bond they can afford would be so small as to be
ignorable as a cost-of-doing-business to a spamhaus of any size.

Or are they supposed to just suffer for the first year, until they've
been around long enough to be mistaken for spammer^W^W^Wallowed to send
mail?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg