A procmail question...
Mark Ogden
We are restructuring the company network this weekend and I have a procmail
problem that I've been racking my brain with to go on our new Linux mail
server. We need to sort mail into seperate folders per user. Doesn't sound
too difficult right? Well, we need each mail, as a seperate file, to go
into, say, /home/%USERNAME/mail. Now, can anyone come up with a quick and
dirty procmail recipe to do just this?
I could do it using one recipe per user but that's going to get a bit
tedious as we have around forty users. There must be a simple way. All I
need to know really is how to get the user name from the e-mail address
(user...@ourcompany.co.uk), and then use that in a path to the mailbox.
There must be a way to do this but, unfortunately, I cannot find it! Please
help!
Thanks in advance...
--
Mark Ogden
E-Mail: ma...@gabriel.co.uk
Collin Park
> into, say, /home/%USERNAME/mail. Now, can anyone come up with a quick and
> dirty procmail recipe to do just this?
If /home/%USERNAME is the home directory of the user, you could
put something like this in /etc/procmailrc:
DROPPRIVS=yes
:0:
$HOME/mail/.
If not,
DROPPRIVS=yes
:0:
/home/$LOGNAME/mail/.
Both of these assume that the directory $HOME/mail exists.
As written, the above recipes will try to put messages in ascending
numerical order; if you don't care what the files are called, you
can delete the trailing '.' character and it'll run a little faster.
> I could do it using one recipe per user but that's going to get a bit
> tedious as we have around forty users. There must be a simple way. All I
> need to know really is how to get the user name from the e-mail address
> (user...@ourcompany.co.uk), and then use that in a path to the mailbox.
According to procmailrc(1):
Environment variable defaults
LOGNAME, HOME and SHELL
Your (the recipient's) defaults
I am assuming that there's a actual user behind each email address
that you're trying to file mail for.
--
Neither I nor my employer will accept any liability for any problems
or consequential loss caused by relying on this information. Sorry.
Collin Park Not a statement of my employer.
Andrzej Filip
I think it may be what you want
/etc/procmailrc :
:0c
* LOGNAME ?? ^[a-z0-9]+$
* ? test "/home/$LOGNAME" = "$HOME"
{
ORGMAIL="$HOME/mail"
DEFAULT="$ORGMAIL"
}
You may hack procmail code directly but
/etc/procmailrc is more flexible (IMHO).
HTH
--
Andrzej (Andrew) A. Filip http://bigfoot.com/~anfi
an...@bigfoot.com an...@polbox.com an...@sdf.lonestar.org
usenet: http://deja.com/profile.xp?author=an...@bigfoot.com
Feel free to correct the post if YOU think it is required.
Philip Guenther
> Mark Ogden wrote:
...
> I think it may be what you want
>
> /etc/procmailrc :
> :0c
> * LOGNAME ?? ^[a-z0-9]+$
> * ? test "/home/$LOGNAME" = "$HOME"
> {
> ORGMAIL="$HOME/mail"
> DEFAULT="$ORGMAIL"
> }
You do _not_ want the 'c' flag on that recipe: that'll tell procmail to
fork and you'll end up with two copies of each message delivered: one
in the default location and one in the location specified by the
variable assignments in the recipe. Also, there's no need to use the
test command when you can do the comparison directly in the recipe, just
like you did the comparison against the LOGNAME variable:
:0
* LOGNAME ?? ^^[a-z0-9]+^^
* HOME ?? ^^/home/$LOGNAME^^
{
ORGMAIL = $HOME/mail
DEFAULT = $ORGMAIL
}
> You may hack procmail code directly but
> /etc/procmailrc is more flexible (IMHO).
An rcfile may (or may not!) be easier to maintain, but the C code can
definitely do things that you can't _directly_ do in an rcfile.
Finally, there are issues involving when the /etc/procmailrc file is
parsed: in particular, it is *not* parsed when users invoke procmail
with the -p flag or when they specify an rcfile on the command line. As
a result, it is not a good place for overridding compile time defaults
for PATH, SHELL, ORGMAIL/DEFAULT and the like. We've been discussing
adding a new rcfile (named something like /etc/procmail.conf) that is
parsed earlier in the processing sequence and would be capable of
reliably resetting the defaults for variables like ORGMAIL and DEFAULT,
but until that happens (don't hold your breath...), in an environment
where procmail may be run directly by users and not just as the local
delivery agent, the only reliable way to change the default values for
those variables is to recompile procmail.
Philip Guenther
Mark Ogden
.cnm! Is this possible to do from the procmailrc? If not, is there an easy
way to run a shell script after procmail has finished running? If I set each
mail to start with msg. then it shouldn't be too difficult to scan through
each mail dir and replace msg.* with msg.*.cnm should it? If anyone wants a
personal challenge then a pat on the back to the person who comes up with
the best way!
--
Mark Ogden
e-mail: ma...@gabriel.co.uk
Andrzej Filip
> [...]
> An rcfile may (or may not!) be easier to maintain, but the C code can
> definitely do things that you can't _directly_ do in an rcfile.
>
> Finally, there are issues involving when the /etc/procmailrc file is
> parsed: in particular, it is *not* parsed when users invoke procmail
> with the -p flag or when they specify an rcfile on the command line. As
> a result, it is not a good place for overridding compile time defaults
> for PATH, SHELL, ORGMAIL/DEFAULT and the like. We've been discussing
> adding a new rcfile (named something like /etc/procmail.conf) that is
> parsed earlier in the processing sequence and would be capable of
> reliably resetting the defaults for variables like ORGMAIL and DEFAULT,
> but until that happens (don't hold your breath...), in an environment
> where procmail may be run directly by users and not just as the local
> delivery agent, the only reliable way to change the default values for
> those variables is to recompile procmail.
>
> Philip Guenther
Do you know any plans to make procmail more "sendmail friendly" ?
e.g.
1) making it accept -Mprocmail_script_path:extra_param
[ -m + extra_param ]
2) making it speak LMTP (procmail based email filters).
[ It would require quite significant changes :-) ]
Philip Guenther
> Do you know any plans to make procmail more "sendmail friendly" ?
> e.g.
> 1) making it accept -Mprocmail_script_path:extra_param
> [ -m + extra_param ]
This is the first I've heard of such a suggestion. What's wrong with
passing the extra parameter as a separate argument, as is currently
supported? That should be more than sufficient, now that sendmail has
persistent macros. When you were limited to $u and $h it would have
been hard to make it robust (or maintainable...), but now it shouldn't
be so bad.
> 2) making it speak LMTP (procmail based email filters).
> [ It would require quite significant changes :-) ]
Heh. The alpha snapshot of procmail has LMTP support, and has had it
since last December. It only required one new .c file and changes to
two others. I 'just' need to merge the changes from version 3.15 into
the snapshot and test it. No timeline on release yet...
Philip Guenther
Andrzej Filip
> Andrzej Filip <an...@bigfoot.com> writes:
> > Do you know any plans to make procmail more "sendmail friendly" ?
> > e.g.
> > 1) making it accept -Mprocmail_script_path:extra_param
> > [ -m + extra_param ]
>
> This is the first I've heard of such a suggestion. What's wrong with
> passing the extra parameter as a separate argument, as is currently
> supported? That should be more than sufficient, now that sendmail has
> persistent macros. When you were limited to $u and $h it would have
> been hard to make it robust (or maintainable...), but now it shouldn't
> be so bad.
Persistent macros had been introduced in sendmail 8.10.
Quite a few installation uses sendmail 8.9 :-(.
The idea behind -M option proposal is to make procmail more useful
for use in sendmail's mailertable. You can only specify mailer and $h
in mailertable but $h is used in current sendmail's procmail mailer
specification to pass script path ONLY.
mailertable entries I dream about:
# mailer=procmail
# $h=/etc/procmailrcs/shared-mailox.rc:mailbox-for-A-dom
A.dom procmail:/etc/procmailrcs/shared-mailox.rc:mailbox-for-A-dom
B.dom procmail:/etc/procmailrcs/shared-mailox.rc:mailbox-for-B-dom
X.dom procmail:/etc/procmailrcs/uucp-grades.rc:uucp-X-node
Y.dom procmail:/etc/procmailrcs/uucp-grades.rc:uucp-Y-node
Introducing "-M" in procmail is almost trivial (I hope), required changes
in sendmail would be much more challenging (IMHO).
> > 2) making it speak LMTP (procmail based email filters).
> > [ It would require quite significant changes :-) ]
>
> Heh. The alpha snapshot of procmail has LMTP support, and has had it
> since last December. It only required one new .c file and changes to
> two others. I 'just' need to merge the changes from version 3.15 into
> the snapshot and test it. No timeline on release yet...
>
> Philip Guenther
I need a beta release to believe in such wonders :-)