spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Mittelstaedt <>
Subject Re: Change .spamassassin directory
Date Thu, 22 Jul 2010 20:48:50 GMT

On 7/22/2010 1:13 PM, Karsten Br├Ąckelmann wrote:
> On Thu, 2010-07-22 at 12:55 -0700, Ted Mittelstaedt wrote:
>> On 7/22/2010 12:32 PM, Karsten Br├Ąckelmann wrote:
>> The biggest downside IMHO is that you lose functionality on the RBL
>> For example at 9am spammer spews.  At 9:15 spammer is listed in RBL.  At
>> 10:0m spammer mails you and your ISP picks up the mail because they
>> aren't using RBLs.  At 11:00 am the spammer's admin shuts the spammer
>> down and delists the IP from the RBL.  At 2:00pm you come along and
>> fetch your mail, and scan all the headers, checking all the IPs in
>> RBLs and the spam's IPs are not in the RBL then, even though they were
>> earlier.
> 4 hours between 10 am and 2 pm.
> Ted, you just described *client* side filtering, running when the user
> starts his MUA. Exactly what I advocated against, and instead
> recommended...
> Server side filtering. Even though SA runs (in the scenario I outlined)
> after some client, fetchmail, I still described server side filtering.
> Automatically, as soon as the mail reaches the server. No MUA required.
> Impossible to have a delay as you described, if set up properly.

Yes, I know - however lots of things can go wrong in such a setup and
the server can end up not pulling mail off the ISP's mailserver for
hours at a time.  Power loss, DSL or cable line goes down, whatever.
With a true "server" that is accepting inbound SMTP and not fetching it,
if there's a problem then the sender requeues and tries again.

> Yes, I do maintain some home systems like that. With freemailers or ISP
> accounts it often isn't possible any other way. Polling interval of a
> minute or two.

And if everyone polled every minute or 2 then the server would melt 
down.  You should be polling every 5 or better yet every 10.  But in
any case why are you advocating a hack like this?  Your last post 
advocated NOT a hack but in doing it right.  In every instance of a
fetchmail setup the biggest loss is that you cannot issue an error
5xx to a spammer.

In my SOHO mailserver setups the RBL's are always run by the MTA first 
before SA even sees the mail.  I also greylist.  And so the spammer
cannot even pass the mail at all if he's in the RBL.  SA RBL checks
still have value since they can scan the entire header whereas the
MTA only cares about the sending IP.  It's only the large shared 
customer mailservers that I don't do that and that's just because 
there's always some bozo who insists on getting mail from some 
corespondent on an RBLed server, even though it's blacklisted. But
I still greylist on everything.

> The truth to your outlined timing scenario?  The exact opposite!

until the cat eats the ethernet cable, etc.


> With polling that frequently, I *do* find spam ever other day, that
> *would* have hit various URI DNSBLs, if only the delay would have been 5
> minutes. Go figure.

View raw message