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 Name
MX Records
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?
Using this information, a database is created, containing:
Domain Name
MX Records
Domain Creation Date
Trust Level / Rank
[...]
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?
3. Penalties:
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'
solution,
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
mouse(_at_)rodents(_dot_)montreal(_dot_)qc(_dot_)ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg