Re: [anti-spam-wg@localhost] Solution to Spam
- Date: Thu, 26 Jun 2003 09:08:22 +0000
> 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_.
Mark's response:
Who cares about their software!!!!!! It will be completely useless to them.
>>> 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.
Mark's response:
Do you know anything about client-server technology. The delay is NOT
client side but SERVER side. The delay is imposed by their ISP in the code
retrieval portion and code upload. Without the code, nothing works.
> 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.
Mark's response:
Sorry, but we really don't care about mailing lists. The majority of users
on the internet cannot use them. Also, are you going to respond personally
to several thousand challange response systems????
> 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.)
Mark's response:
The graphics are stored at the ISP not the email server....
> 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.)
Mark's response:
Challange response systems using the graphical method is the next defacto
standard. It has already been implemented by some of the world's largest
companies. Too late on that one I'm afraid.
>>> 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.
Mark's response:
How many time do you need to be told this, NO, it won't work!!!!!!!!!!!!!!!
> 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.
Mark's response:
Doesn't work like that....
> 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?
Mark's response:
There would only be several thousand entries in the database, hardly a major
thing.
>>> 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_?
Mark's response:
That one's simple, it will be useless until you do.
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.)
Mark's response:
Haven't a clue what your on about.
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.
Mark's response:
It's already working!!!!!!!!!!!!!!!
> 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.)
Mark's response:
If I receive email at to high a rate, they are deleted, its very easy. No,
it doesn't need to work with user names.
>>> 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.
Mark's response:
OK, done! What now?
/~\ 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
_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today!
http://www.msn.co.uk/messenger