You are here: Home > Participate > Join a Discussion > Mailman Archives

[anti-spam-wg@localhost] Solution to Spam

From: "Mark McCarron" < >
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

Post To The List:

Follow-Ups:
- Re: [anti-spam-wg@localhost] it could be sooo easy - Solution to Spam
  - From: Markus Stumpf
- Re: [anti-spam-wg@localhost] Solution to Spam
  - From: der Mouse

<<< Chronological >>>

Author Subject

<<< Threads >>>