An Anti-Spam Heuristic

[Adam Sobieski]

Internet Research Task Force,
Anti-Spam Research Group,

Greetings. I have some ideas to prevent spam. A number of heuristics include increasing the computation required to send and receive an email, for example one to a few minutes of computation per email on desktop computers.

One example of a heuristic, from that category, includes the use of a random number generator, seeded or salted with a combination of the sender's email address, the recipient's email address, and the date and time of the sending of the email. Then, in the described example, some amount of computation, measurable in minutes on a desktop computer, churns a stream of bits from the random number generator, in a buffer the size of which can be obtained from the size of the email, and with those bits in that buffer then utilizable by other heuristics. The recipient of an email can, with the sender's address, their own email address, the date and time of the sending of the email, and possibly other data, seed or salt an identical random number generator, churning a stream of bits, with an indicated amount of computation, measurable in minutes, to obtain the same bits in an identically sized buffer.

By increasing the computation required to send and receive email messages, for example measurable in minutes of desktop computation, desktop graphics card computation, spam can be reduced as spammers would have to compute, per letter, per recipient, per email sending event, as described. In addition to, possibly in combination to, that category of heuristic, increasing the computation required to send and receive emails, the digital signing of email messages can be of use to preventing spam.

In addition to countering spam, I have observed some interest, in the scientific community, with regard to discussing the versioning of and advancement of email protocols, modernizing email-related computer networking protocols.



Kind regards,

Adam Sobieski

[Steve Atkins]

On Dec 12, 2012, at 5:43 PM, Adam Sobieski <***@hotmail.com> wrote:

> Greetings. I have some ideas to prevent spam. A number of heuristics include increasing the computation required to send and receive an email, for example one to a few minutes of computation per email on desktop computers.
>
> One example of a heuristic, from that category, includes the use of a random number generator, seeded or salted with a combination of the sender's email address, the recipient's email address, and the date and time of the sending of the email. Then, in the described example, some amount of computation, measurable in minutes on a desktop computer, churns a stream of bits from the random number generator, in a buffer the size of which can be obtained from the size of the email, and with those bits in that buffer then utilizable by other heuristics. The recipient of an email can, with the sender's address, their own email address, the date and time of the sending of the email, and possibly other data, seed or salt an identical random number generator, churning a stream of bits, with an indi
cated amount of computation, measurable in minutes, to obtain the same bits in an identically sized buffer.
>
> By increasing the computation required to send and receive email messages, for example measurable in minutes of desktop computation, desktop graphics card computation, spam can be reduced as spammers would have to compute, per letter, per recipient, per email sending event, as described. In addition to, possibly in combination to, that category of heuristic, increasing the computation required to send and receive emails, the digital signing of email messages can be of use to preventing spam.

You might want to look at hashcash. http://en.wikipedia.org/wiki/Hashcash

Brief summary of the conclusion: cannot work, as spammers have much easier access to free CPU cycles than do legitimate senders of mail.

Cheers,
Steve

[John Levine]

>You might want to look at hashcash. http://en.wikipedia.org/wiki/Hashcash
>
>Brief summary of the conclusion: cannot work, as spammers have much easier
>access to free CPU cycles than do legitimate senders of mail.

I wrote a white paper about e-postage eight years ago, which has stood
up pretty well. There are other fatal issues, related to the need to
whitelist mail from people whose mail you want to get.

http://www.taugh.com/epostage.pdf

[Adam Sobieski]

Steve Atkins,

Thank you, that article, summarizing decades of research, does both pertain to and discuss the concepts that I broached. A technical topic not mentioned in that article specifically is the use of the sender's email address, recipient's email address, and the date and time of the message event to seed or salt a random number generator.

I think that a quote from that article expresses a premise of the idea well: "the theory is that spammers, whose business model relies on their ability to send large numbers of emails with very little cost per message, cannot afford this investment into each individual piece of spam they send. Receivers can verify whether a sender made such an investment and use the results to help filter email."

It appears that your counterpoint is also indicated in that article which describes "botnets or cluster farms with which spammers can increase their processing power enormously."

