Re: sendmail, deliver and procmail
>> Sendmail can't use its own mail.local because:
>> (1) The standard version does not easily port to Linux, and
>> (2) The Linux version does not do the proper Debian-style mailbox
> Eh? I've been using my own sendmail-8.7.3 package for quite some time now.
> I know I should update it to 8.7.5 but I hope Robs version will become
> good enough for me to drop my own sendmail.
I hope it will become good enough too. :-)
> Anyway, I use the sendmail mail.local. It wasn't very hard to port it,
> *and* it _does_ use <mailbox>.lock dotlocking.. by default.
I admit I didn't try very hard to port it; when I have more time I'll look at
it again. I don't see this as being as critical as some other issues, though,
particularly since `deliver' is a proven solution (despite some people's
objection to the extra dependency.) Eventually what I want to do is make the
choice of local delivery agent arbitrary and as easily configurable as the
rest of the system, and when I do that, I hope to include some form of
`mail.local' as a built-in default.
> Unless I'm really missing something here (which is quite possible - but
> please point it out to me then), just get
> and copy the mail.local part to the debian sendmail-8.7.5 and you're
> done. (Assuming mail.local hasn't changed between 8.7.3 and 8.7.5).
If you actually want my sendmail package to _use_ mail.local, you'll have to
do the right thing to define the LOCAL_MAILER_* macros and rebuild your
sendmail.cf, but I'm sure you knew that. Until I get more time to work on
this, though, this is entirely at your own risk.
> Now that I have your attention ;) is there any chance of moving
> all sendmail files (sendmail.cf, userdb, mailertable etc.) to /etc/mail
> instead of them cluttering up /etc? I want to put a Makefile there to
> create the .db files! Now that I think of it, that Makefile can also be
> used to make the sendmail.cf file from the sendmail.m4 file, and so on.
Yes. It makes sense to do this, and I will eventually do it.
But not yet. :-) It seemed too potentially disasterous to do this and get
something wrong, especially if I don't have time to fix it before 1.1 is
released. If I can guarantee I will have time to work on this _and_ be able to
fix problems before we release 1.1, I will do it.
I _will_ be releasing a new version of the package fairly soon that fixes all
of the more serious bugs that have been reported to date.