Procmail delivery to virtual users
Greg Crosby
could you not get the procmailrc in /etc to construct the home directory from the username
ie /var/spool/mail/$USERNAME
Greg Crosby
-
To unsubscribe, send mail to majo...@postfix.org with content
(not subject): unsubscribe postfix-users
Paul Gargan
> I just had a thought
>
> could you not get the procmailrc in /etc to construct the home directory
> from the username
>
> ie /var/spool/mail/$USERNAME
A plan cunning in its simplicity!
So, in /etc/postfix/virtual.cf I have:
orbism.com placeholder
postm...@orbism.com postmaster
pga...@orbism.com orbism.com-pgargan
jbl...@orbism.com orbism.com-jbloggs
In /etc/postfix/main.cf, I have:
virtual_maps = hash:/etc/postfix/virtual.cf
mailbox_command = procmail
My virtual domain is now defined, and valid virtual recipients therein are
specified. The mailbox_command sets up procmail delivery for local users.
But trying to deliver to a virtual user still fails with "unknown user". So
we need something in /etc/aliases:
orbism.com-pgargan: |procmail
orbism.com-jbloggs: |procmail
I can then create a recipe in /etc/procmailrc to stick the mail into the
required folder, by examining the $LOCAL env variable. At the momemnt, I've
got a shell script capturing the email, which shows me what the environment
contains.
After lunch (it's UTC+0100 over here :) I'll dive into the procmailrc man
pages. Thanks for the suggestion!
Paul.
--
Paul Gargan - pga...@orbism.com
Network Administrator, Orbism Ltd.
Paul Gargan
--------------Boundary-00=_VASN45AD7YFEJWLKFS75
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi all,
I was enquiring last week about enabling Procmail delivery to virtual use=
rs.=20
Quick summary of my setup:
In /etc/postfix/main.cf:
virtual_maps =3D hash:/etc/postfix/virtual.cf
mailbox_command =3D /usr/bin/procmail
In /etc/postfix/virtual.cf:
orbism.com whatever
postm...@orbism.com postmaster
pga...@orbism.com orbism.com-pgargan
jbl...@orbism.com orbism.com-jbloggs
I'd tried mapping the virtual usernames to mailboxes in /etc/aliases, but=
=20
that meant Procmail was bypassed. So my /etc/aliases now reads:
In /etc/aliases:
orbism.com-pgargan: |procmail
orbism.com-jbloggs: |procmail
I now have procmail being invoked for all deliveries - both for local use=
rs=20
in /etc/passwd, and virtual users in /etc/postfix/virtual.cf
The question then arose of how Procmail should determine the virtual mail=
box=20
to deliver to. After all, I was no longer mapping virtual users to=20
mailboxes in /etc/aliases (and even if I was, Procmail wouldn't be aware =
of=20
such mapping)
LDAP was suggested. I've never used it, and didn't want to introduce anot=
her=20
possible source of misconfiguration.=20
Greg Crosby then suggested having Procmail construct a mailbox filename f=
rom=20
the username via /etc/procmailrc. This worked.
My virtual mailboxes are set up as follows:
/var/spool/virtual/orbism.com/pgargan
/var/spool/virtual/orbism.com/jbloggs
/var/spool/virtual/domain.tld/jsmith
and so on.
So my procmailrc exmaines the Postfix "Delivered-To:" line, parses out th=
e=20
virtual domain and the virtual username, and then delivers to=20
/var/spool/virtual/$VIRTUALDOMAIN/$VIRTUALUSER
It also checks to see if it's running as "nobody". If not, it's deliverin=
g=20
to a "real" user, and can just stick the mail in $DEFAULT.
I've attached the procmailrc to this email. I'm somewhat new to Procmail,=
so=20
constructive criticism would be appreciated.=20
Thanks everyone for your help,
Paul.
--=20
Paul Gargan - pga...@orbism.com
Network Administrator, Orbism Ltd.
--------------Boundary-00=_VASN45AD7YFEJWLKFS75
Content-Type: text/plain;
charset="iso-8859-1";
name="procmailrc"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="procmailrc"
#
# Global /etc/procmailrc used to handle all deliveries from Postfix
# (both local and virtual users)
#
# Paul Gargan <pga...@orbism.com>, October 7th, 2002
#
# Uncomment the following when debugging.
#
# LOGFILE=/tmp/procmail.log
# VERBOSE=yes
# LOGABSTRACT=yes
#
#
# On Linux (and other OSes?) you can write to syslog from a procmailrc via:
#
# :0ic
# | logger -i -p mail.info "Some message and/or $variable"
#
# This is inefficient as the whole mail gets send to logger on stdin.
# Hence the need for the 'i' flag in the recipe to ignore write errors.
#
#
# This site doesn't use comsat
#
COMSAT=no
#
# First, filter the entire message through SpamAssassin.
# spamc is the client
# spamd is the server daemon
# -f causes spamc to fail safely if it can't contact spamd, so mail's not lost.
#
:0fw
| spamc -f
#
# Next, we test are we a local or a virtual user.
# Local users will have $LOGNAME set to something other than "nobody",
# and have a normal mailbox in $DEFAULT (/var/spool/mail/$LOGNAME)
# In this case, we just deliver to $DEFAULT and quit.
#
:0:
* ! LOGNAME ?? ^nobody$
$DEFAULT
#
# OK, it's a virtual delivery. Postfix will have added a "Delivered-To:" line
# specifying the intended recipient in the format "domain.tld-username".
# Eg mail to "pga...@orbism.com" will have a line reading:
# Delivered-To: orbism.com-pgargan@HOST (where HOST is the current hostname,
# accessible through $HOST).
# Note the leading $ so $HOST gets interpolated.
# Once we get the virtual target, we use sed to chop off the @HOST bit.
#
:0i
* $ ^Delivered-To: \/.+@$HOST
TARGET=| (echo $MATCH | sed -e "s/@.*//")
#
# If the sed didn't match, we'll either be left with nothing, or the original $MATCH
# Following condition catches both these, and stores the mail to a folder "non-postfix"
# (Which should be checked by the mail admin :)
#
:0:
* $ TARGET ?? ^($MATCH)?$
/var/spool/mail/non-postfix
#
# $TARGET should now be in the form "orbism.com-pgargan"
# Use the \/ operator to grab the virtual username.
#
:0
* TARGET ?? ^.+-\/.+$
{
VIRTUALUSER=$MATCH
}
#
# If we can't find this username, store the maill to a folder "no-virtual-user"
# (Which should be checked by the mail admin :)
#
:0:
* VIRTUALUSER ?? ^$
/var/spool/mail/no-virtual-user
#
# Now use sed to get the first part before the virtual username
#
:0i
VIRTUALDOMAIN=| (echo $TARGET | sed -e "s/-.*//")
#
# If the above sed fails, VIRTUALDOMAIN will either be blank,
# or set to the full value of $TARGET. Following regex tests both.
# Note the initial $ modifier to tell procmail to evaluate the
# condition (ie replace $TARGET with its value)
#
:0:
* $ VIRTUALDOMAIN ?? ^($TARGET)?$
/var/spool/mail/no-virtual-domain
#
# Now we've got both a virtual domain, and a virtual username.
# Store the mail to /var/spool/virtual/domain.tld/username
#
:0:
/var/spool/virtual/$VIRTUALDOMAIN/$VIRTUALUSER
--------------Boundary-00=_VASN45AD7YFEJWLKFS75--
Clifton Royston
> I was enquiring last week about enabling Procmail delivery to virtual users.
> So my procmailrc exmaines the Postfix "Delivered-To:" line, parses out the
>
>
> It also checks to see if it's running as "nobody". If not, it's delivering
>
> constructive criticism would be appreciated.
I didn't scrutinize it closely, but I see a hidden gotcha here in
that each of the shell commands you invoke externally to procmail via |
or ` like this:
VIRTUALDOMAIN=| (echo $TARGET | sed -e "s/-.*//")
and executed for each mail delivered to a virtual user. In the case of
this line it's two shells (one for the subshell, one for the echo) +
sed. This means that your load could go very high with a sudden influx
of mail to these virtual users; this might prove to be a minor source
of load relative to the spamassassin overhead, but you should watch out
for it.
If possible try to rewrite the procmailrc a little to minimize the
number of invocation shell commands, though I haven't looked closely to
see if that's possible. You might be able to do some of the splitting
addresses up with procmail's internal pattern matching rather than sed,
for instance, and if so that would save you a number of forks. You are
doing a good thing in determining up front when you can just save to
DEFAULT and exit.
Once you have this set up, I would try putting this config on another
machine and testing it with postal or smtpstone so that you at least
know how it will behave under a given load.
-- Clifton
--
Clifton Royston -- LavaNet Systems Architect -- clif...@lava.net
"As for yourself, ... I am well disposed to hope you may hitherto have
escaped many Vices of your Country. But by what I have gathered from
your own Relation, and the Answers I have with much Pain wringed and
extorted from you, I cannot but conclude the Bulk of your Natives to be
the most pernicious Race of little odious Vermin that Nature ever
suffered to crawl upon the Surface of the Earth."
- Jonathan Swift, _Gulliver's Travels_
Paul Gargan
> If possible try to rewrite the procmailrc a little to minimize the
> number of invocation shell commands, though I haven't looked closely to
> see if that's possible. You might be able to do some of the splitting
> addresses up with procmail's internal pattern matching rather than sed,
> for instance, and if so that would save you a number of forks. You are
> doing a good thing in determining up front when you can just save to
> DEFAULT and exit.
Trouble is, the number of deliveries to $DEFAULT will be minimal - most of
my users will be virtual.
As for the shell invocations, I'm worried about this to, but can't see
another way to manage it. Procmail's \/ operator grabs what follows it into
the $MATCH variable, but offers no way of grabbing what comes before it.
So if you wish to split a string in the form "firstpart-lastpart", it would
seem you need the sed cludge. You're right, it's not pretty.
Paul.
--
Paul Gargan - pga...@orbism.com
Network Administrator, Orbism Ltd.