As you might be aware, earlier this year, in the Journal of Economic Perspectives, in an article titled The Economics of Spam, Justin Rao of Microsoft and David Reiley of Google estimated the cost of spam to society relative to its worldwide revenues. The societal price tag was indicated as $20 billion while the total revenue of all spammers was indicated as $200 million. Various policy proposals designed to solve the spam problem were discussed in that publication (http://www.aeaweb.org/articles.php?doi=10.1257/jep.26.3.87, http://pubs.aeaweb.org/doi/pdfplus/10.1257/jep.26.3.87).

There may be more than one criterion for success, simultaneously, with regard to anti-spam discussions: (1) the total elimination of spam, (2) a reduction of spam, and (3) solutions which affect the economics of spam in attempts to reduce spam (2). It could be that your conclusion addresses one criterion (1), while other criteria (2) and (3) could be achieved by increasing the computational costs of sending and receiving emails.

Also, what might you think about discussions about versioning and advancing email protocols, modernizing email-related computer networking protocols?



Kind regards,

Adam

[John Levine]

>Steve Atkins,

I'm not Steve, but what the heck.

>and discuss the concepts that I broached. A technical topic not mentioned in
>that article specifically is the use of the sender's email address, recipient's
>email address, and the date and time of the message event to seed or salt a
>random number generator.

It's clever, but since the fundamental problem with proof-of-work is
that the bad guys can do more work than the good guys, the details of
the work aren't particularly interesting.

>reduce spam (2). It could be that your conclusion addresses one criterion (1),
>while other criteria (2) and (3) could be achieved by increasing the
>computational costs of sending and receiving emails.

No, because the bad guys still have more computational power than the
good guys. You could get rid of spam, but only at the cost of getting
rid of all of the rest of e-mail, too.

Effective anti-spam techniques have to be things that it's easier for
good guys to do than for bad guys to do. This turns out to be hard.
It also turns out to be subtle. For example, both good and bad
senders can apply DKIM signatures to their mail, so signing per se is
not an anti-spam technique. What makes them useful is that the
signing identifiers can be keys into reputation systems that are
designed to favor good signers.

>Also, what might you think about discussions about versioning and advancing
>email protocols, modernizing email-related computer networking protocols?

SMTP has had an extension mechanism since RFC 1869 in 1995. There
have been quite a lot of extensions proposed, some of which, such as
pipelining and 8bitmime, are now universally adopted. Early
definitions of SMTP had commands such as SOML and TURN that were found
either not to be useful, or to have serious security problems, so
they've been deprecated and eventually deleted. It's not exactly
versioning, but the protocol has evolved somewhat.

There have been a lot of proposals to "replace SMTP", but none have
come anywhere near close to demonstrating sufficient utility to
motivate people to bear the enormous switching costs from the existing
deployed system.

R's,
John

[Andrew Sullivan]

On Thu, Dec 13, 2012 at 05:43:58AM -0000, John Levine wrote:
> There have been a lot of proposals to "replace SMTP", but none have
> come anywhere near close to demonstrating sufficient utility to
> motivate people to bear the enormous switching costs from the existing
> deployed system.

Just because this hasn't be stated explictly enough this week outside
of Dubai, let me say the problem is that the underlying lookup
mechanism isn't robust enough. If we only knew who it was doing the
lookups, we could use the existing legal systems to solve these
issues. Therefore, all we need to is replace DNS; SMTP can stay where
it is in the stack.

HTH,

A

--
Andrew Sullivan
***@anvilwalrusden.com

[Chris Lewis]

On 12-12-13 04:18 AM, Andrew Sullivan wrote:
> On Thu, Dec 13, 2012 at 05:43:58AM -0000, John Levine wrote:
>> There have been a lot of proposals to "replace SMTP", but none have
>> come anywhere near close to demonstrating sufficient utility to
>> motivate people to bear the enormous switching costs from the existing
>> deployed system.
>
> Just because this hasn't be stated explictly enough this week outside
> of Dubai, let me say the problem is that the underlying lookup
> mechanism isn't robust enough. If we only knew who it was doing the
> lookups, we could use the existing legal systems to solve these
> issues. Therefore, all we need to is replace DNS; SMTP can stay where
> it is in the stack.

Knowing who looked at a phone book doesn't tell you who is making the
phone ring in the middle of the night.

Especially if its possible to copy the phone book.

And even if you did know, what makes you think the existing legal system
will always be able to help?

_Most_ western legal systems already have laws that pertain to just
about the full gamut of what spammers do. The difficulty is in
enforcing it - either getting LE interested, or having a sufficient ROI
to do it in civil law.

Eg: spoofing my email address is something actionable. But it'd be at
_least_ $25K upfront to get a lawyer doing something. And if it was
outside of Canada, start multiplying that ...

[Alessandro Vesely]

On Thu 13/Dec/2012 16:29:41 +0100 Chris Lewis wrote:
> On 12-12-13 04:18 AM, Andrew Sullivan wrote:
>>
>> If we only knew who it was doing the lookups, we could use the
>> existing legal systems to solve these issues.
>
> And even if you did know, what makes you think the existing legal
> system will always be able to help?

That's something we should make pretty clear, for the sake of the
Internet revolution, digital era, and all that sort: If we need to
call the cops to deal with plain spam, we can give up that quest
altogether.

We MUST be able to achieve the total elimination of spam (1) using
only our puters and remote cooperation. For the time being, we have
some difficulties just defining the term, but there's plenty of time
to improve :-)

[Barry Shein]

My retort to "replace SMTP" is always why not just add some new code
like NOTS (switch to not smtp) to SMTP and proceed from there with
your new-fangled protocol.

Add support to the handful of major mailers, in some cases you can do
that with an external program (e.g., milter), you don't even have to
hack the code base, and off you go.

So, that's not the obstacle.

-b

[Barry Shein]

There's also Jef Poskanzer's greymilter which basically requires one
re-send from each never before seen mail server not in a white list.

And sendmail (and others') HELO delay (delay sending HELO a short
period of time) and don't speak until you're spoken to whatever they
call it (I use it, the sender must wait for the SMTP responses, can't
just dump an SMTP conversation at you.)

They're basically isomorphic to hashcash type solutions, increase the
sender's cost, but very transparent and quite clever because of that.

--
-Barry Shein

The World | ***@TheWorld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada
Software Tool & Die | Public Access Internet | SINCE 1989 *oo*

[Michael Thomas]

On 12/13/2012 09:16 AM, Barry Shein wrote:
> There's also Jef Poskanzer's greymilter which basically requires one
> re-send from each never before seen mail server not in a white list.
>
> And sendmail (and others') HELO delay (delay sending HELO a short
> period of time) and don't speak until you're spoken to whatever they
> call it (I use it, the sender must wait for the SMTP responses, can't
> just dump an SMTP conversation at you.)
>
> They're basically isomorphic to hashcash type solutions, increase the
> sender's cost, but very transparent and quite clever because of that.
>
Given botnets, anything that tries to shift burden back onto the
sender is not very likely to be effective in the long run. Yes, you
might get some short term relief, but the firehose is just a software
update away.

Mike

[Barry Shein]

On December 13, 2012 at 09:21 ***@mtcc.com (Michael Thomas) wrote:
> On 12/13/2012 09:16 AM, Barry Shein wrote:
> > There's also Jef Poskanzer's greymilter which basically requires one
> > re-send from each never before seen mail server not in a white list.
> >
> > And sendmail (and others') HELO delay (delay sending HELO a short
> > period of time) and don't speak until you're spoken to whatever they
> > call it (I use it, the sender must wait for the SMTP responses, can't
> > just dump an SMTP conversation at you.)
> >
> > They're basically isomorphic to hashcash type solutions, increase the
> > sender's cost, but very transparent and quite clever because of that.
> >
> Given botnets, anything that tries to shift burden back onto the
> sender is not very likely to be effective in the long run. Yes, you
> might get some short term relief, but the firehose is just a software
> update away.

Has this been measured (reference)? Or is this just one of those
"truisms" that kick around here?

I'm thinking that a spammer has to put out on the order of a billion
messages (attempts) per day to be interesting.

If you slowed those down that would be a blow to them, a billion times
even a little is a lot.

Sure, we can postulate infinite botted systems I suppose.

But that's still just a wild guess.

I'm not arguing for hashcash per se, I think it has other problems,
but I also wonder if this counter-claim is really true.

Or, put better, can we quantify it?


--
-Barry Shein

The World | ***@TheWorld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada
Software Tool & Die | Public Access Internet | SINCE 1989 *oo*

[Steve Atkins]

On Dec 13, 2012, at 2:52 PM, Barry Shein <***@world.std.com> wrote:

>
> On December 13, 2012 at 09:21 ***@mtcc.com (Michael Thomas) wrote:
>> On 12/13/2012 09:16 AM, Barry Shein wrote:
>>> There's also Jef Poskanzer's greymilter which basically requires one
>>> re-send from each never before seen mail server not in a white list.
>>>
>>> And sendmail (and others') HELO delay (delay sending HELO a short
>>> period of time) and don't speak until you're spoken to whatever they
>>> call it (I use it, the sender must wait for the SMTP responses, can't
>>> just dump an SMTP conversation at you.)
>>>
>>> They're basically isomorphic to hashcash type solutions, increase the
>>> sender's cost, but very transparent and quite clever because of that.
>>>
>> Given botnets, anything that tries to shift burden back onto the
>> sender is not very likely to be effective in the long run. Yes, you
>> might get some short term relief, but the firehose is just a software
>> update away.
>
> Has this been measured (reference)? Or is this just one of those
> "truisms" that kick around here?
>
> I'm thinking that a spammer has to put out on the order of a billion
> messages (attempts) per day to be interesting.
>
> If you slowed those down that would be a blow to them, a billion times
> even a little is a lot.

