[Dovecot] what best for anti-spam filter?
what anti-spam for you used ? dspam?spammassian? amavisd-new ? what is best ?
On Tue, 2012-07-24 at 11:58 +0800, fy wrote:
what anti-spam for you used ? dspam?spammassian? amavisd-new ? what is best ?
amavisd-new with spamassassin and anti virus scanner, clamav with sanesecurity rules use enforcing rules in mail server, like block hosts with no DNS/rDNS Enforce SPF, publish SPF with hardfail use DNSBL's in your mail server, spamhaus, spamcop, spam.sorbs, and more etc. milter regex to stop dynamic/suspect hosts
There is no one solution, the solution, is a box of many tricks You might get the odd false blocking, but if system opers can not be bothered running a compliant network with standardised naming conventions for servers, then it is not my problem, and we have had very very very few complaints about this type of policy in over a decade. If someoine sooks to you, educate them, dont whitelist them.
On 07/24/2012 06:49 AM, Noel Butler wrote:
On Tue, 2012-07-24 at 11:58 +0800, fy wrote:
what anti-spam for you used ? dspam?spammassian? amavisd-new ? what is best ?
amavisd-new with spamassassin and anti virus scanner, clamav with sanesecurity rules use enforcing rules in mail server, like block hosts with no DNS/rDNS Enforce SPF, publish SPF with hardfail use DNSBL's in your mail server, spamhaus, spamcop, spam.sorbs, and more etc. milter regex to stop dynamic/suspect hosts
And first of all, even if this is not dovecot related, use a greylisting solution.
There is no one solution, the solution, is a box of many tricks You might get the odd false blocking, but if system opers can not be bothered running a compliant network with standardised naming conventions for servers, then it is not my problem, and we have had very very very few complaints about this type of policy in over a decade. If someoine sooks to you, educate them, dont whitelist them.
Indeed! Fighting spam is a continuous task. While greylisting will cut down the amount of spam by more than 50%, the remaining 50% will give you the hardest time and will keep changing to bypass your rules. You'll need to keep an eye on the flow of false negatives or false positive you are getting...
We (72,000 mailboxes) are currently using amavisd-new with spamassassin and CRM114 via a custom plugin instead of the default bayesian filter. Also like Noel, we're using DNSBLs, SPF (although we had to publish a permissive record since some of our users are using their ISP smtp instead of our own).
Arnaud
-- Arnaud Abélard (jabber: arnaud.abelard@univ-nantes.fr) Administrateur Système - Responsable Services Web Direction des Systèmes d'Informations Université de Nantes
ne pas utiliser: trapemail@univ-nantes.fr
于 2012/7/24 15:16, Arnaud Abélard 写道:
On 07/24/2012 06:49 AM, Noel Butler wrote:
On Tue, 2012-07-24 at 11:58 +0800, fy wrote:
what anti-spam for you used ? dspam?spammassian? amavisd-new ? what is best ?
amavisd-new with spamassassin and anti virus scanner, clamav with sanesecurity rules use enforcing rules in mail server, like block hosts with no DNS/rDNS Enforce SPF, publish SPF with hardfail use DNSBL's in your mail server, spamhaus, spamcop, spam.sorbs, and more etc. milter regex to stop dynamic/suspect hosts
And first of all, even if this is not dovecot related, use a greylisting solution.
There is no one solution, the solution, is a box of many tricks You might get the odd false blocking, but if system opers can not be bothered running a compliant network with standardised naming conventions for servers, then it is not my problem, and we have had very very very few complaints about this type of policy in over a decade. If someoine sooks to you, educate them, dont whitelist them.
Indeed! Fighting spam is a continuous task. While greylisting will cut down the amount of spam by more than 50%, the remaining 50% will give you the hardest time and will keep changing to bypass your rules. You'll need to keep an eye on the flow of false negatives or false positive you are getting...
We (72,000 mailboxes) are currently using amavisd-new with spamassassin and CRM114 via a custom plugin instead of the default bayesian filter. Also like Noel, we're using DNSBLs, SPF (although we had to publish a permissive record since some of our users are using their ISP smtp instead of our own).
Arnaud
try slockd ,it is a policy server for postfix http://www.extmail.org/download
Am 24.07.2012 10:22, schrieb fy:
于 2012/7/24 15:16, Arnaud Abélard 写道:
On 07/24/2012 06:49 AM, Noel Butler wrote:
On Tue, 2012-07-24 at 11:58 +0800, fy wrote:
what anti-spam for you used ? dspam?spammassian? amavisd-new ? what is best ?
amavisd-new with spamassassin and anti virus scanner, clamav with sanesecurity rules use enforcing rules in mail server, like block hosts with no DNS/rDNS Enforce SPF, publish SPF with hardfail use DNSBL's in your mail server, spamhaus, spamcop, spam.sorbs, and more etc. milter regex to stop dynamic/suspect hosts
And first of all, even if this is not dovecot related, use a greylisting solution.
There is no one solution, the solution, is a box of many tricks You might get the odd false blocking, but if system opers can not be bothered running a compliant network with standardised naming conventions for servers, then it is not my problem, and we have had very very very few complaints about this type of policy in over a decade. If someoine sooks to you, educate them, dont whitelist them.
Indeed! Fighting spam is a continuous task. While greylisting will cut down the amount of spam by more than 50%, the remaining 50% will give you the hardest time and will keep changing to bypass your rules. You'll need to keep an eye on the flow of false negatives or false positive you are getting...
We (72,000 mailboxes) are currently using amavisd-new with spamassassin and CRM114 via a custom plugin instead of the default bayesian filter. Also like Noel, we're using DNSBLs, SPF (although we had to publish a permissive record since some of our users are using their ISP smtp instead of our own).
Arnaud
try slockd ,it is a policy server for postfix http://www.extmail.org/download
sadly there is only poor english info
-- Best Regards MfG Robert Schetterer
于 2012/7/24 16:29, Robert Schetterer 写道:
Am 24.07.2012 10:22, schrieb fy:
于 2012/7/24 15:16, Arnaud Abélard 写道:
On 07/24/2012 06:49 AM, Noel Butler wrote:
On Tue, 2012-07-24 at 11:58 +0800, fy wrote:
what anti-spam for you used ? dspam?spammassian? amavisd-new ? what is best ?
amavisd-new with spamassassin and anti virus scanner, clamav with sanesecurity rules use enforcing rules in mail server, like block hosts with no DNS/rDNS Enforce SPF, publish SPF with hardfail use DNSBL's in your mail server, spamhaus, spamcop, spam.sorbs, and more etc. milter regex to stop dynamic/suspect hosts And first of all, even if this is not dovecot related, use a greylisting solution.
There is no one solution, the solution, is a box of many tricks You might get the odd false blocking, but if system opers can not be bothered running a compliant network with standardised naming conventions for servers, then it is not my problem, and we have had very very very few complaints about this type of policy in over a decade. If someoine sooks to you, educate them, dont whitelist them. Indeed! Fighting spam is a continuous task. While greylisting will cut down the amount of spam by more than 50%, the remaining 50% will give you the hardest time and will keep changing to bypass your rules. You'll need to keep an eye on the flow of false negatives or false positive you are getting...
We (72,000 mailboxes) are currently using amavisd-new with spamassassin and CRM114 via a custom plugin instead of the default bayesian filter. Also like Noel, we're using DNSBLs, SPF (although we had to publish a permissive record since some of our users are using their ISP smtp instead of our own).
Arnaud
try slockd ,it is a policy server for postfix http://www.extmail.org/download sadly there is only poor english info
Download the file for slockd and unzie it . see INSTALL and README files .it's easy use and install .
Am 24.07.2012 10:41, schrieb fy:
于 2012/7/24 16:29, Robert Schetterer 写道:
Am 24.07.2012 10:22, schrieb fy:
于 2012/7/24 15:16, Arnaud Abélard 写道:
On 07/24/2012 06:49 AM, Noel Butler wrote:
On Tue, 2012-07-24 at 11:58 +0800, fy wrote:
what anti-spam for you used ? dspam?spammassian? amavisd-new ? what is best ?
amavisd-new with spamassassin and anti virus scanner, clamav with sanesecurity rules use enforcing rules in mail server, like block hosts with no DNS/rDNS Enforce SPF, publish SPF with hardfail use DNSBL's in your mail server, spamhaus, spamcop, spam.sorbs, and more etc. milter regex to stop dynamic/suspect hosts And first of all, even if this is not dovecot related, use a greylisting solution.
There is no one solution, the solution, is a box of many tricks You might get the odd false blocking, but if system opers can not be bothered running a compliant network with standardised naming conventions for servers, then it is not my problem, and we have had very very very few complaints about this type of policy in over a decade. If someoine sooks to you, educate them, dont whitelist them. Indeed! Fighting spam is a continuous task. While greylisting will cut down the amount of spam by more than 50%, the remaining 50% will give you the hardest time and will keep changing to bypass your rules. You'll need to keep an eye on the flow of false negatives or false positive you are getting...
We (72,000 mailboxes) are currently using amavisd-new with spamassassin and CRM114 via a custom plugin instead of the default bayesian filter. Also like Noel, we're using DNSBLs, SPF (although we had to publish a permissive record since some of our users are using their ISP smtp instead of our own).
Arnaud
try slockd ,it is a policy server for postfix http://www.extmail.org/download sadly there is only poor english info
Download the file for slockd and unzie it . see INSTALL and README files .it's easy use and install .
done , nice tool
-- Best Regards MfG Robert Schetterer
On 7/24/2012 2:16 AM, Arnaud Abélard wrote:
And first of all, even if this is not dovecot related, use a greylisting solution.
Greylisting only stops bots. It is resource intensive, and causes delivery delays. There exist bot spam killing solutions that are just as effective, with less downside. Two are Postfix' postscreen daemon, and fqrdns.pcre, which rejects based on consumer/dynamic looking rDNS. Some users have modified the latter for use on HELO strings instead of client rDNS strings, with good success. Either combined with CBL/ZEN should kill all your bot spam much more efficiently. I'm surprised you're using greylisting (Postgrey?) with 72k mailboxes.
Indeed! Fighting spam is a continuous task.
Unfortunately...
We (72,000 mailboxes) are currently using amavisd-new with spamassassin and CRM114 via a custom plugin instead of the default bayesian filter. Also like Noel, we're using DNSBLs, SPF (although we had to publish a permissive record since some of our users are using their ISP smtp instead of our own).
Which of your countermeasures blocks spam from Orange/France Telecom VPS/colo sources?
-- Stan
On Tue, Jul 24, 2012 at 03:38:00AM -0500, Stan Hoeppner wrote:
Greylisting only stops bots. It is resource intensive, and causes delivery delays. There exist bot spam killing solutions that are just as effective, with less downside. Two are Postfix' postscreen daemon, and fqrdns.pcre, which rejects based on consumer/dynamic looking rDNS.
I use that in order to decide the greylisting delay: suspect IP get a 12 hours greylist, everyone else gets 15 mn, or 0 if whitelisted by recipeients. It works quite well.
-- Emmanuel Dreyfus manu@netbsd.org
On Tue, Jul 24, 2012 at 03:38:00AM -0500, Stan Hoeppner wrote:
Greylisting only stops bots. It is resource intensive, and causes delivery delays. There exist bot spam killing solutions that are just as effective, with less downside. Two are Postfix' postscreen daemon, and fqrdns.pcre, which rejects based on consumer/dynamic looking rDNS. I use that in order to decide the greylisting delay: suspect IP get a 12 hours greylist, everyone else gets 15 mn, or 0 if whitelisted by recipeients. It works quite well. Have you considered using some dnswl (whitelist) to turn off greylisting for some hosts? e.g. dnswl.org. Greylisting for dnswl.org "none" level (the lowest
On 07/24/2012 11:45 AM, Emmanuel Dreyfus wrote: trust) makes (some) sense only if you use bulk detectors like razor/pyzor/DCC.
On Tue, Jul 24, 2012 at 12:03:55PM +0200, Andrzej A. Filip wrote:
Have you considered using some dnswl (whitelist) to turn off greylisting for some hosts?
I do not do it, but it is trivial to configure milter-greylist for that usage: just add a whitelist acl based on a DNSRBL lookup.
-- Emmanuel Dreyfus manu@netbsd.org
On 07/24/2012 10:38 AM, Stan Hoeppner wrote:
On 7/24/2012 2:16 AM, Arnaud Abélard wrote:
And first of all, even if this is not dovecot related, use a greylisting solution.
Greylisting only stops bots. It is resource intensive, and causes delivery delays. There exist bot spam killing solutions that are just as effective, with less downside. Two are Postfix' postscreen daemon, and fqrdns.pcre, which rejects based on consumer/dynamic looking rDNS. Some users have modified the latter for use on HELO strings instead of client rDNS strings, with good success. Either combined with CBL/ZEN should kill all your bot spam much more efficiently. I'm surprised you're using greylisting (Postgrey?) with 72k mailboxes.
Greylisting only stops bots. Exactly. That's the whole point! We have been using sqlgrey for now 5 years and we only had one problem last month with OVH smtp infrastructure which sucks and we're happy to see mails bouncing from them, hoping their customers will complain.
But I can understand why you would think greylist is trouble. It depends on how you set it up. One mail delayed per domain and per month is really nothing compared to hundred thousands of bot spams we are rejecting.
dynamic/consumer ip range DNSBL are dangerous since they are rarely up to date, I can painfully remember that.
I guess it all depends on what kind of smtp traffic you get. As a large university we aren't getting the same traffic as a big corporate company which will mostly communicate with other business. We are getting tons of individual mails from local ISPs, lot of geeks hosting their servers at home (a lot of ppl do that here...), etc.
Indeed! Fighting spam is a continuous task.
Unfortunately...
We (72,000 mailboxes) are currently using amavisd-new with spamassassin and CRM114 via a custom plugin instead of the default bayesian filter. Also like Noel, we're using DNSBLs, SPF (although we had to publish a permissive record since some of our users are using their ISP smtp instead of our own).
Which of your countermeasures blocks spam from Orange/France Telecom VPS/colo sources?
Ahah.. that's a good question! since we are a french university we are also getting tons of clean mails from Orange/FT. But the problem isn't as bad as it used to be since Orange is now blocking direct outgoing traffic on port 25 for a few years now. Back then the DNSRBL were a good solution for spams coming from them. Now the new pain in the ass is OVH, the largest european hosting company which also has the worst smtp infrastructure that will not play well with greylist (tons of smtp servers, each on a different ip range so you can't even whitelist them by their networks).
Arnaud
-- Arnaud Abélard (jabber: arnaud.abelard@univ-nantes.fr) Administrateur Système - Responsable Services Web Direction des Systèmes d'Informations Université de Nantes
ne pas utiliser: trapemail@univ-nantes.fr
On 24.07.2012 09:16, Arnaud Abélard wrote:
And first of all, even if this is not dovecot related, use a greylisting solution.
No, greylisting is really a bad solution. It is not RFC compliant and delays the mail traffic.
I would prefer a pre-queue content-filtering solution like MIMEDefang or amavisd-new.
Best regards,
Morten
-------- Original-Nachricht --------
Datum: Tue, 24 Jul 2012 10:49:48 +0200 Von: Morten Stevens mstevens@imt-systems.com An: Dovecot Mailing List dovecot@dovecot.org Betreff: Re: [Dovecot] what best for anti-spam filter?
On 24.07.2012 09:16, Arnaud Abélard wrote:
And first of all, even if this is not dovecot related, use a greylisting solution.
No, greylisting is really a bad solution. It is not RFC compliant and delays the mail traffic.
In what sense is greylisting not RFC compliant?
I would prefer a pre-queue content-filtering solution like MIMEDefang or amavisd-new.
Best regards,
Morten
On Tue, Jul 24, 2012 at 10:49 AM, Morten Stevens mstevens@imt-systems.com wrote:
No, greylisting is really a bad solution. It is not RFC compliant and delays the mail traffic.
Since when? RFC5321 was updated to handle delays and then there is RFC6647.
-- .warren
On Tue, 2012-07-24 at 11:12 +0200, Warren Baker wrote:
On Tue, Jul 24, 2012 at 10:49 AM, Morten Stevens mstevens@imt-systems.com wrote:
No, greylisting is really a bad solution. It is not RFC compliant and delays the mail traffic.
Since when? RFC5321 was updated to handle delays and then there is RFC6647.
When we looked at it years ago, it did little to stem the tide of spam, all it did was over give us a negative impact by delays of legit mail, some servers are also poorly configured and dont try resend for a long period of time, especially if their queue is also loaded up, then there's non compliant twits like a certain freemail service that does not retry, period. Too many downfalls, it lasted all of a few days when we tried it out. It might be acceptable for small SOHO, but it is unacceptable for ISP's and hosting companies who process millions of mails a day.
On 24.07.2012 12:33, Noel Butler wrote:
When we looked at it years ago, it did little to stem the tide of spam, all it did was over give us a negative impact by delays of legit mail, some servers are also poorly configured and dont try resend for a long period of time, especially if their queue is also loaded up, then there's non compliant twits like a certain freemail service that does not retry, period. Too many downfalls, it lasted all of a few days when we tried it out. It might be acceptable for small SOHO, but it is unacceptable for ISP's and hosting companies who process millions of mails a day.
Excellent post, Noel. That's what I mean.
Best regards,
Morten
24.07.2012 10:49, Morten Stevens:
No, greylisting is really a bad solution. It is not RFC compliant and delays the mail traffic.
No. Rejecting mail with an temporary error is perfectly RFC compliant. It happens all the time without greylisting. Because the authors of the SMTP RFC knew that there are many different possible reasons why a mail server might temporarily be unable to receive mail, they added the 4yz responses to it.
With greylisting done right, only a very small part of (wanted) incoming mail is delayed. And for the rest: e-mail isn't guaranteed to be a real-time communication channel.
-- Regards mks
On Tue, Jul 24, 2012 at 10:49:48AM +0200, Morten Stevens wrote:
No, greylisting is really a bad solution. It is not RFC compliant
Of course it is. Have you readen RFC 6647?
and delays the mail traffic.
Greylisting with whitelist and reputation-based greylisting delay makes it painless.
-- Emmanuel Dreyfus manu@netbsd.org
On 24.07.2012 11:50, Emmanuel Dreyfus wrote:
On Tue, Jul 24, 2012 at 10:49:48AM +0200, Morten Stevens wrote:
No, greylisting is really a bad solution. It is not RFC compliant
Of course it is. Have you readen RFC 6647?
Okay, you're right.
Here is it from June 2012: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06288.html
So it is now RFC compliant. Anyway I think delaying mail traffic is not a good solution.
Best regards,
Morten
Morten Stevens mstevens@imt-systems.com wrote:
So it is now RFC compliant. Anyway I think delaying mail traffic is not a good solution.
This is why whitelists and autowhilists are used in greylist filters.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@netbsd.org
On 24.07.2012 13:44, manu@netbsd.org wrote:
Morten Stevens mstevens@imt-systems.com wrote:
So it is now RFC compliant. Anyway I think delaying mail traffic is not a good solution.
This is why whitelists and autowhilists are used in greylist filters.
Okay, and where are your whitelists at netbsd.org?
I've sent an email to you, which is delayed until now. Note: Our servers are listed at dnswl.org with medium score.
Jul 24 12:27:32 mx1 sendmail[31933]: q6OARUOM031928: to=dovecot@dovecot.org, delay=00:00:02, xdelay=00:00:01, mailer=esmtp, pri=152317, relay=dovecot.org. [193.210.130.67], dsn=2.0.0, stat=Sent (Ok: queued as 35AF81AE8359) Jul 24 12:28:32 mx1 sendmail[31933]: q6OARUOM031928: to=manu@netbsd.org, delay=00:01:02, xdelay=00:01:00, mailer=esmtp, pri=152317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.0.0, stat=Deferred: Connection timed out with mail.netbsd.org. Jul 24 12:42:57 mx1 sendmail[32292]: q6OARUOM031928: to=manu@netbsd.org, delay=00:15:27, xdelay=00:01:00, mailer=esmtp, pri=242317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.0.0, stat=Deferred: Connection timed out with mail.netbsd.org. Jul 24 12:50:53 mx1 sendmail[32518]: q6OARUOM031928: to=manu@netbsd.org, delay=00:23:23, xdelay=00:00:02, mailer=esmtp, pri=332317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.7.1, stat=Deferred: 450 4.7.1 manu@netbsd.org: Recipient address rejected: Greylisting in action, please try later Jul 24 12:58:41 mx1 sendmail[312]: q6OARUOM031928: to=manu@netbsd.org, delay=00:31:11, xdelay=00:00:02, mailer=esmtp, pri=422317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.7.1, stat=Deferred: 450 4.7.1 manu@netbsd.org: Recipient address rejected: Greylisting in action, please try later Jul 24 13:42:21 mx1 sendmail[1461]: q6OARUOM031928: to=manu@netbsd.org, delay=01:14:51, xdelay=00:00:01, mailer=esmtp, pri=512317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.7.1, stat=Deferred: 450 4.7.1 manu@netbsd.org: Recipient address rejected: Greylisting in action, please try later Jul 24 13:50:53 mx1 sendmail[1672]: q6OARUOM031928: to=manu@netbsd.org, delay=01:23:23, xdelay=00:00:02, mailer=esmtp, pri=602317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.7.1, stat=Deferred: 450 4.7.1 manu@netbsd.org: Recipient address rejected: Greylisting in action, please try later
This is exactly the reason why greylisting is bad.
Best regards,
Morten
On 7/24/2012 7:13 AM, Morten Stevens wrote:
Jul 24 12:27:32 mx1 sendmail[31933]: q6OARUOM031928: to=dovecot@dovecot.org, delay=00:00:02, xdelay=00:00:01, mailer=esmtp, pri=152317, relay=dovecot.org. [193.210.130.67], dsn=2.0.0, stat=Sent (Ok: queued as 35AF81AE8359) Jul 24 12:28:32 mx1 sendmail[31933]: q6OARUOM031928: to=manu@netbsd.org, delay=00:01:02, xdelay=00:01:00, mailer=esmtp, pri=152317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.0.0, stat=Deferred: Connection timed out with mail.netbsd.org. Jul 24 12:42:57 mx1 sendmail[32292]: q6OARUOM031928: to=manu@netbsd.org, delay=00:15:27, xdelay=00:01:00, mailer=esmtp, pri=242317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.0.0, stat=Deferred: Connection timed out with mail.netbsd.org. Jul 24 12:50:53 mx1 sendmail[32518]: q6OARUOM031928: to=manu@netbsd.org, delay=00:23:23, xdelay=00:00:02, mailer=esmtp, pri=332317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.7.1, stat=Deferred: 450 4.7.1 manu@netbsd.org: Recipient address rejected: Greylisting in action, please try later Jul 24 12:58:41 mx1 sendmail[312]: q6OARUOM031928: to=manu@netbsd.org, delay=00:31:11, xdelay=00:00:02, mailer=esmtp, pri=422317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.7.1, stat=Deferred: 450 4.7.1 manu@netbsd.org: Recipient address rejected: Greylisting in action, please try later Jul 24 13:42:21 mx1 sendmail[1461]: q6OARUOM031928: to=manu@netbsd.org, delay=01:14:51, xdelay=00:00:01, mailer=esmtp, pri=512317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.7.1, stat=Deferred: 450 4.7.1 manu@netbsd.org: Recipient address rejected: Greylisting in action, please try later Jul 24 13:50:53 mx1 sendmail[1672]: q6OARUOM031928: to=manu@netbsd.org, delay=01:23:23, xdelay=00:00:02, mailer=esmtp, pri=602317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.7.1, stat=Deferred: 450 4.7.1 manu@netbsd.org: Recipient address rejected: Greylisting in action, please try later
This is exactly the reason why greylisting is bad.
I have yet to hear of a bot that retries. Thus, there's not reason to set a wait period more than a few seconds, causing the situation above.
That said, there is another use of greylisting not related to bots, which is delaying clients long periods of time in hopes that snowshoe servers will get listed by one's fav dnsbl. Though this isn't very effective against snowshoe. Which is why few use it for this purpose.
-- Stan
On Tue, 2012-07-24 at 07:22 -0500, Stan Hoeppner wrote:
On 7/24/2012 7:13 AM, Morten Stevens wrote:
Jul 24 12:27:32 mx1 sendmail[31933]: q6OARUOM031928: to=dovecot@dovecot.org, delay=00:00:02, xdelay=00:00:01, mailer=esmtp, pri=152317, relay=dovecot.org. [193.210.130.67], dsn=2.0.0, stat=Sent (Ok: queued as 35AF81AE8359) Jul 24 12:28:32 mx1 sendmail[31933]: q6OARUOM031928: to=manu@netbsd.org, delay=00:01:02, xdelay=00:01:00, mailer=esmtp, pri=152317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.0.0, stat=Deferred: Connection timed out with mail.netbsd.org. Jul 24 12:42:57 mx1 sendmail[32292]: q6OARUOM031928: to=manu@netbsd.org, delay=00:15:27, xdelay=00:01:00, mailer=esmtp, pri=242317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.0.0, stat=Deferred: Connection timed out with mail.netbsd.org. Jul 24 12:50:53 mx1 sendmail[32518]: q6OARUOM031928: to=manu@netbsd.org, delay=00:23:23, xdelay=00:00:02, mailer=esmtp, pri=332317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.7.1, stat=Deferred: 450 4.7.1 manu@netbsd.org: Recipient address rejected: Greylisting in action, please try later Jul 24 12:58:41 mx1 sendmail[312]: q6OARUOM031928: to=manu@netbsd.org, delay=00:31:11, xdelay=00:00:02, mailer=esmtp, pri=422317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.7.1, stat=Deferred: 450 4.7.1 manu@netbsd.org: Recipient address rejected: Greylisting in action, please try later Jul 24 13:42:21 mx1 sendmail[1461]: q6OARUOM031928: to=manu@netbsd.org, delay=01:14:51, xdelay=00:00:01, mailer=esmtp, pri=512317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.7.1, stat=Deferred: 450 4.7.1 manu@netbsd.org: Recipient address rejected: Greylisting in action, please try later Jul 24 13:50:53 mx1 sendmail[1672]: q6OARUOM031928: to=manu@netbsd.org, delay=01:23:23, xdelay=00:00:02, mailer=esmtp, pri=602317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.7.1, stat=Deferred: 450 4.7.1 manu@netbsd.org: Recipient address rejected: Greylisting in action, please try later
This is exactly the reason why greylisting is bad.
I have yet to hear of a bot that retries. Thus, there's not reason to
they exist
set a wait period more than a few seconds, causing the situation above.
Not surprising Stanley still doesn't get it, how many mail servers have a retry under 10 minutes anyway, sure as hell none at a "few seconds" , and busy servers with queue limits, could mean a msg set to be retried in 10 mins, may still yet take 2 hours to find its spot in a queue (yes, seen it)
Sendmails greet pause as was noted by an earlier poster was not a bad method, but like grey listing, some spam bots adjusted to suit.
On Tue, 24 Jul 2012, Stan Hoeppner wrote:
On 7/24/2012 7:13 AM, Morten Stevens wrote:
[...]
Jul 24 12:50:53 mx1 sendmail[32518]: q6OARUOM031928: to=manu@netbsd.org, delay=00:23:23, xdelay=00:00:02, mailer=esmtp, pri=332317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.7.1, stat=Deferred: 450 4.7.1 manu@netbsd.org: Recipient address rejected: Greylisting in action, please try later [...] Greylisting in action, please try later Jul 24 13:50:53 mx1 sendmail[1672]: q6OARUOM031928: to=manu@netbsd.org, delay=01:23:23, xdelay=00:00:02, mailer=esmtp, pri=602317, relay=mail.netbsd.org. [149.20.53.66], dsn=4.7.1, stat=Deferred: 450 4.7.1 manu@netbsd.org: Recipient address rejected: Greylisting in action, please try later
This is exactly the reason why greylisting is bad.
I'd say, when greylisting isn't set up correctly. One hour and still greylisting the message? Come on...
I have yet to hear of a bot that retries. Thus, there's not reason to set a wait period more than a few seconds, causing the situation above.
Few seconds is much too short. One of our clients has over 20 servers accross the country, with central GL database. Most of them are MX for the domain, and each one is a storage for some subset of emails in this domain. When a spambot tries to deliver a message, goes through all the MXes - so it takes sometimes 20-30seconds for it to get through all of them...
The initial pre-greeting delay is a good idea - although IMHO users definitely should then use submission port (587) without this delay.
For GL, there is no point in setting times larger than few minutes. Bots either don't retry to send email at all, or retry in legit times. On the other hands, most of the spoiled mail servers (usually in larger corporations) do few delivery retries within few seconds and then after many hours...
So far, this client is still satisfied with GL (set to 10 minutes) since it reduces spam amount by around 50% (about 3k messages a day). Sometimes, when we have troubles with some servers - they are simply added to WL. It doesn't happen too often, although this is a typical business - with lots of mailing campanies, emails that sound as if it was a typical spam etc. ;)
Greetings,
Jacek Osiecki joshua@ceti.pl GG:3828944 I don't want something I need. I want something I want.
On 07/24/2012 10:49 AM, Morten Stevens wrote:
On 24.07.2012 09:16, Arnaud Abélard wrote:
And first of all, even if this is not dovecot related, use a greylisting solution.
No, greylisting is really a bad solution. It is not RFC compliant and delays the mail traffic.
I would prefer a pre-queue content-filtering solution like MIMEDefang or amavisd-new.
Best regards,
Morten
As far as I know greylisting is RFC compliant it even has its own RFC: http://tools.ietf.org/html/rfc6647
Greylisting was prefered for a simple reason If a mail is accepted on our servers we have to deliver it to the user (unless it has a virus)
With greylisting we aren't rejecting potentially spammy mails, we are rejecting misbehaving servers. That's important, legally speaking. We could be in trouble if we rejected an important mail by mistake when our server actually accepted it.
Our users already complain they are getting too much spams (we mark them with [SPAM] in the subject). Without greylist and for the reason I stated above, even if we were able to detect the bot spam as spams, we wouldn't want to reject it and our users would be flooded.
Greylisting isn't a perfect solution. Just a good one. Depends on what you want, I guess.
Arnaud
-- Arnaud Abélard (jabber: arnaud.abelard@univ-nantes.fr) Administrateur Système - Responsable Services Web Direction des Systèmes d'Informations Université de Nantes
ne pas utiliser: trapemail@univ-nantes.fr
24.07.2012 11:57, Arnaud Abélard:
- With greylisting we aren't rejecting potentially spammy mails, we are rejecting misbehaving servers. That's important, legally speaking. We could be in trouble if we rejected an important mail by mistake when our server actually accepted it.
That's something which is not greylisting-specific at all. You must not accept mail you are unwilling or unable to deliver - ever! Creating bounces will make you a source of backscatter and get you blacklisted, eventually. ("Outgoing" mail is a different matter, of course)
But that doesn't mean that greylisting is the only means for fighting spam that is compliant to the above rule. It's, for example, not uncommon to have things like milters or pre-queue filters pipe the incoming mail through a spam checker and accept or reject the mail - during the SMTP dialogue - depending on the result of the check.
-- Regards mks
24.07.2012 14:30, Noel Butler:
On Tue, 2012-07-24 at 14:06 +0200, Markus Schönhaber wrote:
You must not accept mail you are unwilling or unable to deliver - ever!
That insisted behaviour was changed four years ago, read up on RFC 5321
Where does it say so?
IIRC
I doubt you do.
-- Regards mks
On Tue, 2012-07-24 at 15:31 +0200, Markus Schönhaber wrote:
24.07.2012 14:30, Noel Butler:
On Tue, 2012-07-24 at 14:06 +0200, Markus Schönhaber wrote:
You must not accept mail you are unwilling or unable to deliver - ever!
That insisted behaviour was changed four years ago, read up on RFC 5321
Where does it say so?
IIRC
I doubt you do.
s6.2
On 07/24/2012 02:06 PM, Markus Schönhaber wrote:
24.07.2012 11:57, Arnaud Abélard:
- With greylisting we aren't rejecting potentially spammy mails, we are rejecting misbehaving servers. That's important, legally speaking. We could be in trouble if we rejected an important mail by mistake when our server actually accepted it.
That's something which is not greylisting-specific at all. You must not accept mail you are unwilling or unable to deliver - ever!
That's my point. Greylisting screens bad behaviored servers away and if a mail is accepted it will be delivered. If it's detected as a potential spam, it will still be delivered to the end user with a proper tag in the subject.
From what I just read, it seems that indeed postscreen could be an alternative for that purpose.
But screening solutions aren't enough since a lot of unwanted mails are sent from legit RFC compliant servers:
newsletters from sites the users provided their email to and forgot they did.
digital prospecting which is legal if properly done (in France, it must be related to your professionnal field of activity and an unsubscribe link must be provided)
phishing and scams sent from stolen webmail accounts.
Greylisting and DNSBL aren't really useful for any of those, only content analysis will catch them and that's the hard part. Bayesian and markovian filters need training and corrections. Spamassassin rules needs to be added every few weeks, etc.
I kind of like how pyzor and razor work but those are rather slow and tend to use too much CPU. Anyone here who had a good experience with those?
Arnaud
Creating bounces will make you a source of backscatter and get you blacklisted, eventually. ("Outgoing" mail is a different matter, of course)
But that doesn't mean that greylisting is the only means for fighting spam that is compliant to the above rule. It's, for example, not uncommon to have things like milters or pre-queue filters pipe the incoming mail through a spam checker and accept or reject the mail - during the SMTP dialogue - depending on the result of the check.
-- Arnaud Abélard (jabber: arnaud.abelard@univ-nantes.fr) Administrateur Système - Responsable Services Web Direction des Systèmes d'Informations Université de Nantes
ne pas utiliser: trapemail@univ-nantes.fr
People,
this is a mailing list dedicated to Dovecot and the protocols POP, IMAP and MANAGESIEVE with the one or the other detour to storage.
Greylisting and other Anti-Spam techniques, as discussed in this thread, truely are off-topic. Please take discussion offlist or to another list that deals with such stuff.
p@rick
-- state of mind () Digitale Kommunikation
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
and like all the other constant off-topic crud here, you are free to filter it out if you don't wish to see it.
On Tue, 2012-07-24 at 15:46 +0200, Patrick Ben Koetter wrote:
People,
this is a mailing list dedicated to Dovecot and the protocols POP, IMAP and MANAGESIEVE with the one or the other detour to storage.
Greylisting and other Anti-Spam techniques, as discussed in this thread, truely are off-topic. Please take discussion offlist or to another list that deals with such stuff.
p@rick
On 24.7.2012, at 16.46, Patrick Ben Koetter wrote:
this is a mailing list dedicated to Dovecot and the protocols POP, IMAP and MANAGESIEVE with the one or the other detour to storage.
Greylisting and other Anti-Spam techniques, as discussed in this thread, truely are off-topic. Please take discussion offlist or to another list that deals with such stuff.
I think threads like this and storage and maybe others could be moved to some wiki pages. It could be helpful to have a list of possibilities discussing their upsides and downsides, which would work much better in a wiki page than spread into 100 different messages in this list.
So, anyone feel free to create http://wiki2.dovecot.org/AntiSpam and start filling it out.
Am 25.07.2012 13:31, schrieb Timo Sirainen:
On 24.7.2012, at 16.46, Patrick Ben Koetter wrote:
this is a mailing list dedicated to Dovecot and the protocols POP, IMAP and MANAGESIEVE with the one or the other detour to storage.
Greylisting and other Anti-Spam techniques, as discussed in this thread, truely are off-topic. Please take discussion offlist or to another list that deals with such stuff.
I think threads like this and storage and maybe others could be moved to some wiki pages. It could be helpful to have a list of possibilities discussing their upsides and downsides, which would work much better in a wiki page than spread into 100 different messages in this list.
So, anyone feel free to create http://wiki2.dovecot.org/AntiSpam and start filling it out.
hi Timo, good idea, thx for this
by the way , the best anti spam filter , would be the one ,you dont need *g
-- Best Regards MfG Robert Schetterer
fy fy@5dshu.com wrote:
what anti-spam for you used ? dspam?spammassian? amavisd-new ? what is best ?
milter-greylist of course :-) http://hcpnet.free.fr/milter-greylist/
Note that the name is a tribute to what it has been in the beginning, but we now have much more features than greylisting. IMO the really nice thing in milter-greylist is its ACL, which enable different filtering for different recipients. If you add a user-accessible report about what was filtered, then the users can enable/disable filters on the fly depending on their use, which brings to MTA filtering the interraction we used to have in MUA-based filtering.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@netbsd.org
- fy fy@5dshu.com:
what anti-spam for you used ? dspam?spammassian? amavisd-new ? what is best ?
The best goes like this:
- Decide if the SMTP client should be allowed to connect to the server
- Decide if the client should be allowed to send the message
- Decide if the message should be allowed to reach the recipient
For 1 use e.g. 'postscreen' in Postfix. For 2 use SMTP session filters e.g. smtpd_..._restrictions in Postfix For 3 use a combination of content filters like SpamAssassin, ClamAV etc. In case you need to build some content policies e.g. "recipient A may receive message, messages should never be spam filtered for B and C ..." around the filters use amavisd-new, the content filter framework. It also brings features to manage filtered content e.g. quarantine, copy etc.
p@rick
-- state of mind ()
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
-------- Original-Nachricht --------
Datum: Tue, 24 Jul 2012 08:20:08 +0200 Von: Radim Kolar hsn@filez.com An: fy fy@5dshu.com CC: dovecot@dovecot.org Betreff: Re: [Dovecot] what best for anti-spam filter?
what anti-spam for you used ? dspam?spammassian? amavisd-new ? what is best ? i got best results with dspam + graylist. but dspam is not scalable solution, it works only if you do not have many users.
The RICE university is using dspam on about 65K mailboxes without issues: http://it.rice.edu/spam.aspx
Maybe your setup is the problem and not dspam?
The RICE university is using dspam on about 65K mailboxes without issues: http://it.rice.edu/spam.aspx it works with such large number of user only if you use group shared spam/ham dictionaries.
-------- Original-Nachricht --------
Datum: Tue, 24 Jul 2012 11:57:18 +0200 Von: Radim Kolar hsn@filez.com An: Dovecot Mailing List dovecot@dovecot.org Betreff: Re: [Dovecot] what best for anti-spam filter?
The RICE university is using dspam on about 65K mailboxes without issues: http://it.rice.edu/spam.aspx it works with such large number of user only if you use group shared spam/ham dictionaries.
I don't remember Kenneth Marshall saying anything about using shared groups when describing his setup. As far as I know they use an older version of dspam and don't use group support at all. Their backend is PostgreSQL.
Den 2012-07-24 08:20, Radim Kolar skrev:
what anti-spam for you used ? dspam?spammassian? amavisd-new ? what is best ? i got best results with dspam + graylist. but dspam is not scalable solution, it works only if you do not have many users.
depends on backend imho
i know a hoster that only have dspam filtering pr user level, no complains seen in the forum
On Tue, 24 Jul 2012, fy wrote:
what anti-spam for you used ? dspam?spammassian? amavisd-new ? what is best ?
If you can afford using a separate "boundary" SMTP (and, thanks to virtual machines, this is much more common than just a few years ago), MailAvenger is likely to be a very good solution: for Bayesian filtering it relies on plain SpamAssassin, but it really shines in doing deep SMTP transaction analysis, ruling out most spam at that level and making it far less CPU and memory intensive than its counterparts.
You can find it at http://mailavenger.org/
Best regards
Federico Bianchi
Dipartimento di Storia delle Arti
Universita` di Pisa
via Trieste, 38 - I-56126 Pisa (Italy)
tel.(+39) 050 221 6 024; fax (+39) 050 221 6 001
e-mail: <f.bianchi@arte.unipi.it>
===================================================
!DISCLAIMER!: my e-mail reflects _my_own_ opinions!
===================================================On 2012-07-24 2:36 AM, Federico Bianchi fbianchi@arte.unipi.it wrote:
On Tue, 24 Jul 2012, fy wrote:
what anti-spam for you used ? dspam?spammassian? amavisd-new ? what is best ?
If you can afford using a separate "boundary" SMTP (and, thanks to virtual machines, this is much more common than just a few years ago), MailAvenger is likely to be a very good solution: for Bayesian filtering it relies on plain SpamAssassin, but it really shines in doing deep SMTP transaction analysis, ruling out most spam at that level and making it far less CPU and memory intensive than its counterparts.
You can find it at http://mailavenger.org/
Since it doesn't even directly support postfix, I wouldn't even give it a chance.
Personally, my dream antispam system would be ASSP integrated with amavisd-new running only as an after-queue content filter, and use postfix's rock-solid built-in pre-queue anti-spam measures.
ASSP's Block Reporting feature is really awesome for end users to manage anything in their quarantine.
--
Best regards,
Charles
Try this:
http://www.junkemailfilter.com/spam/
On 7/23/2012 8:58 PM, fy wrote:
what anti-spam for you used ? dspam?spammassian? amavisd-new ? what is best ?
On Tue, 2012-07-24 at 10:16 -0700, Marc Perkel wrote:
Try this:
It's also a good idea to place a disclaimer when advertising _your_ products and services on someone else's list
On 7/23/2012 8:58 PM, fy wrote:
what anti-spam for you used ? dspam?spammassian? amavisd-new ? what is best ?
Den 2012-07-24 05:58, fy skrev:
what anti-spam for you used ? dspam?spammassian? amavisd-new ? what is best ?
depends of your gool, if you like to have user controls, then dovecot, dovecot-antispam, with dspam is best, save the spamassassin resources here
amavisd-new is NOT an spam filter btw
and if you want to have no user control then go for spamassassin
currently here i plan to drop spamassassin and only use dspam via dovecot antispam plugin, it save me resources on dns, with lately here is unstable like hell, and talking to dns hosters helps nothing :/
Am 25.07.2012 21:35, schrieb Benny Pedersen:
currently here i plan to drop spamassassin and only use dspam via dovecot antispam plugin, it save me resources on dns, with lately here is unstable like hell, and talking to dns hosters helps nothing :/
why in the world do you not setup our own DNS?
it is not rocket scienece to configure BIND as recursion-resolver and caching server directly on the mail-machine and with high load you should always run local resolvers
Stop replying here and start writing to http://wiki2.dovecot.org/AntiSpam - I added some kind of a template now. Thread closed.
participants (22)
-
Andrzej A. Filip
-
Arnaud Abélard
-
Benny Pedersen
-
Charles Marcus
-
Emmanuel Dreyfus
-
Federico Bianchi
-
fy
-
Gedalya
-
Jacek Osiecki
-
manu＠netbsd.org
-
Marc Perkel
-
Markus Schönhaber
-
Morten Stevens
-
Noel Butler
-
Patrick Ben Koetter
-
Radim Kolar
-
Reindl Harald
-
Robert Schetterer
-
Stan Hoeppner
-
Steve
-
Timo Sirainen
-
Warren Baker