eximlist@??? wrote:
>
> On Wed, 7 Apr 1999, Nigel Metheringham wrote:
>
> >
> > eximlist@??? said:
> > > What I want to do is figure out how to configure exim so that it will
> > > recognize and respect whatever method of locking sendmail is doing on
> > > mailspool files, and also so that it will (in addition to whatever it
> > > normally does) lock them in the same manner so sendmail will recognize
> > > the locks that exim makes.
> >
> > The easiest answer is to do delivery the same way as sendmail does -
> > which is to hand delivery off to another program (probably /bin/mail).
> > You need to set up a pipe delivery into the MDA in the same way that
> > sendmail does.
>
> I've actually just found out its using procmail and am currently trying to
> figure out how to tell exim to call promail the same way that sendmail
> currently does. I have found one sample exim config to do this, but it
> specifies "user = exim" with a comment that indicates this is correct if
> procmail trusts the exim user, but no mention of what is correct if it
> doesnt. I'm assuming the current sendmail setup has no notion of the exim
> user ;P. I don't know how to tell what user sendmail is calling with - or
> exen what user procmail expects to be called as. I figure either root or
> the user associated with the delivery, favoring the latter unless procmail
> needs root for some reason...
I'm not sure about the user, but I know that sendmail on our systems
(SGI Irix) set the active group of the process to "mail", so you might
want to include "group = mail" in your transport. This means that the
user doesn't really matter, as long as the mailboxes are writeable by
"mail", which is the usual convention on many systems.
> > An alternative method is to strace (truss on Solaris, other names on
> > other unices) the MDA and find out how it locks the mail spool.
> >
> > However if you do delivery from multiple machines to an NFS mounted
> > mail spool using mbox files you *will* lose mail. The only questions
> > are how much and how often. NFS is not a reliable filesystem for
> > mail. Things are slightly safer if you do all local delivery on one
> > machine and only read on the others.
>
> Well, there is only one machine that is the MX for the domain. But other
> machines occasionally originate and deliver local mail (such as system
> crontasks sending to root.. etc) to /var/spool/mail which is NFS mounted
> on all machines.
>
> > If you think that NFS semantics are up to mail then try running a Cyrus
> > IMAP server over NFS - the db file structures Cyrus uses break NFS
> > locking every time.
>
> Does procmail properly lock over NFS?
>
> I am under the impression that exim does handle locking NFS-mounted
> mailspools properly - am I incorrect?
>
> Why is locking over NFS a problem, especially if lockfiles are used? (eg
> /var/spool/mail/root.lock)? Is it only a problem for flock/lockf types of
> locking? (which I don't wholly understand anyway)
>
I think the simple answer is: Because NFS is buggy. We have had many
problems related to this that turned out the be caused by NFS bugs.
(They may be fixed now, though.) You should definitely consider letting
one host only deliver mail, i.e. to have the others forward all local
messages to it. This setup is simple to implement as long as the MX
records are correct, you basically just leave local_domains empty on
anything but the primary MX. This should also work for messages sent by
cron as they are always delivered via the MTA on any sane system.
--
- T. Lund
--
*** Exim information can be found at
http://www.exim.org/ ***
