procmail
[Top] [All Lists]

Re: How to stop creation of BOGUS.xxx

1997-03-10 16:33:38

Peter Jaeckel <pj(_at_)jet(_dot_)uk> writes:
On Fri, 7 Mar 1997, Philip Guenther wrote:
...
The Correct way to fix this is to stop trying to deliver local mail
anywhere but at the hub. You'll need to change your sendmail.cf to do
this, of course.  I recommend using the m4 config file generators
(documention of which should be found in /usr/doc/sendmail* on RedHat
systems) and enable either the "nullclient" FEATURE or the MAIL_HUB
define depending on how non-local mail should be handled
[...]

Yes, that would be ideal. However, as it happens, I then run into
other problems. Userids local on this pc may not be the same as site
wide. Thus, I would have to specify for each user for whom this is the

By "userids" do you mean numeric UIDs or login names?  I assume the
later, as the former would make NFS pointless.


case, where it has to go. Alternatively, the user uses .forward
entries. Bu then there are special local users such as root, news,
etc. Emails to them must not possibly leave this pc. There are other
complications. Also, I don't see why I should not attach something to

Define a database doing the mapping, have ruleset 5 use the map and
pass the mapped address back to ruleset 0 on a match.  Users excluded
from the map would be delivered locally.  You're going to have to do
a mapping somewhere.  Right now you're doing it in symlinks.  Wouldn't
a single file be easier?


a mail folder on an NFS-mounted volume where the symlinks in
/var/spool/mail in my case are directed. The nfs daemon on that server

By using a symlink as the last part of the path you make dotlocking
impossible.  More precisely, processes on different machines can lock
a given file at the same time as the lockfiles will be in different
locations.


takes care of locking. Of course I realise that problems can be caused
by local symlinks, and I take responsibility to make sure there are no
such symlinks in /var/spool/mail.

I'm sorry to be the one to tell you this, but RedHat 4.0 (Linux 2.0.29)
DOESN'T SUPPORT KERNEL LOCKING ACROSS NFS!!!  I just tried it myself
here between a linux box running 2.0.29 and an nfs server running
solaris 2.5.  Kernel locking did work between the solaris box and
another one acting as a client, so it's not solaris's fault.  The Linux
people just haven't gotten to it yet (who know, it may work on newer
developmental kernels, but given the history of NFS file locking
implementations, I wouldn't trust it until it was moved to the stable
branch).

So, you basically are doing *no* locking.  Do you consider this
situation acceptable?


It doesn't matter, how you present this problem, there will always be
someone from whose point of view the problem is most easily solved by
stopping procmail doing the system mailbox screening.

When "most easily solved" is broken, it isn't a solution.  We can't
stop you from shooting yourself in the foot, but don't complain to us
when your mailbox is corrupted, and *please* don't suggest to *anyone*
else that they should do this.


If anyone is offended by the forcefulness of my writing, I ask your
forgiveness.  I just take this issue very seriously, and sometimes
my writing out-paces my editing.

Philip Guenther

<Prev in Thread] Current Thread [Next in Thread>