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>
|
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), (continued)
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), Jonathan Morton
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), Jonathan Morton
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), Brad Knowles
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), Jonathan Morton
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), Brad Knowles
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), Jonathan Morton
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), Jonathan Morton
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), Brad Knowles
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), Eric S. Johansson
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), Brad Knowles
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks),
Eric S. Johansson <=
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), Jonathan Morton
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), Brad Knowles
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), Yakov Shafranovich
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), Jonathan Morton
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), Eric S. Johansson
- Re: [Asrg] 6. When To Reject, david nicol
- Re: [Asrg] 6. When To Reject, Brad Knowles
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), Eric S. Johansson
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), Jonathan Morton
- Re: [Asrg] 6. Email Path Verification (hashcash benchmarks), Eric S. Johansson
|
|
|