actually greylisting works pretty well, and the whitelist of exceptions is relatively small (not more than 300 entries as far as I remember). Also if you communicate the value of it to the customers, they tend to agree that having 90% of spam filtered before entering the system is worth waiting for half an hour for email from a new source.
It's also a matter of resources: if you don't want or cannot enable greylisting, you have to invest more resources into a more sophisticated mail filtering software. Even if it's available for free, still developing and maintaining your solution might become too expensive.
so, basically as we discussed it already last week in regards to Skype: use the right tools for the right task :-)
----- Original Message ----
From: Tonnerre Lombard tonnerre@bsdprojects.net To: swinog@swinog.ch Cc: swinog@lists.swinog.ch; per.jessen@enidan.ch Sent: Friday, October 17, 2008 5:27:10 PM Subject: Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Salut, Per,
On Fri, 17 Oct 2008 12:47:48 +0200, Per Jessen wrote:
Another option is to disable greylisting just for that one mailserver.
This implies that either you know all servers hosting broken scripts (NP-complete I think) or your customers will always communicate problems. Usually they encounter them and rant about it on their Stammtisch and then change provider to someone with one hell of a lot of SPAM.
Tonnerre
...and beside that, is really strange that 90% of the professional spam cleaner (I'm talking about services not appliances) extensively use greylisting.
I'm using greylisting (with some self made scripts to auto learn to withe and blacklist) since 2 1/2 years and I never missed a single mail.
Someone said that "greylisting is a religion". No, it's not. It's just a pretty effective method of keep the spam out. There are lot of tools, scripts and applications to do that but most of them are quite cpu intensive. 98% of the incoming spam is catched by the greylisting engine with almost zero cpu, only the remaining 2% need to be analyzed.
And so fair as I am, I also put a notice in the 450 and 554 error code explaining why it is delayed or rejected. That's not true for notorious spammers which will hangs for hours in my tarpit (and thus saving some other people from being spammed). I know that spammers don't cares about logs but I expect a serious mail-admin does (at least the non M$ admins) and can react on it.
As long as the internet community does not efficiently fight spam at the source I will put my efforts on fighting spam at the destination ! My personal opinion is that no consumer hoster or ISP (xDSL/Docsis) should allow their customers to send SMTP directly (beside some exceptions). Just a matter of keep the mess out of the net. We all know that most of the spam comes from bot pc which are on residential access. I guess that if every ISP would apply a mandatory SMTP-relay we would have at least 70% less spam !
And now I stop before we start another "never ending flame-up" discussion :-)
Stanislav Sinyagin wrote:
actually greylisting works pretty well, and the whitelist of exceptions is relatively small (not more than 300 entries as far as I remember). Also if you communicate the value of it to the customers, they tend to agree that having 90% of spam filtered before entering the system is worth waiting for half an hour for email from a new source.
It's also a matter of resources: if you don't want or cannot enable greylisting, you have to invest more resources into a more sophisticated mail filtering software. Even if it's available for free, still developing and maintaining your solution might become too expensive.
so, basically as we discussed it already last week in regards to Skype: use the right tools for the right task :-)
----- Original Message ----
From: Tonnerre Lombard tonnerre@bsdprojects.net To: swinog@swinog.ch Cc: swinog@lists.swinog.ch; per.jessen@enidan.ch Sent: Friday, October 17, 2008 5:27:10 PM Subject: Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Salut, Per,
On Fri, 17 Oct 2008 12:47:48 +0200, Per Jessen wrote:
Another option is to disable greylisting just for that one mailserver.
This implies that either you know all servers hosting broken scripts (NP-complete I think) or your customers will always communicate problems. Usually they encounter them and rant about it on their Stammtisch and then change provider to someone with one hell of a lot of SPAM.
Tonnerre
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Salut, Stanislav,
On Fri, 17 Oct 2008 08:42:49 -0700 (PDT), Stanislav Sinyagin wrote:
actually greylisting works pretty well, and the whitelist of exceptions is relatively small (not more than 300 entries as far as I remember). Also if you communicate the value of it to the customers, they tend to agree that having 90% of spam filtered before entering the system is worth waiting for half an hour for email from a new source.
They don't care as long as they receive all mails they want to.
It's also a matter of resources: if you don't want or cannot enable greylisting, you have to invest more resources into a more sophisticated mail filtering software. Even if it's available for free, still developing and maintaining your solution might become too expensive.
I've found a different method to be at least equally time-saving: rejecting SPAM rather than accepting and deleting it. The basic dialog looks about like this:
Out: 220 planck.ngas.ch ESMTP Postfix (2.5.1) In: HELO gurgel.org Out: 250 planck.ngas.ch In: MAIL FROM: blubber@gurgel.org Out: 250 2.1.0 Ok In: RCPT TO: kreisch@ngas.ch Out: 250 2.1.0 Ok In: DATA Out: 354 End data with <CR><LF>.<CR><LF> In: [...] In: . Out: 550 Keep your SPAM to yourself.
The scheme doesn't look as great as it works. The end result is that the spammer learns that the address is not reachable (because permanent errors are usually received for non-existent addresses) and won't retry as frequently as for others.
This keeps the level of incoming SPAM really low. In addition, it has the great advantage that if a sender really happens to fall into the false positive trap, he will discover it immediately by receiving a mail from his own mail server saying that the mail could not be delivered, rather than to notice after days that the other end has deleted or never read the mail.
Greetings from inside the Grenchenbergtunnel,
Tonnerre
Stanislav Sinyagin wrote:
actually greylisting works pretty well, and the whitelist of exceptions is relatively small (not more than 300 entries as far as I remember). Also if you communicate the value of it to the customers, they tend to agree that having 90% of spam filtered before entering the system is worth waiting for half an hour for email from a new source.
It's also a matter of resources: if you don't want or cannot enable greylisting, you have to invest more resources into a more sophisticated mail filtering software. Even if it's available for free, still developing and maintaining your solution might become too expensive.
agreed. maintenance for spamassassin or equal tools is much more time intensive than setting up and controlling greylisting. though my experience was that it's not necessary to use a long greylisting time, 5 minutes are usually more than enough to filter out 95% of bad mailers and usually queue times are 5,10 or 30mins for the first retry so users don't have to wait more then 5-30 mins at average.
the resource question isn't just about the software, using content filter tools e.g. spamassassin consumes a lot of CPU and memory and if you don't have proper hardware it might also result in delays or other problems...
so, basically as we discussed it already last week in regards to Skype: use the right tools for the right task :-)
----- Original Message ----
From: Tonnerre Lombard tonnerre@bsdprojects.net To: swinog@swinog.ch Cc: swinog@lists.swinog.ch; per.jessen@enidan.ch Sent: Friday, October 17, 2008 5:27:10 PM Subject: Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Salut, Per,
On Fri, 17 Oct 2008 12:47:48 +0200, Per Jessen wrote:
Another option is to disable greylisting just for that one mailserver.
This implies that either you know all servers hosting broken scripts (NP-complete I think) or your customers will always communicate problems. Usually they encounter them and rant about it on their Stammtisch and then change provider to someone with one hell of a lot of SPAM.
Tonnerre
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
-
Daniele Guazzoni -
Marco Fretz -
Stanislav Sinyagin -
Tonnerre Lombard