The cost to spammers using almost free, botted systems is always going
to be a lot lower than the cost to legitimate senders using expensive,
well managed systems.

Anything you do to make sending mail more expensive that isn't
pretty good at differentiating between legitimate and illegitimate
senders is going to harm legitimate senders disproportionately.

You can buy a rooted asian box for <$5. ESP-grade MTAs and
management systems can be up in the tens of K per box - so
if you double the average delivery latency then you've cost the
spammer $5 and the legitimate sender $5000. That doesn't work.

Cheers,
Steve

[Barry Shein]

Just "no" would have been sufficient. There's nothing wrong with
liking the idea, but quantified is something else entirely.

-b

On December 13, 2012 at 15:10 ***@blighty.com (Steve Atkins) wrote:
>
> On Dec 13, 2012, at 2:52 PM, Barry Shein <***@world.std.com> wrote:
>
> >
> > On December 13, 2012 at 09:21 ***@mtcc.com (Michael Thomas) wrote:
> >> On 12/13/2012 09:16 AM, Barry Shein wrote:
> >>> There's also Jef Poskanzer's greymilter which basically requires one
> >>> re-send from each never before seen mail server not in a white list.
> >>>
> >>> And sendmail (and others') HELO delay (delay sending HELO a short
> >>> period of time) and don't speak until you're spoken to whatever they
> >>> call it (I use it, the sender must wait for the SMTP responses, can't
> >>> just dump an SMTP conversation at you.)
> >>>
> >>> They're basically isomorphic to hashcash type solutions, increase the
> >>> sender's cost, but very transparent and quite clever because of that.
> >>>
> >> Given botnets, anything that tries to shift burden back onto the
> >> sender is not very likely to be effective in the long run. Yes, you
> >> might get some short term relief, but the firehose is just a software
> >> update away.
> >
> > Has this been measured (reference)? Or is this just one of those
> > "truisms" that kick around here?
> >
> > I'm thinking that a spammer has to put out on the order of a billion
> > messages (attempts) per day to be interesting.
> >
> > If you slowed those down that would be a blow to them, a billion times
> > even a little is a lot.
>
> The cost to spammers using almost free, botted systems is always going
> to be a lot lower than the cost to legitimate senders using expensive,
> well managed systems.
>
> Anything you do to make sending mail more expensive that isn't
> pretty good at differentiating between legitimate and illegitimate
> senders is going to harm legitimate senders disproportionately.
>
> You can buy a rooted asian box for <$5. ESP-grade MTAs and
> management systems can be up in the tens of K per box - so
> if you double the average delivery latency then you've cost the
> spammer $5 and the legitimate sender $5000. That doesn't work.
>
> Cheers,
> Steve
>
> _______________________________________________
> Asrg mailing list
> ***@irtf.org
> http://www.irtf.org/mailman/listinfo/asrg

[Chris Lewis]

Ooh, quantitative ;-)

For grins, I took one of my smaller spamtraps and applied a 30 second
banner delay. I wanted to quantify

"And a lot of spamware doesn't flunk."

In the timestamps below, the change happened at 04:52.

Flow per minute:

156 2012/12/14-04:39
205 2012/12/14-04:40
189 2012/12/14-04:41
188 2012/12/14-04:42
167 2012/12/14-04:43
165 2012/12/14-04:44
181 2012/12/14-04:45
138 2012/12/14-04:46
185 2012/12/14-04:47
173 2012/12/14-04:48
152 2012/12/14-04:49
113 2012/12/14-04:50
156 2012/12/14-04:51
30 2012/12/14-04:52
46 2012/12/14-04:53
46 2012/12/14-04:54
63 2012/12/14-04:55
46 2012/12/14-04:56
55 2012/12/14-04:57
41 2012/12/14-04:58
51 2012/12/14-04:59
41 2012/12/14-05:00
30 2012/12/14-05:01

A 3:1 spam reduction is nothing to sneeze at.

Not only that, but I can tell you that Lethic (Windows spambot) stopped
dead in its tracks, and it looks like both Cutwail and Darkmailer2 (a
combination of 2 or 3 Linux server infestation types) were affected
severely too.

This server flow is quite low, and isn't seeing flow from several other
bots (eg: Kelihos and Festi) at the moment, so I don't know what other
ones die. But it's a start.

I'll have to try this on a few other bots, bigger traps and different
delays.

Oh, as a FYI, relatively few connections failed to wait for the banner.

[Chris Lewis]

On 12-12-13 11:39 PM, Chris Lewis wrote:

> I'll have to try this on a few other bots, bigger traps and different
> delays.

As a FYI, I tried it again.

It looks like Kelihos and Festi are also stopped dead in their tracks by
a 30 second banner delay.

That means that all of the currently high-volume spambots, except
Cutwail and Darkmailer (usually Linux) are stopped by a 30 second delay.

Kelihos is alternately spewing HUGE quantities of viral infectors and
Toronto Pharmacy pillz spam.

Festi is trying to spew huge quantities of Canadian Pharmacy Pillz spam.

There are many versions of cutwail in the field, under the control of at
least a dozen different operators. It's quite possible that a 30 second
delay impairs some of them and longer delays will impair yet more.
OTOH, cutwail has multiple operating modes (including AUTH cracking)
which wouldn't be impacted by banner delays.

It looks like the darkmailerish code I have has 60 second timeouts.

[Alessandro Vesely]

On Fri 14/Dec/2012 05:39:21 +0100 Chris Lewis wrote:
> Ooh, quantitative ;-)
>
> For grins, I took one of my smaller spamtraps and applied a 30 second
> banner delay. I wanted to quantify
>
> "And a lot of spamware doesn't flunk."
>
> In the timestamps below, the change happened at 04:52.
>
> Flow per minute:
> [snip]
> 156 2012/12/14-04:51
> 30 2012/12/14-04:52
>
> A 3:1 spam reduction is nothing to sneeze at.

You need at least 15 daemons accepting 2 msgs/minute each to get 30
messages, while at, say, 60 msgs/minute 3 daemons can take 180.

> Oh, as a FYI, relatively few connections failed to wait for the banner.

