Date: Sun, 16 May 2004 16:02:33 -0500 From: "Micheal Patterson" <micheal@tsgincorporated.com> To: "Gary Kline" <kline@thought.org>, "Chuck Swiger" <cswiger@mac.com> Cc: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: blacklist(s) Message-ID: <02f701c43b89$1f5ea070$0201a8c0@dredster> References: <20040515005503.GA9224@tao.thought.org> <40A579DA.7070404@mac.com><20040516022518.GB70076@tao.thought.org> <40A77452.6050105@mac.com> <20040516201425.GB9464@tao.thought.org>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: "Gary Kline" <kline@thought.org> To: "Chuck Swiger" <cswiger@mac.com> Cc: "FreeBSD Mailing List" <freebsd-questions@freebsd.org> Sent: Sunday, May 16, 2004 3:14 PM Subject: Re: blacklist(s) > On Sun, May 16, 2004 at 10:01:54AM -0400, Chuck Swiger wrote: > > Gary Kline wrote: > > >On Fri, May 14, 2004 at 10:00:58PM -0400, Chuck Swiger wrote: > > >>According to the RFCs, one MUST NOT bounce mail sent to postmaster. > > >>One ought to read the rfc-ignorant.org site I mentioned. > > [ ... ] > > > Well, bit again. The line in my access file was > > > > > > 206.46 550 Verizon email not wanted here > > > > > > that I've commented out. This isn't the first time I've had > > > to fine tune; it probably won't be the last. Apologies! > > > > Consider using FEATURE(`delay_checks', `friend') and add the following to > > the access map: > > > > Spam:abuse@ FRIEND > > Spam:postmaster@ FRIEND > > > > [ Pre 8.12 versions of sendmail use To: instead ] > > > > ...which will allow you to block mail as you please using IP or other > > reject rules, yet not prevent delivery of mail to postmaster and abuse... > > > > Outstanding idea, at least it seems. This site has all > the details: > > http://www.technoids.org/spamlovers.html > > I think that most email to postmaster should be allowed, > any everything to abuse. > > thanks for the tip! (and a tip of the hat), > > gary > > > -- > Gary Kline kline@thought.org www.thought.org Public service Unix > Delay_checks does indeed work. However, there are some side effects that need to be taken into consideration. Since you're basically filtering on the delivery of the message, sendmail doesn't check if the user exists until after acceptance. This means, that for each and every spam message you receive for an invalid user, Sendmail has to send a bounce back to the originator. See the gotcha yet? If not read on. :) For example, let's say, your mail server handles 50 - 100 thousand messages every 24 hours, and 25 thousand of those are spam. Not too uncommon in today's internet. Now, let's say that of those 25 thousand messages, 20 thousand (conservative number) have forged return addresses. You don't see these forgeries on unknown users under Sendmail's normal config as the message is rejected at connection time. Still don't see the gotcha? That's ok. I didn't either at first when it happened to me. Let me explain what I saw with it. If sendmail bounces after message acceptance, it now has to send a bounce to each of those 20 thousand forged addresses. Each of those messages will then bounce and return to postmaster after it can't deliver them and at least, 2 things will most definitely occur. 1. The amount of mail sitting in your mail queue will increase. 2. The amount of mail to postmaster will most definitely increase as these messages fail delivery to the forged originators. If you're like me, you tend to keep tabs on your postmaster email for possible problems, but in my experience, my mail load, both for the server and in my mailbox, jumped 150% on my 2 mx's because of delay_check. I ended up disabling delay_check and using amavisd and spamassassin so that I can filter on connection. I personally don't recommend delay_check to be enabled on a large production mta. For smaller systems that don't pass a lot of email, it's fine. However, for larger systems, I'd recommend using a different method. -- Micheal Patterson TSG Network Administration 405-917-0600 Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?02f701c43b89$1f5ea070$0201a8c0>