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.
Ted
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.
