From: "Fco. J. Ballesteros" <nemo@lsub.org>
To: 9fans@9fans.net
Subject: Re: [9fans] upas locking
Date: Thu, 18 Apr 2013 16:51:07 +0200 [thread overview]
Message-ID: <95d2e7ed6bedce278c2a29ca32d77412@lsub.org> (raw)
In-Reply-To: <2e14c2fbb566df6d129d01cc4d835243@kw.quanstro.net>
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]
Yes, perhaps we should stop using that.
Nevertheless, the problem I was trying to address is that
everyone is sharing /mail/tmp (see the scripts in /mail/lib,
although I'm sure you know them from memory :) ), and thus
if one has one problem, it can lock everyone else using /mail/tmp.
I'll take a look now to the countermeasures you suggest.
I think we are applying a few other measures, including
validatesender, but I'll take a look.
[-- Attachment #2: Type: message/rfc822, Size: 5896 bytes --]
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: Re: [9fans] upas locking
Date: Thu, 18 Apr 2013 10:42:56 -0400
Message-ID: <2e14c2fbb566df6d129d01cc4d835243@kw.quanstro.net>
> 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!)
next prev parent reply other threads:[~2013-04-18 14:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-18 9:15 Francisco J Ballesteros
2013-04-18 14:04 ` erik quanstrom
2013-04-18 14:24 ` Francisco J Ballesteros
2013-04-18 14:42 ` erik quanstrom
2013-04-18 14:51 ` Fco. J. Ballesteros [this message]
2013-04-18 15:33 ` Charles Forsyth
2013-04-18 15:43 ` lucio
2013-04-18 15:59 ` Francisco J Ballesteros
2013-04-18 16:12 ` erik quanstrom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=95d2e7ed6bedce278c2a29ca32d77412@lsub.org \
--to=nemo@lsub.org \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).