Hi all!
I was wondering who is using Greylisting in their compangny, and if yes, do they receive any complaints from customers about latency or not deliverance of mail?
Thanks for answer
G.Galland
Am 19.10.2009 um 18:27 schrieb Gregoire Galland:
Hi all!
I was wondering who is using Greylisting in their compangny, and if yes, do they receive any complaints from customers about latency or not deliverance of mail?
we use it for about 35'000 accounts and did not get any complaints. much to the contrary our customers acclaim the brilliant spam filters we have.
Thanks for answer
G.Galland
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
We had it turned on for 150 mailboxes and approx. 200k / in-out emails daily (heavy outbound due to confirmation and statements). As Marc said accuracy with grey-listing is very high - we had about 2 junks per thousand. By design there will be delays with it enabled.
As sales people noticed delivery delays with their sales leads (almost always with new email addresses, new domaines and new smtp servers which simply equals to worst case), we had to turn it off and the delays were obviously better but the accuracy worst, about 10 junks per thousands.
The decision really depends on the purposes of your email usage.
Cheers.
- Gregory
2009/10/19 Gregoire Galland mlgg@hispeed.ch
Hi all!
I was wondering who is using Greylisting in their compangny, and if yes, do they receive any complaints from customers about latency or not deliverance of mail?
Thanks for answer
Am 19.10.2009 18:27, schrieb Gregoire Galland:
I was wondering who is using Greylisting in their compangny, and if yes, do they receive any complaints from customers about latency or not deliverance of mail?
If you don't know about the impact you can run greylisting without actually block something.
In postfix you would add warn_if_reject before the policy daemon. If you enable auto whitelisting this fills your database and when you activate the rejects the users the send you mails frequently wont get blocked.
Another possibility would be running greylisting selective, using a regex to filter only hostname containing dailin patterns or no reverse dns entry at all...
Regards André
On Monday 19 October 2009 18.27:25 Gregoire Galland wrote:
Hi all!
I was wondering who is using Greylisting in their compangny, and if yes, do they receive any complaints from customers about latency or not deliverance of mail?
There are mailservers out there who don't cope with greylisting.
But if you use greylisting with a whitelist including allmost all known mailserver (like doing a query to dnswl.swinog.ch and if listed, don't greylist) you get very good results and don't delay mails from known mailserver which would anyway resend the email later.
-Benoit-
Am Montag, den 19.10.2009, 19:14 +0200 schrieb Benoit Panizzon:
There are mailservers out there who don't cope with greylisting.
Sorry, but these "mailservers" are broken.
http://webattacks.de/exchange-greylist-problem-und-kein-offizieller-patch.ht...
This problem is known since 2003, I think there is no further comment needed ;)
Salut, Andre,
On Mon, 19 Oct 2009 20:48:35 +0200, Andre Timmermann wrote:
Am Montag, den 19.10.2009, 19:14 +0200 schrieb Benoit Panizzon:
There are mailservers out there who don't cope with greylisting.
Sorry, but these "mailservers" are broken.
http://webattacks.de/exchange-greylist-problem-und-kein-offizieller-patch.ht...
This problem is known since 2003, I think there is no further comment needed ;)
There are customers out there that don't care if Exchange is broken, unfortunately. We're living in a world where «broken» may mean «Find a workaround» rather than «Have them fix it».
Greylisting is a feature, not a must-have. And if it breaks when customers want to talk to MS Exchange users, then you will have to disable it or lose your customers. I'm leaving this choice up to you though.
However, this has all been debated (and flamed to death) long before, please refer to the list archives for answers.
On Sun, Oct 25, 2009 at 17:41, Tonnerre Lombard tonnerre@bsdprojects.net wrote:
There are customers out there that don't care if Exchange is broken, unfortunately. We're living in a world where «broken» may mean «Find a workaround» rather than «Have them fix it».
This was an issue with Exchange 2003, that has since then been fixed.
Microsoft recommended Exchange 2003 to be deployed with an Edge server running another MTA to mitigate security risks. Many vendors have sprung in an offered appliances to do this task, but simpler solutions would be to deploy Postfix or another full-fledged MTA.
Basically, anyone that experiences this issue is running a configuration that's not recommended by Microsoft and does not have the proper hotfixes applied to make the not-recommended scenario work correctly.
Exchange 2007/2010 have a much better SMTP implementation, one that can actually talk to the Internet without messing up too much.
I have deployed that patch to all our customers running Exchange 2003. Every other Exchange administrator should do the same.
btw
Spam2Co2 :-): http://img.en25.com/Web/McAfee/CarbonFootprint_12pg_web_REV_NA.pdf
Gregoire Galland wrote:
Hi all!
I was wondering who is using Greylisting in their compangny, and if yes, do they receive any complaints from customers about latency or not deliverance of mail?
Thanks for answer
G.Galland
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Ben,
Should companies calculate extra heat and ressource usage (CPU, RAM, HDD, SAN, LAN, WAN) for filtering spam and ask a counter-part when some spammers get caught to sue them? :)
Would be fun.
- Gregory
2009/10/19 ben mongol gogol@monsoleil.ch
btw
Spam2Co2 :-): http://img.en25.com/Web/McAfee/CarbonFootprint_12pg_web_REV_NA.pdf
Gregoire Galland wrote:
Hi all!
I was wondering who is using Greylisting in their compangny, and if yes, do they receive any complaints from customers about latency or not deliverance of mail?
Thanks for answer
G.Galland
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
last AprilMartin Blapp has presented a nice concept at SwiNOG:
instead of greylisting, the SMTP server delays the first OK response to HELO/EHLO for 30 seconds. That is usually enough for the vast majority of spambots to give up. Also if the client tries to send something before receiving the OK, the connection is dropped immediately.
Martin implemented this hack in a FreeBSD kernel module. Of course this gives more room for performance, but then it binds the solution to a specific OS and kernel release. I personally feel there's something wrong if the kernel has to deal with an application-level protocol. On the other side, you usually install a dedicated server just for incoming mail processing.
I think there should be ways to do it outside of kernel, in userland, in a nice and efficient way. But I never had the time to dig any deeper :) The biggest challenge is to keep thousands of open TCP connections in the memory and still have enough CPU power to process SMTP and deliver the mail.
cheers, stan
----- Original Message ----
From: Gregoire Galland mlgg@hispeed.ch To: "swinog@lists.swinog.ch" swinog@lists.swinog.ch Sent: Mon, October 19, 2009 6:27:25 PM Subject: [swinog] Greylisting
Hi all!
I was wondering who is using Greylisting in their compangny, and if yes, do they receive any complaints from customers about latency or not deliverance of mail?
Thanks for answer
G.Galland
On 19.10.2009, at 21:30, Stanislav Sinyagin wrote:
last AprilMartin Blapp has presented a nice concept at SwiNOG:
instead of greylisting, the SMTP server delays the first OK response to HELO/EHLO for 30 seconds. That is usually enough for the vast majority of spambots to give up. Also if the client tries to send something before receiving the OK, the connection is dropped immediately.
That feature is in stock sendmail. It's called the greet_pause ruleset.
FEATURE(`greet_pause', `5000') dnl 5 seconds
causes the MTA to wait 5 seconds before greeting. You could also use 30000 to make it be 30 seconds, though usually 5 is plenty.
Check http://www.sendmail.org/documentation/configurationReadme for a further description of how to implement.
I think there should be ways to do it outside of kernel, in userland, in a nice and efficient way. But I never had the time to dig any deeper :) The biggest challenge is to keep thousands of open TCP connections in the memory and still have enough CPU power to process SMTP and deliver the mail.
It's not that many thousands of connections. 30 seconds is pretty long, less usually works. The feature set basically loads the box with X extra seconds worth of connections, usually not actually thousands.
Chris
Hi,
That feature is in stock sendmail. It's called the greet_pause ruleset.
FEATURE(`greet_pause', `5000') dnl 5 seconds
causes the MTA to wait 5 seconds before greeting. You could also use 30000 to make it be 30 seconds, though usually 5 is plenty.
The problem here is that sendmail forks() before it delays the connection. This opens another weakness, especially during a DDoS attack. With the five seconds delay, you only catch the pregreeting spammer connections, with a larger delay, the spammers often give up sending anything at all.
I use kernel greatpause support together with graylisting in a second stage in my commercial email appliance.
IMHO graylisting still works best to keep a lot of the connections away. If it is implemented in a clever way, you can bypass mail delays for real email traffic.
-- Martin
I don't have the exact statistics in hand, but about 3 years ago a server with ~10K mailboxes was hit constantly with requests, few connections per second.
Sendmail at that time was known for heavy forking, so people used mainly Postfix or Qmail as email front-end servers. I don't know how far Sendmail is improved since then, but I guess it's still forking on every SMTP request. Also in the old days, sendmail was re-reading its configuration after each fork. I hope it's not the case now :)
In regards to 5 seconds vs. 30, I honestly don't know. Let's wait till Martin reads these messages here :)
Even with 5 seconds delay, an average spam virus attack would blow the server easily if it has to fork on every incoming request. With the new Windows 7 coming up, you never know how vulnerable it's going to be to viruses :)
----- Original Message ----
From: Chris Meidinger cmeidinger@sendmail.com To: Stanislav Sinyagin ssinyagin@yahoo.com Cc: "swinog@lists.swinog.ch" swinog@lists.swinog.ch Sent: Mon, October 19, 2009 9:42:53 PM Subject: Re: [swinog] Greylisting
On 19.10.2009, at 21:30, Stanislav Sinyagin wrote:
last AprilMartin Blapp has presented a nice concept at SwiNOG:
instead of greylisting, the SMTP server delays the first OK response to
HELO/EHLO
for 30 seconds. That is usually enough for the vast majority of spambots to
give up.
Also if the client tries to send something before receiving the OK, the
connection
is dropped immediately.
That feature is in stock sendmail. It's called the greet_pause ruleset.
FEATURE(`greet_pause', `5000') dnl 5 seconds
causes the MTA to wait 5 seconds before greeting. You could also use 30000 to make it be 30 seconds, though usually 5 is plenty.
Check http://www.sendmail.org/documentation/configurationReadme for a further description of how to implement.
I think there should be ways to do it outside of kernel, in userland, in a
nice
and efficient way. But I never had the time to dig any deeper :) The biggest challenge is to keep thousands of open TCP connections in the
memory
and still have enough CPU power to process SMTP and deliver the mail.
It's not that many thousands of connections. 30 seconds is pretty long, less usually works. The feature set basically loads the box with X extra seconds worth of connections, usually not actually thousands.
Chris
Stanislav Sinyagin wrote:
last AprilMartin Blapp has presented a nice concept at SwiNOG:
instead of greylisting, the SMTP server delays the first OK response to HELO/EHLO for 30 seconds. That is usually enough for the vast majority of spambots to give up.
On a heavy traffic mail server, you probably run into a max session problem when you try to hold many idle connections for 30 seconds.
- Dan
Please note, that some mailservers has a default timeout of 30 seconds for smtp connection. So if you go to delay the HELO/EHLO message for 30 seconds, you will probably block legitimate mails, because the sending server will disconnect, caused by his timeout settings.
Patrick
-----Ursprüngliche Nachricht----- Von: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] Im Auftrag von Daniel Kamm Gesendet: Dienstag, 20. Oktober 2009 10:39 An: swinog@swinog.ch Betreff: Re: [swinog] Greylisting
Stanislav Sinyagin wrote:
last AprilMartin Blapp has presented a nice concept at SwiNOG:
instead of greylisting, the SMTP server delays the first OK response to HELO/EHLO for 30 seconds. That is usually enough for the vast majority of spambots to give up.
On a heavy traffic mail server, you probably run into a max session problem when you try to hold many idle connections for 30 seconds.
- Dan
_______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Salut, Stanislav,
On Mon, 19 Oct 2009 12:30:09 -0700 (PDT), Stanislav Sinyagin wrote:
Martin implemented this hack in a FreeBSD kernel module. Of course this gives more room for performance, but then it binds the solution to a specific OS and kernel release. I personally feel there's something wrong if the kernel has to deal with an application-level protocol. On the other side, you usually install a dedicated server just for incoming mail processing.
It's fairly easy to implement in Postfix:
smtpd_helo_restrictions = reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, permit_mynetworks, check_helo_access hash:/usr/pkg/etc/postfix/checks/helo_checks, sleep 30, reject_unauth_pipelining, permit
There you go.
On 19.10.2009 18:27 Gregoire Galland wrote
I was wondering who is using Greylisting in their compangny, and if yes, do they receive any complaints from customers about latency or not deliverance of mail?
I'm doing hostname-based selective greylisting (see http://lists.ee.ethz.ch/postgrey/msg01214.html ff for details( which works absolutely fine for me. No problems at all,
Best regards, Arnold
-
Andre Keller -
Andre Timmermann -
Arnold Nipper -
ben mongol -
Benoit Panizzon -
Chris Meidinger -
Daniel Kamm -
Gregoire Galland -
Gregory Agerba -
Lukas Beeler -
Marc Balmer -
Martin Blapp -
Patrick Studer -
Stanislav Sinyagin -
Tonnerre Lombard