At 12:28 PM 3/16/2003 -0600, you wrote:
On Sat, 15 Mar 2003 06:14:04 -0600, Brad Spencer
<brad(_dot_)madison(_at_)mail(_dot_)tds(_dot_)net> writes:
> After years of effort to secure all open relays there are still enough
> open relays that spammers actively seek them. securing them all isn't
> a viable option, didn't work, can't work. I favor a different
> approach that does work and can work: dilute the pool of true open
> relays with so many false ones that the spammers can't find the true
> ones. That's absolutely simple. While this is being ramped up the
> operators of fake relays who know how can take the information they
> glean from their false relays and use it to persuade ISPs to take
> action against the spammers.
However, is it effective? What this means is that a slightly greater
percentage of email is denied.
Yes, for small numbers of such systems.
The real point is that of considering the abuse aspects of the majority of
spam and devising ways to combat that abuse. Spammers don't know anything
about a particular IP just form the IP - they have to find out in some
manner anything they do know. Currently it is close to 100% safe and
reliable for them to test for open relay (or test for open proxy) and find
what they seek. That's abuse, it is accepted and tolerated, spam continues
to grow as a problem.
I'm no internet expert, this is an IETF working group. Some focus, some
goal, some something is needed. What's currently being done is
demonstrably inadequate. The solutions seem to (1) do much more of
something that is already done and (2) do something new. The something
news that I see are elaborate and require (I think) a shift in how email is
done. There'd have to be a very long transition period - that needs to be
well-analyzed in any proposal for a new email protocol, for example. I've
already done some analysis (which maybe someone could show to be bogus) by
characterizing the transition period as very long I have a great distaste
for that - I want spam dead now, and if not now then next week, or the
middle of next month.
More people could use blocklists, with usage concentrated on the blocklists
that are intended to do what blocklists do - prevent delivery of spam
(contrasting with SPEWS, if you can't see my intent.) More people could
use DCC - it's mostly automatic (there's a whitelisting requirement for
sites that have mailing list subscribers), it works, it responds quickly,
it scales. Then the approach I emphasize: do something at the abuse level,
before the spam is on its way to the final destination. The anti-spammers
have the advantage here if they want to claim it (right now, by ignoring
the abuse, anti-spammers give the advantage to the
spammers.) Anti-spammers far overwhelm spammers in their numbers,
anti-spammers can be in any IP space. Practically everyone who reads this
message should be able to go to the logs of a mail server and observe that
relay email is being rejected. Most have chosen the path of blocking such
abuse and then ignoring it. The spammers figuratively knock on the door
and ask to have access, the response is to ignore the knocking and then to
curse the neighbor who lets the spammers misuse their systems. That
approach guarantees that relay spam is sent to systems that will relay
it. When it is relayed it then shows up at destinations ISPs to be
filtered or otherwise rejected or accepted. Too much is accepted - that's
the problem. It would have been easy to stop the spam (like that which
advertises http://www.quickmailorderbrides.com/?oc=3D2390 that I'm stopping
in small quanttties) but most just let it go to the true open
relays. There's no real asrg plan - may I suggest looking at what could be
done about the abuse aspects of relay spam and deciding whether its a
viable option for significantly helping to defeat spam? I understand that
there is direct spam - this approach doesn't touch direct spam. If the
result of this approach were the forcing of spammers to send direct spam
from overseas wouldn't that be a giant step forward? Then there'd be a
relatively small number of IPs to block - it's a situation tailor-made for
success by DNSBL.
However, email sending is as
automatable as it was. If we are in a world where bandwidth costs are
expected to decrease and where CPU costs are expected to decrease,
then even with this, spam becomes more economical, because with the
same resources, they can send more messages, even if an increasing
percentage get rejected.
And they do. That same argument apples to most or all current
techniques. The goal surely is to drive the cost of sending the spam above
amount "earned" from the spam. There's no particular reason to pick what I
advocate other than the fact that the opportunity is great and that
opportunity has been overlooked. It's a cherry-picking situation: almost
anyone with a Windows system on a permanent network connection can run
Jackpot and do something against spam. How many million people would that
be if you assumed just 1% did it successfully?
We need a solution that can continue to work in worlds where
Disk/CPU/bandwidth is becoming ever cheaper. A technique that halves
the effectiveness of spam will be erased in two years. What do they
care if half of the proxies are fake two years from now? The cost per
message that goes through a non-fake proxy will be the same then as
now. At such a small loss, it may not even be worth the effort to
identify the fakes.
Good. Now you are in an evaluation discussion but you are doing it (to me)
backwards. You are assuming failure and then describing failure in terms
of an inadequate approach. I suggest you determine how many fake proxies
it would take to hurt them badly enough to force them to quit and then
evaluate how difficult it would be to get that number of fake
proxies. Make conservative guesses both ways: assume lots are needed,
assume difficulty in getting participants. Can it still be done effectively?
RFC 2505 flatly stated that securing open relays was not a viable way to
fight spam. Nonetheless that was the method of choice for years. Securing
all open relays has to be around 99% complete for it to have a visible
effect. That seems not to have yet happened.
Poisoning the pool of open relays is effective at all levels. If 10% of
the pool is fake relays then you'd estimate, I think, that twould give a
10% effectiveness against relay spam, just on the basis of non-delivered
spam messages alone. Any further effect you achieve by identifying spam
sources or spamvertised URL's is a bonus. Any extra work you force the
spammers to do to avoid fake relays is a bonus.
It works now. I think it deserves further analysis, further amplifcation.
Computing and bandwidth is cheap enough that you can't win by forcing
the spammer to burn cycles or bandwidth, unless you can increase those
costs by orders of magnitude. One person's yearly wage of, say,
$40,000 can buy 20 $1400 machines and still spend $1000/month for
bandwidth/colo. Lets see, 4TB/month. Requiring them to hire one
additional employee affects their bottom line more than blocking 10
billion emails.
The guy spending his entire yearly wage in order to spam would need, I'd
think, to earn more than that yearly wage to make spamming
worthwhile. Earning that wage takes him around 2000 hours/year - that's
his primary job. Make spamming hard enough that it takes 2000 hours of
work to earn $40,000 and any sane spammer would give up - he's putting in
4000 hours to clear what he already is earning.
> The basic idea is sound, and some very effective fake open relays are
> simply standard MTAs, reconfigured. Those aren't going to be easily
> identified. More to the point is that this entire means of combatting
> spammers and this entire opportunity to do so are both almost
> completely ignored. The idea has further extension. An ISP with a
> customer who is sending out large numbers of relay tests should be
> easily able to identify that customer strictly by the pattern of his
> outgoing traffic. A large ISP cannot monitor the entire stream of its
At least as far as outgoing traffic is concerned, wouldn't a server
doing relay tests closely resemble any popular mailing list server? It
might be identifiable if it gets a huge number of incoming RST's from
port 25.
I think it would look exactly like a mailing list server, if that server is
busy 24 hours/day. That would be some mailing list server. I don't doubt
there are such but I couldn't name any. If the TOS allow packet
examination then it's a different story - the spam and/or the relay tests
will stick out. If you DCC'd outgoing email then relay tests would be
personalized for every recipient (because most relay tests have the tested
IP either encoded or in plain text.) If you simply look at destination
IP's and compare that with the target addresses of the email then relay
tests and relay spam stick out instantly. Probably other statistical
measures that avoid actual examination of the contents of outgoing messages
would also serve to distinguish the valid form the invalid.
Here's some HTTP lines from a spam run I'm capturing - would a legitimate
mailer ever have such content in its messages?
<a href=3D"http://www.quickmailorderbrides.com/remove/?oc=3D23900";>Le<!--32=
152112-->t me kn<!--32151146-->ow an<!--321800041767-->d I won't wri<!--321=
<a href=3D"http://www.quickmailorderbrides.com/?oc=3D2390";>A ni<!--48664627=
13614-->ce lady wa<!--4866462624478155-->nts to corr<!--4866462455010778-->=
<a href=3D"http://www.quickmailorderbrides.com/remove/?oc=3D23900";>Le<!--48=
66462752305-->t me kn<!--486646222340-->ow an<!--486646222274-->d I won't w=
<a href=3D"http://www.quickmailorderbrides.com/?oc=3D2390";>A ni<!--8784534-=
->ce lady wa<!--8781671-->nts to corr<!--878231134728-->espond with you.<!-=
<a href=3D"http://www.quickmailorderbrides.com/remove/?oc=3D23900";>Le<!--87=
8566853511-->t me kn<!--87871-->ow an<!--87863245-->d I won't wri<!--878632=
<a href=3D"http://www.quickmailorderbrides.com/?oc=3D2390";>A ni<!--56486335=
7458778354-->ce lady wa<!--56486335800484-->nts to corr<!--5648633533-->esp=
<a href=3D"http://www.quickmailorderbrides.com/remove/?oc=3D23900";>Le<!--56=
48633566--><!-- b hiqzpw khxjmm npjtyl epu-->t me kn<!--564863350710-->ow a=
The messages are all to people not in my domain. How many legitimate
mailing lists are sent through relays?
r;boQbj(_at_)acnet(_dot_)net
r;danQielle(_at_)a-o(_dot_)com
r;rhQunt(_at_)americanleaseline(_dot_)com
r;mcQg(_at_)acnet(_dot_)net
r;jchQriste(_at_)addr(_dot_)com
r;cgQsecor(_at_)aol(_dot_)com
r;rolQf(_dot_)hay(_at_)address(_dot_)com
r;mvickQers(_at_)abimarketinggroup(_dot_)com
r;benloQken(_at_)alltel(_dot_)net
r;alexQica(_at_)agis(_dot_)net
r;gcQook(_at_)aaawv(_dot_)com
r;webQsite(_at_)addr(_dot_)com
r;beaQnt(_at_)airnet(_dot_)net
r;rQev(_at_)alt(_dot_)net
r;stQarr(_at_)acuson(_dot_)com
I munged the addresses slightly...
The point is not what I'm doing, the point is that more thought could be
given to fighting back against the spammers at the abuse level. There's
probably several unexplored ideas - what are they? (One guy got so tired
of the relay spam volume that he programmed a very long response packet -
to cause a buffer overflow in the sending system - to the spamware. Just
like that, after one such response, the flow stopped...)
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg