ietf-asrg
[Top] [All Lists]

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

2003-09-14 16:01:27
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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>