I implemented greylist.pl in my environment (~25k messages per day) and found it to not work well. Many of the large isp's have multiple outgoing e-mail servers which results in the following scenario:
Server 1 attempts to deliver from [EMAIL PROTECTED] and is greylisted. After defined pause Server 2 attempts to deliver from [EMAIL PROTECTED] and is greylisted again. After another defined pause Server 3 attempts to deliver from [EMAIL PROTECTED] and is greylisted again. I imagine this is three entries in the database file for future messages. The end user's message never delivers and they freak out. I know the answer is to probably whitelist these domains but I didn't have the time to keep up with it. Another issue that I ran across was even though I had set the greylist to accept after 30 seconds the sending server would wait much longer to try again (sometimes a half day or more). Do you see this behavior on your side? I would love to turn the rule back on but it caused too many interruptions. YMMV though. Thanks! On 29 Jan 2007 01:26:53 -0500, Jon Carnes <[EMAIL PROTECTED]> wrote:
Thanks for the great discussion. I just finished my last tests on my mail server - which now does Greylisting! I'm using a simple perl script and a few added lines to my Postfix configurations. All in all a fairly simple addition to my other anti-spam tools. http://www.opensource.apple.com/darwinsource/Current/postfix-144/postfix/examples/smtpd-policy/greylist.pl I put the greylist.pl file into /var/lib/postfix chmod a+x greylist.pl Setup a directory for use by the greylist database: mkdir /var/mta chown nobody /var/mta == Note: when I tested the application, it didn't work. perl /var/lib/postfix/greylist.pl It errored-out and told me that it couldn't find the DB-File application needed for the Perl program. It turns out I needed the perl-DB_File RPM. After I installed that, it ran without error. == I then added the following lines to my /etc/postfix/master.cf # greylisting added as "policy" policy unix - n n - - spawn user=nobody argv=/usr/bin/perl /usr/lib/postfix/greylist.pl # == Note: I had played with using user "postfix" instead of nobody, but that turned out to be a *bad* idea. Postfix really got upset with that and let me know with several hundred messages. I changed the app back to "user=nobody", which was the recommended user setting. == The last step was to add these lines to my /etc/postfix/main.cf # Setting up greylisting - using policy in master.cf # actual greylisting app: /usr/lib/postfix/greylist.pl # must allow the policy more time to simulate a SMTP connection policy_time_limit = 3600 # # Specify use of greylisting "policy" at end of all other checks smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination check_sender_access hash:/etc/postfix/sender_access check_policy_service unix:private/policy Note: The file sender_access is a simply a text file with a list of domain names that get accepted without going to the next step (greylisting). The files looks like: ftnc.net OK gw.featuretel.com OK Next I simply restarted Postfix service postfix restart A scan of the logs showed that Postfix was running without errors or warnings - though it was turning away all initial connections (greylisting!) After about 30 minutes, the time specified in the perl script, I began getting my test messages. When I sent a second round of test messages, they came through immediately. Sehr gut! Thanks again. Jon On Sat, 2007-01-27 at 20:25, [EMAIL PROTECTED] wrote: > Grey listing is cool, and it is the one tool I have yet to use against > spammers... The fly-by night guys drop the spam to you via a broken > relay. This lets the mail come to you via a legitimate IP block that has > not yet been added to anyones Block-list. Gray listing will definitely > work very well against a misconfigured mail server. > > I would love to front-end my mail services with an OpenBSD box... Thanks > for the HeadsUp Magnus! Maybe I'll give that a try first, before putting > in a C/R system. I'm not too hopeful though as Spammers do seem to adapt > rapidly these days. We really need to press for smtp-auth to become the > standard of the 21st century. > > Jon > > ----- Original Message ----- > From: Cristobal Palmer <[EMAIL PROTECTED]> > Date: Saturday, January 27, 2007 7:52 pm > Subject: Re: [TriLUG] Another seal broken... thinking of installing a > C/R anti-spam system > To: Triangle Linux Users Group discussion list <[email protected]> > > > It's unfortunate that "spamd" also refers to a deamonized version of > > spamassassin. Is anybody using this OpenBSD version on Linux? > > > > Also, how is this harder for spammers to work around than anything > > else? I was under the impression that many (if not most) pump-and-dump > > spam programs ignored RFCs to the point that they didn't wait for any > > replies whatsoever, so this OpenBSD system would have no effect on > > those programs. Am I wrong? > > > > Thanks, > > CMP > > > > On 1/27/07, Owen Berry <[EMAIL PROTECTED]> wrote: > > > On Sat, 2007-01-27 at 17:03 -0500, Magnus wrote: > > > > OpenBSD's spamd is one of the most brilliant ideas going. The > > best> > adaptation spammers have made to deal with it is simply to > > recognize it > > > > and disconnect before the spam engine gets stuck. > > > > > > I hadn't heard of this before, so I did some reading. I thought > > others> in my situation might be interested in this: > > > > > > http://www.benzedrine.cx/relaydb.html > > > > > > Informative and fairly entertaining. Take that you spammers! :-) > > > > > > Owen > > > > > > -- > > > TriLUG mailing list : > > http://www.trilug.org/mailman/listinfo/trilug> TriLUG > > Organizational FAQ : http://trilug.org/faq/ > > > TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ > > > > > > > > > -- > > Cristóbal M. Palmer > > UNC-CH SILS Student -- ils.unc.edu/~cmpalmer > > TriLUG Vice Chair > > "There are many roads to enlightenment, and thus many roads back to > > the One True Debian" --crimsun > > -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
-- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