Can you confirm the max-daemons limit wasn't hit? A deadly slow TCP
backlog could cause clients to timeout. In that case, banner delay
would work similar to random connection dropping as done, e.g. by
stockade (see http://en.wikipedia.org/wiki/Stockade_%28software%29.)

On a real MX, rather than being fixed at 30 seconds, the banner delay
should be made proportional to the spammitude reckoned for the sending
IP. Sort of tarpitting, perhaps not the FUSSP itself, but...

[Chris Lewis]

On 12-12-16 06:50 AM, Alessandro Vesely wrote:
> On Fri 14/Dec/2012 05:39:21 +0100 Chris Lewis wrote:
>> Ooh, quantitative ;-)
>>
>> For grins, I took one of my smaller spamtraps and applied a 30 second
>> banner delay. I wanted to quantify
>>
>> "And a lot of spamware doesn't flunk."
>>
>> In the timestamps below, the change happened at 04:52.
>>
>> Flow per minute:
>> [snip]
>> 156 2012/12/14-04:51
>> 30 2012/12/14-04:52
>>
>> A 3:1 spam reduction is nothing to sneeze at.

Small update: Kelihos and Lethic are stopped dead with a 30 second
delay. Unlike previous reports, Festi actually appears unaffected.

These tests were very short duration and given the small size of the
trap, it's sometimes difficult to tell the difference between natural
flow variation and clear effect. With Lethic and Kelihos it's
absolutely unmistakeable. Festi looked at first, but it wasn't doing
much anyway and later showed it wasn't dead.

> You need at least 15 daemons accepting 2 msgs/minute each to get 30
> messages, while at, say, 60 msgs/minute 3 daemons can take 180.

The trap is 20 simultaneous daemons, _each_ multi-threaded (event driven).

When pushed, the traps can have several thousand SMTP sessions
simultaneously in progress.

We weren't anywhere near hitting a limit.

Obviously, this can be a consideration - I wouldn't want to set a
several minute delay on one of the traps currently doing 700 emails/second.

I've tried this on two of our smallest traps for this very reason - and
this is why I was only able to relate the effects on the very highest
volume bots.

[One of our traps is capable of and has _seen_ sustained thruput of 6-7
_thousand_ per second.]

> Can you confirm the max-daemons limit wasn't hit?

Yup, see above.

> On a real MX, rather than being fixed at 30 seconds, the banner delay
> should be made proportional to the spammitude reckoned for the sending
> IP. Sort of tarpitting, perhaps not the FUSSP itself, but...

Right. I did this as simply as I could. In production, you'd want
something much smarter.

The idea isn't to "punish" (like tarpit), the idea is to distinguish as
simply and cheaply as possible what is highly non-RFC-compliant, and
ignore ignore them from then on.

Something like;

