Date: Sun, 16 May 2004 15:02:21 -0700 From: Gary Kline <kline@thought.org> To: Micheal Patterson <micheal@tsgincorporated.com> Cc: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: blacklist(s) Message-ID: <20040516220221.GE9464@tao.thought.org> In-Reply-To: <02f701c43b89$1f5ea070$0201a8c0@dredster> References: <20040515005503.GA9224@tao.thought.org> <40A77452.6050105@mac.com> <20040516201425.GB9464@tao.thought.org> <02f701c43b89$1f5ea070$0201a8c0@dredster>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 16, 2004 at 04:02:33PM -0500, Micheal Patterson wrote: > > > ----- 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. > Appreciate your input. I was thinking of the side-affect bounces--that's why I qualified with 'at least it seems'. For now, for maybe some small-N days, I'll enable the delay_check feature. If I get slogged by tons of junk, I'll rely on dspam (or another filter). Like just about everything else, this is a learn-by-experience. gary -- Gary Kline kline@thought.org www.thought.org Public service Unix
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040516220221.GE9464>