[anti-spam-wg@localhost] Solution to Spam
- Date: Thu, 26 Jun 2003 07:20:24 +0000
Mouse, you are trying to break this down to its componants. Let's do it, I
to run email servers both in and out as well. These suggestions would
require updates to both server and client software. All it takes is a
little ingenuity.
The solution is simple:
1. Limit the number of recipients for each email. For domestic use,
10 or 20 is quite adaquate. Emails with more recipients than the
allowed limit should automatically be spanned as separate emails.
This can be done now, by receiving mailservers. It may be worth
trying, but I doubt it will help much.
Mark's response:
This would need to be an update to both client and sending server. It will
only work in conjunction with the next proposals and is not designed to work
on its own.
2. A 10-15 second delay between emails should be imposed.
This will be...difficult. A given server can prevent a given sender
from sending more often than that, but nobody is in a position to
prevent a sender from sending back-to-back to multiple recipients.
Worse, it will punish legitimate senders who compose offline and send
the composed messages through their email provider's outgoing
mailserver as a batch, by requiring them to stay online several times
as long as they really need to.
Mark's response:
The Update would be for sending servers (like SMTP) a simple delay of 10
seconds per email would result in a connection time of 46 hours for 1
Million emails. The cost of this and the long time-frame would elimate
nearly 90% of spam overnight. A simple change of the client code would
result in multiple recipients being spanned across several emails. The
server code could be altered to prevent multiple recipients above a given
level. MSN already uses this feature in Hotmail, a maximum of 50 recipients
per email. Also limiting the amount of emails in any 24 hour period
(another MSN tactic) would have a drastic effect. The punishment for
legitimate users would be minimal since they are not sending the volumes
associated with spammers. Challange response systems would be worse.
3. Each email request should force a graphic to be loaded to the
email client with an obscured word on it. This graphic should be
random.
This immediately eliminates two classes of people from using email, the
blind and the text-only. Neither is particularly large, but neither is
deserving of such treatment, and I for one as a mailserver owner and
operator (both incoming and outgoing) won't implement either side of
any protocol that has such effects.
It's not clear when this happens and to whom: to the sender's user
agent at send time, or the receivers' at receive time, at read time,
when?
Mark's response:
When each email is to be uploaded to the server a new graphic is download
and the authorisation code must be entered manually. As for the blind or
visually impaired, this is already an issue with challange response systems.
A simple solution would be to transmit a word or several words in amongst
random characters for these type of people, but then, a good parser could be
written for automation using a dictionary. The solution here maybe to add
numbers or special characters within the word(s) than a human could
understand but would be difficult to automate.
4. Each uploaded email should have a random ID appended to its
header as an authorisation code.
Appended by whom? Who chooses it? Who needs to trust it? If that
entity isn't the sender, how can it be assured it's trustworthy?
Mark's response:
The authorisation code would be appended to the email by the sending server.
This code would simply mean that the email has passed the graphic security
on that server. The code is stored to an internal database on the sending
server for remote check. If a spammer is sending 1 Million emails then this
would be 46 hours in which to identify the location and ban the server.
Also, every email would then have ACCURATE information on the sender's
server, ip address etc, to have recieved the email in the first place.
Without the code, the sender would be unable send to systems protected by
the new changes. There would be several parts to a code, the first part
identifies the ISP. Therefore, a simple request to the ISP will identify if
the server is registered with them, if not the email(s) is(are) deleted.
The next part isolates the server itself and is allocated by the ISP. This
allows individual servers to be identifed, traced and blocked should the
need arise.
5. The recipient's email server should then confirm the code with
the sending server. If the code does not exist then the email is
destroyed without notification.
What prevents a spammer's sending server (which these days usually
means an 0wn3d Windows box somewhere) from answering "yes, it's fine"
to every such "confirmation" request?
Mark's response:
Firstly, a lot of spammers search for open/badly configured servers on the
Internet through which they send spam using anonymous emailers. Without any
authorisation code, from a graphic, even an improperly configured server
would refuse the email. That's the end of that method completely.
Secondly, servers would have to remain connected for several days to send
large volumes of emails, to allow for code checks, etc. This would identify
the location of the spammers, their isp and measures can be taken to block
that isp's ENTIRE email service until they remove/prosecute the offender. A
little bit of a bullying tactic, I agree, but highly effective nonetheless.
Also see above response.
So, let us do our sums on this, for an average spammer. We'll assume
that the email has 1000 recipients.
That's _way_ too low for a spam run. 1000000, or even 10000000.
Mark's Response:
Please, this is for demonstration purposes only!!!!!!!!
1000 recipients at a limit of 10 per email would result
in 100 emails.
100 * 10 seconds delay = 1000 seconds or about 16
minutes.
Right as far as it goes. But who is going to enforce these limits?
And how?
Mark's response:
There are only a handful of major email suppliers in the world. By
combining their power, limits can be set on what their servers will recieve.
These limits would form part of an 'open standard' configuration. This,
in turn, would force others to adopt the same settings or face being exluded
from being able to send emails to those domains. No ISP could afford to be
blocked from those domains.
add 100 * 5 second delay for loading of each
authorisation graphic = 500 seconds or about 8 minutes.
That's a total of 24 minutes to send 1000 recipients.
Five seconds? How enormous are you thinking of making these images??
Anything that's large enough to have significant impact on high-speed
connections will be totally unusable on slow dialups. Not to mention
the problems I sketched above (blind and text-only users).
Mark's response:
The 5 seconds to load an image is just another delay mechanism. This is
optional. Also, I was referring to dial-up users when quoting that time not
broadband users.
This coupled with the authorisation code will practically result in
the complete elimination of spam on the internet if universally
adopted.
Perhaps - but how do we get the spammers to adopt it? How do we ensure
they are actually doing so instead of just writing shells that make all
the right noises when queried but don't actually do anything?
Mark's response:
Because their email system has to be authorised by the ISP to obtain an
operating code. Without one the system would be useless.
The adaptations required to implement this are of a minor nature
compared with other programming tasks and can be released as updates
to existing servers and client software.
You appear to be under some kind of impression that spammers use
existing mail clients and servers for their spew. This is true only
from the point at which it hits the recipient's incoming mailserver.
Mark's response:
I used to do this for a living. I know the in's and out's of it.
So, in conclusion:
1. Limit recipients by alterations to both server and client code.
2. Limit the amount of emails sent in any 24 period, requires alteration to
the server code.
3. Add a 10 second delay between emails.
4. Use a random graphic with obscured authorisation code. Use randon
text/numbers for the visually impaired or blind.
5. Add the random ID, with ISP code and ISP auth. code for that email
server.
6. Force confirmation of codes by recipient's server. Compare codes with a
'black-list' of servers.
7. Have large email suppliers combine to adopt new system and create an
'open-standard' for configuration forcing third parties to adopt or die.
There you go, problem solved.
Mark McCarron
_________________________________________________________________
Use MSN Messenger to send music and pics to your friends
http://www.msn.co.uk/messenger