> if (this is the first time in t0 seconds you've seen a given IP)
> then
> banner delay it for t1 seconds.
> elsif (this is the second time in t0 seconds you've seen a given IP)
> then
> if (it previously passed)
> then
> don't banner delay
> else
> banner delay for t1 seconds
> else
> if (it previously passed)
> then
> don't banner delay
> else
> drop at connect

then twiddle the tn's. The second "kick at the delay" is to allow for
a legitimate mail server or network hiccup - the banner delay will be
treated as a retry and you want the retry to work.

[Michael Thomas]

Barry Shein wrote:
> On December 13, 2012 at 09:21 ***@mtcc.com (Michael Thomas) wrote:
> > On 12/13/2012 09:16 AM, Barry Shein wrote:
> > > There's also Jef Poskanzer's greymilter which basically requires one
> > > re-send from each never before seen mail server not in a white list.
> > >
> > > And sendmail (and others') HELO delay (delay sending HELO a short
> > > period of time) and don't speak until you're spoken to whatever they
> > > call it (I use it, the sender must wait for the SMTP responses, can't
> > > just dump an SMTP conversation at you.)
> > >
> > > They're basically isomorphic to hashcash type solutions, increase the
> > > sender's cost, but very transparent and quite clever because of that.
> > >
> > Given botnets, anything that tries to shift burden back onto the
> > sender is not very likely to be effective in the long run. Yes, you
> > might get some short term relief, but the firehose is just a software
> > update away.
>
> Has this been measured (reference)? Or is this just one of those
> "truisms" that kick around here?
>
> I'm thinking that a spammer has to put out on the order of a billion
> messages (attempts) per day to be interesting.
>
> If you slowed those down that would be a blow to them, a billion times
> even a little is a lot.
>
> Sure, we can postulate infinite botted systems I suppose.
>
> But that's still just a wild guess.
>
> I'm not arguing for hashcash per se, I think it has other problems,
> but I also wonder if this counter-claim is really true.
>
> Or, put better, can we quantify it?

If tarpitting and other such things were the FUSSP, then everybody would use them,
and the unicorns would come out of hiding. If spammers haven't adjusted their botnet
software, then it really says that there's no evolutionary pressure for them to do so.
If there is, they will do so. What else would they do? Go out of business? They aren't stupid.

Mike

[Chris Lewis]

On 12-12-13 08:26 PM, Michael Thomas wrote:

> If tarpitting and other such things were the FUSSP, then everybody would
> use them,
> and the unicorns would come out of hiding. If spammers haven't adjusted
> their botnet
> software, then it really says that there's no evolutionary pressure for
> them to do so.
> If there is, they will do so. What else would they do? Go out of
> business? They aren't stupid.

Enough of them have changed to indicate that there is _some_ pressure.

Indeed, pure botnet was, until recently, generally responsible for
85-95% of all spam.

Right now, tho, it's about 40% compromised Linux _servers_.

Yes. Really.

[Adam Sobieski]

Internet Research Task Force,
Anti-Spam Research Group,

I have an idea to defend computers from botnets to reduce spam. On a computer security topic, what do you think about the idea of utilizing one or more P2P DHT's and the hashes of each file, or each important file, on computers? Based upon the hardware specifications, platform, compiler, and compiler version, the hashes of compiled item or downloaded binary items can be compared to the hashes of the files on other Linux servers. That is an example of how P2P technologies can enhance Linux servers.

Another security procedure, extending from that one, could be to remove the disks, the hard drives, from computers, periodically, and to scan the file systems and other disk sectors, using other computing devices, to obtain the hashes of each file and to then utilize some resource, e.g. a P2P DHT, to compare the hashes of those files to the hashes of the files on other computers.



Kind regards,

Adam Sobieski

[Chris Lewis]

On 12-12-13 11:49 PM, Adam Sobieski wrote:
> Internet Research Task Force,
> Anti-Spam Research Group,
>
> I have an idea to defend computers from botnets to reduce spam. On a
> computer security topic, what do you think about the idea of utilizing
> one or more P2P DHT's and the hashes of each file, or each important
> file, on computers? Based upon the hardware specifications, platform,
> compiler, and compiler version, the hashes of compiled item or
> downloaded binary items can be compared to the hashes of the files on
> other Linux servers. That is an example of how P2P technologies can
> enhance Linux servers.

Obviously, it can't be all files. Otherwise, all computers would be
identical ;-) Then you have to consider all the versions of the code.
Then the highly idiosyncratic mix of other software versions that may be
on the machine in unusual places. Etc.

This is more-or-less a distributed version of tripwire (which dates back
to the 1980's, IIRC, introduced in an early edition of Gene Spafford's
UNIX Security O'Reilly book), or, for somewhat newer stuff, consider
rkhunter & "rkhunter --propupd".

I worked for a company in the mid 80's that did this in a
semi-distributed fashion.

While I'm not intimately familiar with all versions of Linux spamware,
you have the following considerations:

- As far as I am aware, Linux spam compromises relatively seldom involve
replacing existing programs. They're entirely new files, often in
unusual places. You're unlikely to have something to compare checksums
against. Then what?

- A lot of compromises involve changed config files. What does a
checksum comparison of a config file to other machines mean? Nothing.
You can tripwire them, but in busy multi-hosting environments, you'll
get flooded with false positives.

- A large class of compromises are based around programs you _can't_
find on disk. Each spamrun begins with: download program, start
program, program removes its own files, start spamming. There's nothing
to checksum for more than a few seconds.

- Many hosting environments can have multiple versions of the same code
(especially stuff like Wordpress or Joomla) operating simultaneously.
How does the code know what to compare checksums with?

Such techniques sound promising, but once you get into trying to run one
of them in a large enough scale to do something useful, you find out
it's a lot harder than it looks, and not nearly as effective as you'd like.

I run rkhunter. I run Rkhunter to see if I can tell people to use it to
find compromises. I keep throwing infections on the machine (but don't
start them). It hasn't found any of them... Sigh.

[rkhunter has an explicit "rootkit finder" module in addition to its
tripwire capability. I don't know how the RK finder works (they don't
say ;-) - I'm sure I could find out but...), but, it's not finding the
darkmailer and r57shell and ... tidbits I'm laying around as bait... So...]

> Another security procedure, extending from that one, could be to remove
> the disks, the hard drives, from computers, periodically, and to scan
> the file systems and other disk sectors, using other computing devices,
> to obtain the hashes of each file and to then utilize some resource,
> e.g. a P2P DHT, to compare the hashes of those files to the hashes of
> the files on other computers.

That'd go over really well in large-scale production multi-hosting
environments.... ;-)

You don't have to go that far. Boot from CD. Or see how tripwire gets
around this.

[Rich Kulawiec]

In addition to Chris's excellent comments:

- Connecting a [Linux or other] server to a P2P network may not be possible
or desirable in many/most instances.

- Use of a technique like this might leak information on which software
is installed, which versions, etc.

- It will trigger false positives whenever software is upgraded/patched.
(I say "will" because very long experience with tripwire and similar
taught me this a long time ago.)

- If the server has been subverted, then this mechanism can also
be subverted.

- Linux systems are not a significant component of botnets. I've been
doing passive OS fingerprinting for most of a decade, and they're in
the noise floor. It's still true now, as it was years ago, that
bot-originated spam comes from Windows systems to about six 9's.

- Better techniques already exist, such a firewalling outbound port 25
by default and only punching holes for systems that actually need to
send mail. Another example: monitoring the TCP connection rate to
port 25 on remote systems -- spam-senders are likely to push it much
higher than "normal".

---rsk

[Chris Lewis]

On 12-12-14 08:39 AM, Rich Kulawiec wrote:

> - Linux systems are not a significant component of botnets. I've been
> doing passive OS fingerprinting for most of a decade, and they're in
> the noise floor. It's still true now, as it was years ago, that
> bot-originated spam comes from Windows systems to about six 9's.

If only that were still true. Sorry Rich.

Compromised Linux machines (mostly servers) are now responsible for ~40%
of all spam.

The actual _count_ of compromised Linux machines is indeed quite low.
Say 62K out of 8.6M observed compromised machines. About .72%. Two 9's ;-)

But prolific?

I have individual IPs out in the wild that have shoved >1M spams into a
single trap in <48 hours. I have a copy of one of these bots. I
periodically run it on a wimpy dual-Atom linux laptop to characterize
what it's sending at the time. It shoves 65 spams per _second_.

Imagine what a real server could do on industrial grade connections.

And the machine owners don't notice!

> - Better techniques already exist, such a firewalling outbound port 25
> by default and only punching holes for systems that actually need to
> send mail. Another example: monitoring the TCP connection rate to
> port 25 on remote systems -- spam-senders are likely to push it much
> higher than "normal".

Unfortunately,, getting people to deploy those is worse than pulling teeth.

[Rich Kulawiec]

On Fri, Dec 14, 2012 at 10:08:48AM -0500, Chris Lewis wrote:
> Compromised Linux machines (mostly servers) are now responsible for ~40%
> of all spam.
>
> The actual _count_ of compromised Linux machines is indeed quite low.
> Say 62K out of 8.6M observed compromised machines. About .72%. Two 9's ;-)

I believe you. This suggests two possibilities:

1. Somethings's broken somewhere in my experimental design between data
acquisition and statistical analysis.

or

2. We're talking apples and oranges and that's why our numbers are so
different. To clarify: I'm not trying to measure spam volume, just
the number of systems (and their OS types). And to clarify further:
I classify a system as a bot if it meets a set of criteria that includes
more than sending spam: I may also classify it as a bot if it's doing
brute-force SSH/FTP/IMAP/etc. attacks, if it's doing port scans, etc.
(The "may" is there because some systems engaged in these activities don't
appear to be bots. Of course that's a judgment call and I'm sure I make
FP and FN mistakes.)

For example, if 190.147.78.102 (Static-IP-cr19014778102.cable.net.co,
thus probably in Colombia) makes 133 different IMAP login attempts,
I'm going to conclude that it's not a bored user in Bogota with
nothing better to do, it's most likely a bot doing that.

Do you think #2 explains the difference in our numbers, or do I have
to make a LOT of coffee and dig into #1?

---rsk

[Chris Lewis]

On 12-12-14 12:44 PM, Rich Kulawiec wrote:
> On Fri, Dec 14, 2012 at 10:08:48AM -0500, Chris Lewis wrote:
>> Compromised Linux machines (mostly servers) are now responsible for ~40%
>> of all spam.
>>
>> The actual _count_ of compromised Linux machines is indeed quite low.
>> Say 62K out of 8.6M observed compromised machines. About .72%. Two 9's ;-)
>
> I believe you.

Would I lie to you Rich? ;-)

Let me remind you of what you said:

>> - Linux systems are not a significant component of botnets. I've been
>> doing passive OS fingerprinting for most of a decade, and they're in
>> the noise floor. It's still true now, as it was years ago, that
>> bot-originated spam comes from Windows systems to about six 9's.

