|
Re: procmail and sendmail virtual hosting
2002-07-03 21:03:36
At 18:20 2002-07-03 -0700, Eric S. Theise wrote:
> again, I'm delivering to users who exist - even if they don't all have
> shell capability, they do exist.
I don't know what exist means. My users are in the password file and
their mailboxes reside on the system, but they do not have shell access,
they do not have home directories, and they only receive email at domains
that are hosted virtually.
They're in /etc/passwd, therefore they exist to the unix system. It isn't
uncommon to have a user with an /nonexistant homedir and an /sbin/nologin
type shell definition, to prohibit them from logging in, while still
providing access to other resources, such as POP mail. OTOH, you could
have a system whereby the POP users are authenticated through an external
DB, rather that the user db, in which case they wouldn't "exist" by my
definition, but your POP server could still authenticate them (this would
presume that the mail system were delivering this mail as some static user
to named files).
You've confirmed that you DO have users, so we move from there.
This is all handled through a systemwide /etc/procmailrc file, which at
the moment only contains:
:0fw
| spamc
This is RUNNING a process which in turn requires a shell. I would expect
your VERBOSE log to report SOMETHING. In any event though, this definatley
could be expected to have problems if the user doesn't have a shell defined.
Preceed that with a:
LOGFILE=/tmp/procmail.testing.log
LOG="${LOGNAME} has a shell of ${SHELL}
"
(yes, with the newline before the closing quote)
Send a test message to one of these users and then check the procmail log.
Could you be specific as to where procmail shows that it's going to pot?
Well, I'd expect your VERBOSE log to show an error about an inability to
run the script if it was being invoked for the user without a shell
definition. Let's start with needing a procmail logfile for that to
happen. AFAIK, procmail shouldn't log anything (VERBOSE or otherwise) to
the system mail log simply because there's no procmail logfile - if you had
failures to run procmail itself at the MTA level because of security issues
(permissions on the .procmailrc for instance), then that sort of error
would log to the system logs.
I find no messages relating to missing shells in any of my logs;
procmail's, /var/log/maillog, or /var/log/messages.
For a procmail log to exist, you'd need to define one. If the above
procmailrc is indeed your whole procmailrc, then it doesn't define a log.
I suppose that by delivering to spamc, I'm delivering to a program, but
the most common installation of spamassassin seems to rely on procmail,
... and may very well assume you have a SHELL, since as an installing user,
you'd sort of need one just to set it all up in the first place. Well, I'm
assuming that - I don't run SpamAssassin, but somehow, I rather doubt it
includes instructions on how to set it up via FTP...
so I'm a little confused by this statement that by delivering to a program,
I'm automatically by-passing procmail as local delivery agent.
Back up a bit, you're confusing the MTA delivery agent selection.
Mlocal is the LDA - local delivery agent. Not surprisingly, this IS a
program, but it is the program invoked for a "local" (M_local_)
delivery. In the sendmail.cf file, you should find a line that starts with
"Mprog", which is the PROGRAM delivery -- what sendmail uses when the
delivery is to a program, rather than a user (the initial delivery from the
MTA, not the fact that the MTA delivers to the LDA program, which itself is
a program, or that the LDA in turn may invoke any programs). There's also
Msmtp, Mesmtp, Msmtp8, Mdsmtp, Mrelay, and several internally defined ones
which won't appear in the file, including:
:include: (see the Sendmail book, section 25.2)
/file
|program
Plus others you might define, or use sendmail M4 rules to
define. Mprocmail is a procmail mailer - *NOT* used for LDA, but for
special invocations of procmail from WITHIN sendmail rulesets. Mdiscard is
one I define so that I can easily discard a message from within
virtusertable and the users db - no bounce, no delivery, just poof. Handy
as hell, but I digress.
For example. if in aliases, you had:
joeuser "|/bin/tickle-my-elmo"
then sendmail would go, "oh, I'm delivering to a PROGram, and select the
Mprog - the M(ailer for a )PROG(ram recipient)
With sendmail as your MTA, to check which mailer it believes should be
used, do the following:
sendmail -bv recipientaddress(_at_)domain(_dot_)tld
This would report the mailer used. Say if it were a program (note the
BEGINNING of the alias):
"|/usr/local/majordomo/wrapper request-answer -C
/usr/local/majordomo/majordomo-some.cf listname"... deliverable: mailer
prog, user "|/usr/local/majordomo/wrapper request-answer -C
/usr/local/majordomo/majordomo-some.cf listname"
Or a file (this is the owner- address for an outbound mailing list which
comes from OTHER mailing lists, so that delivery failures on this one list
just go to the ether):
/dev/null... deliverable: mailer *file*, user /dev/null
Doing this test with an include file though causes sendmail to recursively
resolve all the recipients and their final delivery types (for EACH
recipient), just as with any multi-recipient alias, so be forewarned if you
have any 20,000 user mailing lists to contend with... :O
If procmail isn't the LDA, but the user has a .forward which invokes a
program (such as procmail):
"|IFS=' ' && exec /usr/local/bin/procmail -f- || exit 75 #username"...
deliverable: mailer prog, user "|IFS=' ' && exec /usr/local/bin/procmail
-f- || exit 75 #username"
A regular joe user, without a .forward (they might be listed in
virtusertable or aliases, or not at all, but still have an entry in
/etc/passwd):
someuser... deliverable: mailer local, user someuser
or (elaborated for a virtusertable type of entry where the username may not
be the same as the recipient name):
someuser(_at_)somedomain(_dot_)tld(_dot_)(_dot_)(_dot_) deliverable: mailer
local, user somehosteduser
I personally checked, and as I expected, there's no problem delivering
through /etc/procmailrc for a user with a disabled shell, or for delivering
for users without homedirs (also with no shell). Not with 3.15.2 and 3.22
at least.
So, perhaps you could present us with an example of the virtusertable entry
for one of the recipients you're having problems delivering through
procmail for. Go ahead and tweak the user domain name and the username for
privacy, but if it is a PROGRAM being invoked, don't meddle with it. Of
course, you should also run the sendmail command above for one of these
problem users, and you should ensure that your /etc/procmailrc is defining
a logfile so that you can check it.
And it does process my email.
My gut reaction is that it's because YOU have a shell, and therefore the
program you're running from the procmailrc can be invoked on your
behalf. When procmail fails to invoke a program, it will consider the
filter to have failed, and therefore the message would continue to be
delivered normally - to their mailbox, without any apparent interraction
with the mail filter.
Thus, from the end result, it _appears_ that procmail isn't filtering the
After doing the above diagnostics, and seeing that the problem accounts ARE
being delivered through the 'local' mailer and that procmail IS logging
their passage through the /etc/procmailrc file, try this:
# preserve the shell, then set it to something we know should work for what
# we're doing here.
ORGSHELL=$SHELL
SHELL=/bin/sh
(whatever you're doing)
# do this, or else the SHELL will remain redefined even when your own personal
# .procmailrc is used. Be a good mushroom and undefine ORGSHELL.
SHELL=$ORGSHELL
ORGSHELL
If Mlocal IS being used, the above tweak should fix your problem for the
NOSHELL users...
FTR, I do this as a matter of course on my /etc/procmailrc.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail
|
|