Re: [Asrg] 6. Email Path Verification (hashcash benchmarks)

["Eric S. Johansson" <esj@harvee.org>]

Brad Knowles explained:

> At 12:07 PM -0400 2003/09/14, Eric S. Johansson wrote:
>
> >  camram puts all of its efforts into the interpretation where because
> >  that's where you need to make the decisions about spam.
>
>     If you are looking at the content, there is no other way you can do 
> that.  However, my view is that this decision needs to be made while the 
> sender is still connected, so that you can decide what kind of SMTP 
> Reply code to generate.
>
>     If you look at the message and decide what to do with it 
> after-the-fact, then you've already lost.  If nothing else, you open 
> yourself to being used to DoS someone in a joe-job.
my belief, based on all the efforts I have seen is that identifying a spammer at 
the server is extremely difficult.  By the time they are shipping you data, they 
have already one according to your definition.  I've heard from a few folks I 
trust that one of the tricks they do is show the message in during the data 
phase, send the . and close the connection.  If it won't close, they just drop 
it.  The only ability to deal with spam at the connection level IMO is to take 
feedback from your clients and then associate that feedback within IP address as 
a spam source.  Then you can pull all sorts of tricks such as connection 
stalling tuning SMTP responses etc. for future connections but that's a 
potentially dangerous feedback loop especially if the triggers are controlled by 
folks not necessarily trained in dealing with spam.

With the camram model, yes, you are looking at messages after the fact.  But, if 
it's a strictly postage and white list environment, that message isn't going 
anywhere near the users inbox.  It's going in spamtrap.  Even with the addition 
of a well tuned discriminator, the risk or possibility of dangerous unstamped 
e-mail coming into the users inbox is low.

During one of the latest e-mail viruses, one of my clients started labeling all 
of the reproductive messages as spam.  Within a few training sessions, the virus 
problem went away because it was all placed in the dumpster.  Personally, I 
never would have thought of doing that but I have a clever client.

so far, it looks to me like filtering at the end node especially on a postage 
base system is very easy, low-cost, and high payoff

> >  PS, I've been living with stamp generation for the past four months
> >  on a Pentium II/333 in foreground mode and it doesn't suck too bad
> >  although it would be better in the background.  Check the headers.
>
>     Lots of things work acceptable well in small-scale use, but fail 
> completely when you try to scale them up.
that's true but remember, camram is supposed to "fail" at the high end.  That's 
how it causes pain to spammers.  Only works in server mode because of the 
"friends fly free" principle.  If you generated a stamp for every single 
message, camram would "fail" by restricting the number of messages that could be 
sent in a given time period.  From a traffic standpoint, a legitimate 
high-volume mail server behaves exactly the same as a spammer mail server.  This 
is why I want to push stamp generation is close to the edge as possible.

In the small at each e-mail client generating stamps should be low pain and, for 
all practical purposes, invisible.  I must say, this is one of things that makes 
me the most excited about camram.

You don't need to be a network genius to make it work.

in fact, you don't really need to learn anything new except how-to manipulate 
the spamtrap (10 minutes if you are dim) and how/when to set configuration 
parameters.  Right now, any average administrator can operate and cleanup camram 
spamtrap in 10 to 15 minutes per day if you operate in global mode (i.e. 
everyone on the server).  If you operate in individual user mode, you're still 
looking at 2-3 minutes a day tops.  In fact I frequently ignore the spamtrap for 
two or three days at a time without any pain.  That is good human factors and is 
something we should all be striving for in our solutions.  if we create a 
solution that is the jobs program for IT, we have come up with the wrong 
solution.  It will put the burden of cost on the user and not the spammer where 
it belongs.

anyway, that's my Sunday night rant.  Make the it simple, drive the cost of 
installation and daily operation through the floor and that solution will be a 
good one.

---eric



_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg