Re: [anti-spam-wg@localhost] Solution to Spam
- Date: Thu, 26 Jun 2003 08:49:57 +0000
It's already under development. The details were passed to Microsoft this
morning. You may be an administrator of email servers, but you hardly seem
to know anything about the security side of things. I develop security
protocols, a few test systems are already in place and the pilot has been
100% sucessful, not one spam email passed the system.
It eliminated over 100,000 spam emails, every attempt to bypass the system
completely failed. As for 'mailing lists', well, the majority of users
don't really care about them. That is what it comes down to in the end,
majority rules. Special authorisation codes can be given to legitimate
companies to enable certain bulk email features however, any breaches will
result in complete loss of service.
There are only several thousand ISP's on the planet, so a simple text file
can be used if it came down to it, most likely there will be a central
database co-hosted by the major email suppliers to run the system. One
person could set it up within 24 hours, no big deal.
See you don't seem to understand the client-server aspect too well and you
are getting confused. You are applying things to the clients side that
actually reside on the server side. There is NO possible way that a code
can be forged, even if it was copied directly from another server, it won't
work, because the server is connectly directly through the ISP and the
system ONLY connects to the real server. If your code is not on it, then
the emails are deleted. Simply by counting the amount of same codes that
come into a system a spammer can be identified in minutes, automatically
blocked and their ISP contacted.
If your wondering about 'older email systems' they will simply incompatable
with the new system and would be unable to send emails to any domain using
the new system. They would have to be updated to be able send emails.
Within a matter of days the spam level would fall by around 95%, after that
people wouldn't even bother.
Mark McCarron
From: der Mouse mouse@localhost
To: "Mark McCarron" markmccarron_it@localhost
Subject: Re: [anti-spam-wg@localhost] Solution to Spam
Date: Thu, 26 Jun 2003 03:32:38 -0400 (EDT)
MIME-Version: 1.0
Received: from Sparkle.Rodents.Montreal.QC.CA ([216.46.5.7]) by
mc8-f30.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 26 Jun
2003 01:09:21 -0700
Received: from localhost (localhost [[UNIX: localhost]])by
Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id EAA24144;Thu, 26 Jun 2003
04:09:16 -0400 (EDT)
X-Message-Info: JGTYoYF78jEHjJx36Oi8+Q1OJDRSDidP
Message-Id: <200306260809.EAA24144@localhost>
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be
part of it anyway.
In-Reply-To: <BAY2-F38zmRf6Ci6nx800000292@localhost>
References: <BAY2-F38zmRf6Ci6nx800000292@localhost>
Return-Path: mouse@localhost
X-OriginalArrivalTime: 26 Jun 2003 08:09:21.0662 (UTC)
FILETIME=[3FC951E0:01C33BBA]
> These suggestions would require updates to both server and client
> software.
Then they won't work. We - for any value of "we" - do not control the
sending software in use by spammers; they are using special-purpose
ratware for sending _already_.
>>> 2. A 10-15 second delay between emails should be imposed.
>> [N]obody is in a position to prevent a sender from sending
>> back-to-back to multiple recipients.
> 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.
Yes, but so what? The spammers will just have their ratware skip that
delay. We do not control their software.
> The punishment for legitimate users would be minimal since they are
> not sending the volumes associated with spammers.
You obviously have never run a large mailing list. Any `solution' that
kills mailing lists is, as far as I and approximately everyone else
I've discussed it with are concerned, a total non-starter. We couldn't
even be _having_ this discussion in such a world.
> When each email is to be uploaded to the server a new graphic is
> download and the authorisation code must be entered manually.
This implies that you are expecting spammers to use outgoing
mailservers that are not under their control. This has not been true
for a long time, at least for most spam. (A little, things like
incompetent wannabees sending MMFs, uses stock outgoing servers. It's
the exception rather than the rule, today, at least as far as _my_
incoming spam stream is concerned.)
> As for the blind or visually impaired, this is already an issue with
> challange response systems.
How so? The blind can read and respond to a C/R message just as well
as they can any email. (C/R systems that depend on extracting text
from images, yes, they are unusable for the blind; that's one reason I
consider them dead on the vine. The amazing venom people react to them
with is another; I know of a lot of people, including me, who simply
plonk anyone sending out such challenges.)
>>> 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?
> 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.
So, all spammers need to do is have their servers lie about this,
adding whatever codes they feel like and then cheerfully confirming
their authenticity when asked.
> 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.
Hardly. You already have the address of the server you got it from,
and that's all you'd have with this - you'd just find spammer ratware
hijacking Windows boxen and not only pumping out spam but confirming
the authcodes in the headers thereof. I see no real gain here.
> 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.
How? Are you proposing to maintain some kind of global registry of
ISPs? What prevents spammers from registering with it? Does that also
prevent me (I own and run my own mailserver) from registering? How can
we trust this central point? If you don't have such a central
registry, how do you identify ISPs in that "first part", and in that
case too what prevents spammers from pretending to be ISPs?
>>> 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?
> Firstly, a lot of spammers search for open/badly configured servers
> on the Internet through which they send spam using anonymous
> emailers.
This sounds like open relay spam, which is mostly dead by now.
> Without any authorisation code, from a graphic, even an improperly
> configured server would refuse the email.
Only if you somehow manage to get all the old servers now in existence
updated. How do you propose to manage _that_?
Also this takes no account of 0wn3d Windows boxen running
special-purpose sending ratware.
>>> 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?
> There are only a handful of major email suppliers in the world.
And how do you propose to ensure that everyone must run one of them?
Break them so they no longer use an open protocol? You'll lose the
open-source crowd instantly. (You _can't_ close the protocol used by
open source software.)
That's one of the few things that might actually stop spam: get the
800# gorillas to run something closed that won't talk to ratware. Of
course, it won't talk to anybody _but_ the 800# gorillas; this amounts
to going back to the days before the September That Never Ended as far
as email is concerned, with the masses on closed systems that don't
intercommunicate with the rest of the net.
It would - or at least could - stop spam. Or at least limit it to the
gorillas spamming among themselves. I'd even be willing to lose
contact with the AOLs and Hotmails of the world if it means we (the
people running free software that speaks open protocols) can have our
mailboxes back - it's gotten that bad.
I doubt it will happen.
> 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.
How can you, the recipient, tell whether my outgoing mailserver imposes
your ten-second limit (or any other part of your MUA->MTA protocol) or
not? Except in the negative if you get multiple messages from me
within ten seconds? (To be practical, it has to be per-user, so all
spammers will have to do is rotate usernames, something they already do
anyway.)
>>> 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?
> Because their email system has to be authorised by the ISP to obtain
> an operating code. Without one the system would be useless.
So you're creating another pyramid of authorizations. Why can we trust
it? We can't trust the ones that are in place now.
>>> The adaptations [...] 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.
> I used to do this for a living. I know the in's and out's of it.
What, sending spam? I think you're not in as good touch with the
current state of the art as you think. I as a recipient see a most of
my incoming spam quite definitely _not_ coming from anything even
approximating a normal MTA. Reports from people I trust indicate that
much of it comes from Windows malware that is actually somewhat
sophisticated, capable of maintaining tens of thousands of sending
threads in parallel and the like.
> So, in conclusion: [...]
> There you go, problem solved.
Very good. Go implement it. I'll be waiting.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
_________________________________________________________________
Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile