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