You made two assertions there. I'm more or less agreeing with the
former (linux botnet infections are rare compared to Windows), but
disagreeing with the second - 40% of all spam right now is from that
small number of Linux botnet infections.

> And to clarify further:
> I classify a system as a bot if it meets a set of criteria that includes
> more than sending spam: I may also classify it as a bot if it's doing
> brute-force SSH/FTP/IMAP/etc. attacks, if it's doing port scans, etc.

The term "botnet" is somewhat nebulous. It's perhaps best that you
consider it to be an infection of some sort that does things via
"network initiated" command&control.

And do remember I was specifically addressing an assertion about _spam_.
Not other botish things.

The "tame" linux spambot I have periodically fetches commands from
somewhere in the Ukraine, and spams based on those commands.

The traditional darkmailer infection is more of a cgi that's accessible
via the infectee's web server, and is either manually or automatically
controlled.

> Do you think #2 explains the difference in our numbers, or do I have
> to make a LOT of coffee and dig into #1?

We're comparing apples to oranges and apples. Forget about the oranges
bit ;-)

[Barry Shein]

On December 14, 2012 at 10:08 clewis+***@mustelids.ca (Chris Lewis) wrote:
>
> Compromised Linux machines (mostly servers) are now responsible for ~40%
> of all spam.

Any information on how they are being compromised?


--
-Barry Shein

The World | ***@TheWorld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada
Software Tool & Die | Public Access Internet | SINCE 1989 *oo*

[Chris Lewis]

On 12-12-15 11:38 AM, Barry Shein wrote:
>
> On December 14, 2012 at 10:08 clewis+***@mustelids.ca (Chris Lewis) wrote:

> > Compromised Linux machines (mostly servers) are now responsible for ~40%
> > of all spam.

> Any information on how they are being compromised?

- Wordpress and Joomla seem to be subject to a never-ending blizzard of
various file-upload compromises. While ensuring that the customers
using them are using the very latest patches seems to help a _lot_,
that's apparently something that not all hosters attempt to enforce, and
tomorrow there'll be another compromise discovered.

- Some multi-host platforms are inherently leaky. IIUC, Cpanel has anon
ftp turned on by default.

- Files uploaded via compromised customer userid/password are extremely
common, and have been for quite a while. Small-medium environments are
under surprisingly high phishing pressure. Even my teensy regional ISP
is subject to a never ending wave of phishes.

[Adam Sobieski]

Internet Research Task Force,
Anti-Spam Research Group,

Thank you for the information Chris and Rich. A summary of that idea could then be a distributed version of Tripwire, adding P2P, e.g. distributed hash tables, or other distributed and decentralized algorithms, to software approaches like Tripwire. P2P networks can facilitate such software having access to data from numerous other computers.

With such P2P techniques, Windows systems could be easier to secure than some Linux systems. In the data about various Linux systems and servers, however, we might see identically configured systems, systems running the freshest versions of various Linux distributions and the freshest versions of each of a set of applications.

On the topic of countering botnets to reduce spam, and on the topic of the approach of seeking to keep well-informed any interested computer scientists about developments, and on the topic of distributed and decentralized applications, we can consider decentralized and distributed systems, with all-to-all messaging capability, where any users can upload a message and any users can download a message. In many system designs with user-generated content, countering spam is topical, including systems for disseminating instantaneous information to computer scientists about securing computers and computer networks, countering botnets to reduce spam.

Blogs could be an implementation of all-to-all messaging where folksonomic tags could be utilized, from a vocabulary, to describe specific computer system configurations and situations.

Usenet, or NNTP, could be utilized by computer scientists and would be more convenient with a means of prefixing message subject strings to indicate computer configurations.

Email and mailing lists could be utilized in an implementation, as well, with the same topic about subject string prefixes to indicate the computer configurations discussed in the message.

In each of those examples is the problem of spam.

As an aside, we could version NNTP, as well as email-related protocols, to include metadata-related enhancements, for purposes including searchability, potentially metadata models beyond those of blog articles.

In addition to blogs, Usenet and mailing lists, there exist P2P system designs for all-to-all messaging; for example, based upon file-sharing networks. In such systems, any computer scientist could upload a computer security related message, with metadata indicating topical specific computer configurations, and any computer scientist, seeking to receive messages about a set of specific computer configurations, could download such messages from uploaders as they arrive. Metadata-based search of objects on distributed systems, P2P systems, could then be topical.

Metadata, again, beyond that of blog articles, can enhance blogs, Usenet, email and P2P systems. Systems can be designed to facilitate the well-informedness of computer scientists by computer scientists towards securing computer systems including to prevent botnets which can eliminate or reduce spam. That is, an information distribution network for computer security messages can enhance computer and computer network security.

In each described system with user-generated content, countering spam enhances usability, utility, and user experience. As a proponent of public forums, preventing spam on Usenet is an interesting topic which pertains to promoting free speech and civil discourse. Do any of you know of any detailed reports or analyses about Usenet spam data, archived Usenet data, or statistics, possibly correlations at the granularity of specific forums, thread topics, or discussion events?



Kind regards,

Adam Sobieski

[John Levine]

>Thank you for the information Chris and Rich. A summary of that idea
>could then be a distributed version of Tripwire, adding P2P, e.g.
>distributed hash tables, or other distributed and decentralized
>algorithms, to software approaches like Tripwire. ...

Other than the magic term P2P, what does this provide above what
packages like Tripwire do now? Any particular distribution of Linux
is installed from a known set of masters, where the files have known
checksums. The checksums are not large, and are not a big deal to
retrieve. What does P2P add? Random other Linux boxes are certainly
not more likely to have a set of good checksums than, say, an https
server run by a well known distribution organization.

[Chris Lewis]

On 12-12-14 08:17 PM, John Levine wrote:

> Other than the magic term P2P, what does this provide above what
> packages like Tripwire do now? Any particular distribution of Linux
> is installed from a known set of masters, where the files have known
> checksums. The checksums are not large, and are not a big deal to
> retrieve. What does P2P add? Random other Linux boxes are certainly
> not more likely to have a set of good checksums than, say, an https
> server run by a well known distribution organization.

I _suppose_ it might make it a bit more feasible to obtain checksums of
random code that isn't necessarily in sync with a Linux dist.

In many hosting environments, there can be literally as many versions
of, say, Wordpress, as there are customers. The admins steadily patch
the basic O/S, but often they won't touch the customer's images for fear
of breaking them.

Or virtualized systems. Just imagine how many different O/S images
there are on a cloud. Eg: Amazon expects the customer to do their _own_
patching.

I really don't think the idea would work in the end of the industry
(cloud, multi-host platforms) that need it most.

[Seth]

Barry Shein <***@world.std.com> wrote:

