[Mdlug] Test message

[Rich Clark <rrclark@rrclark.net>]

On Thu, 28 Sep 2006, Raymond McLaughlin wrote:

>> Postgrey greylisting
>>
>>  	A sending host will connect to port 25 of our machine, which is
>> handled by postfix.  Postfix then compares the message to our internal
>> access list and also checked against the spamhaus.org XBL/SBL combined
>> list.
>
> A cached local copy. or is spamhaus contacted each time?

Spamhaus is contacted each time.  A cached local copy would be a bit of 
effort to pull and the overhead isn't worth the work to eliminate.

> Is there a local whitelist as well?

Incorporated in /etc/postfix/access.

> This first step is part of the configuration of postfix itself, not an other
> program?

Again, /etc/postfix/access, /etc/postfix/client.cidr, et.al. Yes, part of 
postfix.

> Are any added modules, or I guess a servlet needed? Part of the standard 
> package?

Postgrey is a separate add-on package from postfix, pulled from tarball, 
not rpm.  Amavisd-new, spamassassin, and clamav are separate packages 
available as rpms or, as you saw with the case of spamassassin, can be 
installed via perl -MCPAN.

>>  If it passes those checks, it's then passed to postgrey.  If it's a
>> message that has not been seen before, it is temporarily delayed for 300
>> seconds with a 450 smtp response to the sending server.
>
> If it's a message that has not been seen before == Is not identical to a
> previous message. From what you say below the message hasn't been sent (
> deferred delivery) so it's just the header then?

To put it more simply, if the IP address has not connected before, yes, it 
gets the timeout.  There is an automatic whitelisting facility in 
postgrey.  To see a better explanation, execute perldoc 
/usr/local/bin/postgrey.

> 300 second is 5 minute. That's going to slow down a lot of conversations. The
> current server is almost IM like at times.

Remember, the auto-whitelisting feature will take care of repeat customers 
that behave in a normal fashion, thereby returning the performance back 
to the usual millisecond message delivery times.  It's the spam attempts 
from IPs that only connect once in a blue moon that will be slowed down.

>> All MTA software
>> knows to defer delivery on receipt of a 450 code.  Spamware, however,
>> won't bother to resend as it is too wasteful of the spammer's resources.
>> It just moves on to the next address on the list.  I've seen most MTA
>> software retry several times before the postgrey timeout expires, though
>> I'm not certain if it will reject messages after too many retries before
>> the timeout expires.  I'll have to reread up on whether it has that
>> capability.  There's another rate-limiting feature in postfix that I'll
>> detail further on in this explanation.
>
>
>> Postfix/amavisd-new/spamassassin/clamav filtering.
>>
>>  	Once the greylisted message has passed the 300 second greylist
>> timeout, it's passed through to postfix.
>
> So it's postfix to postgrey and back to postfix?

True.

>> Postfix then passes the message
>> to amavisd-new, which runs checks against spamassassin and clamav.
>> Spamassassin is set to tag-only; clamav will toss anything that it finds
>> with a virus to a quarantine directory.  The mail that passes these tests
>> is then returned to postfix for final delivery.
>
> And finally postfix to postgrey and back to postfix, then to clamav and
> spamassasin and finally back to postfix? Just so I'm following.

Nope.  Here:

Inbound --> postfix --> check internal lists and spamhaus RBLs -->
 	postgrey --> postfix --> amavisd --> spamassassin -->
 	amavisd --> clamd --> amavisd --> postfix --> final delivery

>>  	While setting this all up, I noted a new feature in postfix 2.2
>> that I'd not seen in earlier releases, a servlet called anvil, which
>> rate-limits incoming messages.  Anvil will be useful to me at home as I'm
>> still getting little mailbombs from some spammer or two that I've pissed
>> off over the years.  I'll rate limit down to 30 connections and/or 30
>> messages per minute
>
> Is this limit per IP address, or keyed to some other identifier?

Per connecting IP address.

>> and simply drop connection on him.  I don't think
>> those kinds of limits for the LUG server would be a bad idea, either, so
>> it's in place there already.
>
> Would be? So there in place, but latent, i.e. without an actual limit set?

Again, I've implemented these limits already so they'll be in place when 
we go live.  Of course I'll watch it like a hawk and see if there will be 
any problems.

/etc/postfix/main.cf.

smtpd_client_connection_count_limit = 30
smtpd_client_message_rate_limit = 30
smtpd_client_recipient_rate_limit = 30
smtpd_client_connection_rate_limit = 30

-- 
Rich Clark

Summary of IBM's 04/04/2006 reply in support of
its Motion to Limit SCO's Claims Relating to 
Allegedly Misused Material, with apologies to 
Monty Python:

IBM: It's not much of a case, is it?

SCO: Finest in the district!

IBM: Explain the logic underlying that conclusion.

SCO: It's so clean!

IBM: It's certainly uncontaminated by evidence.

--thanks to Juggler9 on Groklaw.net


A good way to deal with stage fright is to first
imagine yourself naked, then imagine yourself
laughing at your naked self and pointing.  Then
you yell to yourself dressed as a cop to "Arrest
that pervert!" before beating your naked body
with a truncheon. -- nu-monet v8.0