procmail
[Top] [All Lists]

Re: sendmail/procmail virtusertable/aliases problem

2002-12-18 14:22:55
At 17:14 2002-12-18 +0100, sven did say:

[snip]

Wow, a request that provides version numbers for everything! Thanks - you wouldn't believe how many people post questions without providing background.

I wrote some recipies which mark emails with some spam characteristics with
[SPAM]

I presume they are in /etc/procmailrc ?

However, I configured Teapop to use /mail/users as the basic directory
instead of /var/spool/mail. All domains on my server are also listed in the
/etc/mail/domain file.

FTR, procmail will need to be recompiled to understand the mail directory being moved, but I take it that /mail/users is ONLY for the accounts handled by teapop, not the regular accounts? Of course, there's another problem - unless you start hacking procmail, procmail cannot assume the identity of the NON-USER recipient to deliver the message to their mailbox, unless the mailboxes are all owned by one system user, and that user is used to invoke procmail. What user actually owns the teapop mailbox files?

To handle those users without system accounts, I create an entry like

How do they _retrieve_ email from the system then? Oh, nevermind, this is answered below.

"foo(_at_)bar(_dot_)com foo.bar.com" in the virtusertable and "foo.bar.com:
/mail/users/foo.bar.com"

You're explicitly delivering to a file - the LDA is never invoked, and thus, procmail isn't being invoked (either as the LDA, or from a (nonexistant) .forward file invocation).

Depending upon the contents of your /etc/procmailrc file, you could still invoke procmail in generic mailfilter mode and specify that file. I'd actually split the code OUT of the /etc/procmailrc file, and use INCLUDERC there to invoke it for local account users. Put the include rc file(s) into /etc/procmailrcs/, then, in your aliases file:

foo.bar.com: "|procmail -m /etc/procmailrcs/popmail.rc /mail/users/foo.bar.com"

(all one line, if it has wrapped in this email)

The popmail.rc would set up things for this type of invocation, and include the same rcfiles as /etc/procmailrc does.


# popmail.rc
# the first commandline arg (from the manual non-LDA invocation) is the file
# to store the mail as.  Use that to define the default delivery mailbox.

DEFAULT=$1

# you may have other variables to define, do them here.

# include the generic spam filter rules also used by /etc/procmailrc
INCLUDERC=/etc/procmailrcs/spamfilter.rc

# mail dropping out the bottom here will be delivered to the DEFAULT mailbox
# file as defined above.


This is overly simplified, since I don't have details about your specific configuration, but the key here is to actually _INVOKE_ procmail on your file deliveries, and the above should accomplish that.

I use something a bit more elaborate for a majordomo list pre-filter, and although majordomo has a user account associated with it, the individual list aliases all run through invoked programs, not just out to the user mailbox.

If you rummage around in the list archives from earlier this year, I've presenteed a couple of variations on a mechanism for allowing individual users to opt in and out of filtering options in an /etc/procmailrc type environment (say, some users would rather _not_ have their subjects fiddled with - with a little work at the front end, you can set things up so that users can individually control which of the global filters apply to their account).

How can I instruct sendmail to pass _all_ emails to procmail (just like it
does for passwd-accounts)? Plus, why are the emails not piped to procmail? I spent about 1-2 weeks messing around with lots of pop3 servers to find one who can do text (or mysq)-based auth instead of /etc/passwd.

Ah, that explains how users without accounts are retrieving their email without a regular account.

I can't help but ask: why not just create accounts without a home directory (or more correctly, with a common empty stub dir), and set the shell to be a no-login shell? Create a group for "popmail", and set that as their primary group when creating their account. Then account maintenance is all still handled through the standard unix tools, and the users cannot log into a shell (and if you've configured ftp properly, their group would also be restricted from logging into ftp). Also, you wouldn't need to hack at your virtusertable and aliases files all the time.

But, that's just how I'd probably have approached it - it keeps everything about the accounts consistent with the unix account management systems, and directories for mailbox files and whatnot remain normal.

---
 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