> There's also Jef Poskanzer's greymilter which basically requires one
> re-send from each never before seen mail server not in a white list.
>
> And sendmail (and others') HELO delay (delay sending HELO a short
> period of time) and don't speak until you're spoken to whatever they
> call it (I use it, the sender must wait for the SMTP responses, can't
> just dump an SMTP conversation at you.)
>
> They're basically isomorphic to hashcash type solutions, increase the
> sender's cost, but very transparent and quite clever because of that.

They have nothing to do with increasing the sender's cost. Rather,
they take advantage of the fact that legitimate mailers implement the
RFCs in ways that spamware typically doesn't, so they test for that
and spamware flunks.

Seth

[Steve Atkins]

On Dec 13, 2012, at 12:59 PM, Seth <***@panix.com> wrote:

> Barry Shein <***@world.std.com> wrote:
>
>> There's also Jef Poskanzer's greymilter which basically requires one
>> re-send from each never before seen mail server not in a white list.
>>
>> And sendmail (and others') HELO delay (delay sending HELO a short
>> period of time) and don't speak until you're spoken to whatever they
>> call it (I use it, the sender must wait for the SMTP responses, can't
>> just dump an SMTP conversation at you.)
>>
>> They're basically isomorphic to hashcash type solutions, increase the
>> sender's cost, but very transparent and quite clever because of that.
>
> They have nothing to do with increasing the sender's cost. Rather,
> they take advantage of the fact that legitimate mailers implement the
> RFCs in ways that spamware typically doesn't, so they test for that
> and spamware flunks.

And a lot of spamware doesn't flunk. Yet it can damage legitimate use of email,
both when the senders aren't following RFCs strictly (lots of senders will
give up if a recipients MX is so overloaded/broken that it's not responding
after tens of seconds) or when they are (greylisting in particular really
breaks active mailing lists, by reordering discussions into a fairly random
order).

It's the sort of thing that people tend to do because it makes them feel
like they're sticking one to spammers - which isn't a bad reason, by any
means, but doesn't lead towards optimal solutions.

Cheers,
Steve

[Chris Lewis]

On 12-12-13 04:08 PM, Steve Atkins wrote:

> And a lot of spamware doesn't flunk.

The vast majority of spamware _still_ flunks.

> It's the sort of thing that people tend to do because it makes them feel
> like they're sticking one to spammers - which isn't a bad reason, by any
> means, but doesn't lead towards optimal solutions.

Tarpitting/teergrubing et. al. are normally what people try in a
mistaken attempt to punish spammers.

Supposedly you don't do that if it isn't spam, the problem being is that
if you pick wrong, some legitimate email gets broken and some bad mail
gets through. And there's no way you can punish a botnet enough to make
any difference.

Banner delay, MX tricks (ie: "no listing") aren't "punishment" methods,
they're highly effective filtering techniques in their own right. They
don't require that you guess right as to whether the email is spam or not.

While dumb banner delay mechanisms can push damage and slow-downs back
on the sender, intelligently designed ones don't have to. After all, if
it passes a banner delay, you _know_ that the next time it connects it
probably won't flunk either. So only the first connection (over however
long you decide to "remember" it) suffers the delay.

Secondly, in this day and age, increasing the average delivery time,
say, by a factor of two, does NOT imply that the thruput per unit time
goes down by a factor of two. Hint: multi-thread mail servers[+].
Bandwidth requirements don't change.

[+] Relatively modest SMTP receivers _might_ have hundreds or even
thousands of simultaneous live connections at any given moment (my traps
do). So can senders.

[John Levine]

>after tens of seconds) or when they are (greylisting in particular really
>breaks active mailing lists, by reordering discussions into a fairly random
>order).

Sounds like a badly broken greylister. Mine still deters a remarkable amount
of spam, but since it whitelists every IP that's retried, its effect on normal
mail is quite tiny.

[Barry Shein]

On December 13, 2012 at 15:59 ***@panix.com (Seth) wrote:
> Barry Shein <***@world.std.com> wrote:
>
> > There's also Jef Poskanzer's greymilter which basically requires one
> > re-send from each never before seen mail server not in a white list.
> >
> > And sendmail (and others') HELO delay (delay sending HELO a short
> > period of time) and don't speak until you're spoken to whatever they
> > call it (I use it, the sender must wait for the SMTP responses, can't
> > just dump an SMTP conversation at you.)
> >
> > They're basically isomorphic to hashcash type solutions, increase the
> > sender's cost, but very transparent and quite clever because of that.
>
> They have nothing to do with increasing the sender's cost. Rather,
> they take advantage of the fact that legitimate mailers implement the
> RFCs in ways that spamware typically doesn't, so they test for that
> and spamware flunks.

Not true.

They don't implement RFCs accurately because they're trying to send
faster/cheaper.

Even e-bay for example had a problem when this "demand they wait for a
response" feature started to become popular because they too figured
out they could just dump one side of the SMTP conversation w/o waiting
for responses and it previously worked well enough and was much
"cheaper" on their servers.

Spamware did it because it was computationally and networktationally
cheaper. Which is what hashcash et al is all about.

And the same is true of making them re-try the first time
(graylisting.)

Again, not an argument for hashcash, just clarifying that it's all the
same thing.

It wasn't that they were poor at following RFCs, it was cheaper to
carbitrage the protocol.

--
-Barry Shein

The World | ***@TheWorld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada
Software Tool & Die | Public Access Internet | SINCE 1989 *oo*

[John Levine]

>They don't implement RFCs accurately because they're trying to send
>faster/cheaper.

Actually, a lot of it is still because they're sloppy and inept. Not
all spammers are stupid, but a lot of them are. This one, for example
(I know, I was there):

http://www.justice.gov/usao/nj/Press/files/Rad,%20Christopher%20Verdict%20PR.html

>Even e-bay for example had a problem when this "demand they wait for a
>response" feature started to become popular because they too figured
>out they could just dump one side of the SMTP conversation w/o waiting
>for responses and it previously worked well enough and was much
>"cheaper" on their servers.

That was just broken. There's a perfectly well specified way to do
SMTP pipelining, which lets clients skip most of the waits without
losing the responses.

R's,
John

[Barry Shein]

See:

http://en.wikipedia.org/wiki/Penny_Black_%28research_project%29

--
-Barry Shein

The World | ***@TheWorld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada
Software Tool & Die | Public Access Internet | SINCE 1989 *oo*

[Rich Kulawiec]

> A number of heuristics include increasing the computation required to
> send and receive an email, for example one to a few minutes of computation
> per email on desktop computers.

Presume an adversary with computing resources that routinely range in
the area of "tens of millions of systems", with all the processing,
memory, disk, and bandwidth resources that implies. Presume that those
systems are capable of coordinated or independent tasks as designated
by the adversary. Show how this approach will have a meaningful effect
on the adversary's ability to generate/transmit [SMTP] spam.

