blacklist(s)

[Gary Kline]

On Sun, May 16, 2004 at 04:02:33PM -0500, Micheal Patterson wrote:
> 
> 
> ----- Original Message ----- 
> From: "Gary Kline" <kline at thought.org>
> To: "Chuck Swiger" <cswiger at mac.com>
> Cc: "FreeBSD Mailing List" <freebsd-questions at 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 at 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 at thought.org   www.thought.org     Public service Unix