On Tue, 19 Feb 2002, Arpi wrote:

> > 3. Allow for far greater loads than will fit on a single mail processing
> > machine (regardless of how many CPUs you cram in your starfire box) by
> > enabling the processing load to be spread around a network.  The network
> ok, you're right here, i must agree. i didn't think of multiple machines...

That's potentially a very big issue for big sites.

> > I/O overhead is not all that significant, and if you're running
> > spamc/spamd on the same machine, communicating over the local loopback
> > TCP interface, your OS is responsible for making sure that's done
> > efficiently.  If it's much slower than using a shell pipe, you need a
> > new OS.
> :)

Not quite - spamc is a local pipe + a TCP stream. spamassassin or a new
local-only C version would just be a local pipe.

>From what I can see, spamc gets messages over the network -fast-, so no, I
don't think that extra redirection is a problem.

> > > I don't even plan to implement 100% compatible alternative, i'll probably
> > > leave some checks out. At least now i won't implement all that eval's in C
> > > and will leave all network tests (they can be done by the MTA if needed).
> >
> > Well, they can't really be done by the MTA in most cases, unless you
> > have a really fancy MTA.  The network checks are not done in most cases
> > against the envelope contents (which is what MTAs normally check), but
> could you explain tis in more detail? 9or point me to the RTFM, i couldn't
> find the doc/ dir mentioned in README)

Most MTA's only check against the connecting host, and the options are to
allow or reject the mail.

SpamAssassin looks at the Received headers, checking more than the
connecting host, but also every machine it was passed through. It also
allows scoring against it, rather than outright blocking.

As an ISP, I don't feel like I can use the blacklists for outright
blocking. Not that I wouldn't use them on a personal system ...

> > against the email header information.  Also, they do things like razor
> > checking, etc. which MTAs don't normally do.  I'm not saying any of this
> but procmail can...
> (assuming there is a razor client somewhere)

No, it can't. The procmail interfaces to DNS Blacklists are all call-out
programs ... it is possible to parse out the received headers and pass
those to a dns looker-upper, though. But then you lose the ability to have
one "score" that you are working towards. I think it makes more sense to
keep DNS tests in spamassassin.

> > is critical, and I run spamd -L anyway.

Have you tried using just bl.spamcop.net? I use that and
blacklist.spambag.org. You can secondary blacklist.spambag.org for better
speed, too. I find the spamcop list to be the best one around, by far.

I'm not really sure how useful the MX tests are. I'm captivated by them,
but I don't see much getting hit by them ...

And I'm actually playing with Razor again. It isn't nearly as broken as it
was for a while. But I've got some spare CPU cycles to throw at Razor
right now. Razor probably wouldn't be worth re-implementing in a C
re-write, but the Rhyolite.com DCC system might be.

> me too. anyway, i have another idea, "developed" some time ago for virus
> checking. the main point is checking mails for databases
> (razor/virusscanner) at time of _downlaoding_ mail (pop3), instead of
> when it arrives. (when it arrives (especially true for viruses) it's
> mostly unknown by databases, but few hours/days later when teh user
> downloads it it's already listed in the database and can be cought.
> anyway it has many limitations at pop3 side, and needs special pop3
> daemon (which at first time of mail checking checks and move new mails
> to a new folder where the user can download from).

This would be pretty easy. Don't change your pop3 daemon, just write a
wrapper/proxy for it.

At first glance I think IMAP would be a bit harder.

Would probably help for Razor tests, too.

-- 
Charlie Watts
[EMAIL PROTECTED]
Frontier Internet, Inc.
http://www.frontier.net/


_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk

Reply via email to