Re: Mails stay in /var/spool/mail, without being forwarded
On Sat, 18 Oct 2008, T o n g wrote:
"Most Linux systems are set up to use procmail as the local delivery
agent by default, so you should not have to set up a .forward."
Or there is something else?
procmail is optional, and so can not be the default MDA
In Debian, sensible-mda(8) is the default MDA, and it, in turn will use
one of procmail(1), maildrop(1), deliver(8), or mail.local(8)
Ah, thanks for the explain.
I hope that such default MDA configuration can be stored in debconf DB so
that I can pre-seed it before (debootstrap) installation.
dpkg-reconfigure -p low sensible-mda
produces nothing configurable.
You missed the whole point of sensible-mda(8) - it uses whatever common
MDA it can find... If you want to force a MDA, edit sendmail.mc !
Which ever you choose, make sure there is a a link for it in
/etc/mail/smrsh (you update them with /usr/share/sendmail/update_smrsh)
YES, running /usr/share/sendmail/update_smrsh without any parameters
solved my problem. Just that,
Previously there is only one link there.
lrwxrwxrwx 1 root smmsp 26 10-10 15:41 mail.local -> /usr/lib/sm.bin/
mail.local*
Having run /usr/share/sendmail/update_smrsh, there are 2 links there.
lrwxrwxrwx 1 root smmsp 17 10-17 22:14 procmail -> /usr/bin/procmail*
is added.
Is it normal? Should /etc/mail/smrsh contains only one link?
The directory is rebuilt whenever sendmail is upgraded, or you
run the command by hand
Until Debian has a way for packages to register hooks and see
install/remove activity, this can't be automated further
Further, where can I get help on /usr/share/sendmail/update_smrsh?
$ file /usr/share/sendmail/update_smrsh
/usr/share/sendmail/update_smrsh: POSIX shell script text executable
$ wc -l /usr/share/sendmail/update_smrsh
94 /usr/share/sendmail/update_smrsh
$ vi /usr/share/sendmail/update_smrsh
/usr/share/sendmail/update_smrsh -h
is no use.
$ man update_smrsh
No manual entry for update_smrsh
I gladly take patches ;^)
--
Rick Nelson
Less is more or less more
-- Y_Plentyn on #LinuxGER
Reply to: