[anti-spam-wg@localhost] (no subject)

["Angel of Death" <]

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



-------------------------------------------------------------
Sign up for ICQmail at http://www.icq.com/icqmail/signup.html