From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu, 18 Apr 2013 10:42:56 -0400
To: 9fans@9fans.net
Message-ID: <2e14c2fbb566df6d129d01cc4d835243@kw.quanstro.net>
In-Reply-To: <1A70F044-4B17-4D0F-AE80-2BA28F0D28D1@lsub.org>
References: <7C2F640A-2A94-4AA1-9CE9-4E4845F0860F@lsub.org>
	<96ac8463d3e63c152de3bf159eb53fb6@kw.quanstro.net>
	<1A70F044-4B17-4D0F-AE80-2BA28F0D28D1@lsub.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] upas locking
Topicbox-Message-UUID: 43b9fbb2-ead8-11e9-9d60-3106f5b1d025

> The problem was that we had quite a number of upas/fs's and scanmails
> running and it was because one of them had a problem and kept a
> /mail/tmp/L.mbox file locked. All other ones kept waiting for that
> (although all of them were using different "mboxes" created by the
> piped script at /mail/tmp/$pid.blah.blah
>

i'm confused.  doesn't this just make the problem smaller rather
than fixing it?  i would think if scanmail has the same issue, then
mail will still go undelivered, right?

we don't run scanmail.  since scanmail relies on building rules, it
needs constant maintence.  and i didn't want to be on the hook
for that.

instead, i use mechanical defensive measures in smtpd and
validatesender.  the most effective measure is enforcing the
rfc2821 rule that the ehlo string must look up in dns.
to appease imap4 clients, there's a flag to force auth
for clients ehlo'ing incorrectly.

spamhaus does a good job cleaning up what remains.

- erik

http://www.quanstro.net/magic/man2html/8/smtp

(yes, that's ugly!)