Simultaneously, presume the existence of hundreds of thousands of highly
useful mailing lists (e.g., "ietf", "nanog") with varying numbers of
members and show how this approach will not adversely affect their
ability to function in the way they've been functioning for decades.

I don't think you can do this. I think you're trying to drown someone
who owns the ocean, and that the attempt is futile. But perhaps you have
an approach that's eluded others, that overcomes the obvious problems,
and I just don't see it yet due to insufficient caffeine intake.

---rsk

[Bill Cole]

On 13 Dec 2012, at 9:03, Rich Kulawiec wrote:

> I just don't see it yet due to insufficient caffeine intake.

As the ASRG approaches the end of its first decade, we should stipulate
that caffeine is too tame a drug to enable one to comprehend the FUSSP.

[Barry Shein]

On December 13, 2012 at 09:23 ***@billmail.scconsult.com (Bill Cole) wrote:
> On 13 Dec 2012, at 9:03, Rich Kulawiec wrote:
>
> > I just don't see it yet due to insufficient caffeine intake.
>
> As the ASRG approaches the end of its first decade, we should stipulate
> that caffeine is too tame a drug to enable one to comprehend the FUSSP.

We should also reflect on every time someone ever said "won't work
because that solution would take a DECADE to be adopted!"

--
-Barry Shein

The World | ***@TheWorld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada
Software Tool & Die | Public Access Internet | SINCE 1989 *oo*

[Bart Schaefer]

On Dec 13, 9:03am, Rich Kulawiec wrote:
}
} > A number of heuristics include increasing the computation required to
} > send and receive an email, for example one to a few minutes of computation
} > per email on desktop computers.
}
} I don't think you can do this. I think you're trying to drown someone
} who owns the ocean, and that the attempt is futile. But perhaps you have
} an approach that's eluded others, that overcomes the obvious problems,
} and I just don't see it yet due to insufficient caffeine intake.

Generating "cash" with computing resources means they can print all the
money they want. For a pay-to-play scheme to have any hope of working,
it needs to be based on a resource that can be controlled from outside.

Which leads to the same discussion we had four years ago. Today is the
anniversary of http://tools.ietf.org/html/draft-irtf-asrg-postage-00
which never went went anywhere beyond that.

It is acknowledged that the bad guys can steal postage from a zombied
system almost as easily as they can steal compute resources, but it's
easier to discover and react to the theft of something that doesn't
invisibly regenerate.

[John Leslie]

Bart Schaefer <***@brasslantern.com> wrote:
> On Dec 13, 9:03am, Rich Kulawiec wrote:
>} [Adam Sobieski <***@hotmail.com> wrote:]
>}
>}> A number of heuristics include increasing the computation required to
>}> send and receive an email, for example one to a few minutes of computation
>}> per email on desktop computers.
>}
>} I don't think you can do this. I think you're trying to drown someone
>} who owns the ocean, and that the attempt is futile. But perhaps you have
>} an approach that's eluded others, that overcomes the obvious problems,
>} and I just don't see it yet due to insufficient caffeine intake.

It's not sufficient to prove some value was expended: something of value
must be transferred to the receiving SMTP server (if not all the way to
the reader).

> Generating "cash" with computing resources means they can print all the
> money they want. For a pay-to-play scheme to have any hope of working,
> it needs to be based on a resource that can be controlled from outside.

I'm not sure "controlled from outside" can work...

> Which leads to the same discussion we had four years ago. Today is the
> anniversary of http://tools.ietf.org/html/draft-irtf-asrg-postage-00
> which never went went anywhere beyond that.

Indeed it is, Bart! I'll treat you and Ben to a virtual beverage and
four virtual candles. ;^)

> It is acknowledged that the bad guys can steal postage from a zombied
> system almost as easily as they can steal compute resources, but it's
> easier to discover and react to the theft of something that doesn't
> invisibly regenerate.

It's better yet to react to actual value received. ;^)

The snail-mail systems _are_ sender-pays systems, but it's only the
perceived value-received that causes snail-mail recipients to open an
envelope.

(I'm not holding my breath on anything happening with ePostage, but
I remain willing to work with anybody else with the energy to pursue it.)

--
John Leslie <***@jlc.net>

[Barry Shein]

I still think real postage of a form (I mean $$$) could do it but I'm
sick of wearing out keyboards explaining why and seeing others wearing
out their keyboards trying to rationalize why it won't.

But, in a sentence, creating an economy around spam-fighting, an
economic incentive to fight fraud, would help because money focuses
the mind.


--
-Barry Shein

The World | ***@TheWorld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada
Software Tool & Die | Public Access Internet | SINCE 1989 *oo*

[Martijn Grooten]

> But, in a sentence, creating an economy around spam-fighting, an economic
> incentive to fight fraud, would help because money focuses the mind.

I think it's good to keep in mind that we (the anti-spam industry/community) are actually doing rather well at blocking spam. Catch rates are extremely high, false positive rates quite low. There's definitely still room for improvement, particularly among the edges, but if you want to argue for a new way to fight spam, especially one that radically changes the way email works, you will have to explain why it will work even better.

What we're particularly good at, is fighting botnet spam. Global spam levels have decreased in the past four years, largely due to a significant decrease in spam sent via botnets. What is still being sent is relatively easy to block.

Botnet resources, vast as they may be, are ultimately limited and botnets come with a price tag too (literally, on the underground market). And the profit margins on spam, especially botnet spam, are already extremely small. So it may well be that someone will come up with a very clever way of increasing the cost of sending spam via botnets that will make it financially uninteresting for botherders to do so. I seriously wonder how much this would improve things. Of all the things bad guys can do with botnets, sending spam does relatively little harm, and because it involves doing something that home PCs generally aren't supposed to do (namely making outbound connections on TCP port 25), it helps ISPs detect infected customers.

Martijn.


________________________________

Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.

[Adam Sobieski]

Internet Research Task Force,
Anti-Spam Research Group,
Martijn Grooten,
Rich Kulawiec,

Greetings. Earlier in our discussion, the ITU WCIT conference in Dubai was mentioned, and I would like to express my opinion to you that, like many scientists, I oppose regulation of the Internet and of the Web, by either the United States or the United Nations. Some participants at the ITU WCIT conference did broach spam topics and there were concerns about regulatory approaches.

I agree with what Rich Kulawiec said about the value to society of the numerous mailing lists of scientists addressing the spam problems, including the IRTF Anti-Spam Research Group, and I agree with Martijn Grooten's indication that the anti-spam industry / community has been doing well at blocking spam and working to address and to solve any remaining spam problems. Science, not regulation, is where solutions come from.



Kind regards,

Adam Sobieski