Craig Pardey <craigp(_at_)zip(_dot_)com(_dot_)au> writes:
I am trying to setup procmail to do some basic forwarding of mail. I
have an account where all mail to the site goes to one account,
regardless of the user-id.
I am using procmail to filter and forward all mail at this account
depending on the user-id specified. The problem is that if I specify
several addresses in the CC: line of the incoming mail message, procmail
only forwards it to the first one.
i.e. if i send mail like:
$ elm me(_at_)my(_dot_)host
Subject: blah
Copies to:
user1(_at_)my(_dot_)host,user2(_at_)my(_dot_)host,user3(_at_)my(_dot_)host
then procmail checks the rc.users file, but only forwards the mail to
me(_at_)my(_dot_)host and user1(_at_)my(_dot_)host, even though user2 and
user3 also have
entries in the file. Know what I mean?
I'd just like to know how to get around this problem so that all
addresses in the CC: line are checked and processed properly.
WARNING
The following essay is based on a few assumptions that to me seem
reasonable to draw from your posting, primarily an assumption about how
the procmailrc for the common account is setup, and (here's the
dangerous part) how much you know about "deep email anatomy". If,
after reading through the entire message, applying grains of salt where
necessary and keeping in mind that I have a philosophical aversion to
smileys/emoticons and thus avoid applying them, even where humour is
implied, if even after doing that you feel insulted, talked down to, or
just plain annoyed, I request that you send your counter-rant via
personal email. At that point, the list will have fallen asleep while
reading this message, and there's no reason to wake everyone.
END WARNING
First, the rant: DON'T CONFUSE THE ENVELOPE WITH THE MESSAGE!!! The
headers in the message are allowed to contain a list of address in the
To: and Cc: headers that are totally irrelevant to where the message it
going. For example, a message from a mailing list (like this one!) may
simply say "To: procmail(_at_)Informatik(_dot_)RWTH-Aachen(_dot_)DE", with no
visible
sign that "guenther(_at_)gac(_dot_)edu" is an address to which the message is
being delivered. That information, where the message is currently in
the process of being delivered to, is found *ONLY* in the envelope.
Okay, where is this precious envelope? In SMTP the envelope consists
of the MAIL FROM: and RCPT TO: SMTP commands. However, when a message
is given to the local mailer, this information is typically lost.
Well, the envelope _sender_ is usually saved now days in the
Return-Path: header, but the envelope _recipient_ usually only appears
in the form of the login name that the local mailer was passed on the
command line. This can be used, for example, by /etc/procmailrc
scripts that check $LOGNAME to see where the message is set to go.
A problem arises however when people start creating virtual domains.
When sendmail does the aliasing (usually by mailertable I believe?), it
totally loses the original envelope recipient address in the
rewriting. All the addresses get rewritten to the same thing, and
sendmail thus has no reason to differentiate them. Having lost their
independent identities, the now-same multiple recipients are merged to
form one call to the local mailer.
The key point here is that once the envelope recipient is lost by the
virtual domain alias, THERE IS NO WAY TO GET IT BACK! You can wave
your hands and try faking it, but no one in the virtual domain can ever
get onto a mailing list or otherwise receive a piece of mail for which
the header doesn't explicitly contain his/her email address. And
furthermore, even doing that faking is extremely difficult to do
right. What I show below does *NOT* correctly handle messages with
Resent-* headers. This can result in messages being received by people
who shouldn't receive them, possibly violating someone's privacy.
Please keep all that in mind if you decide to use it. It handles a
goodly percentage of the cases, but it'll bite you badly at some point
in the future.
So you may ask, does this mean that virtual domains are hopeless? The
answer is no, you just have to be very careful in the sendmail.cf to
keep the envelope recipient stashed somewhere long enough that it can
be passed as an argument to the local mailer, usually by putting it in
the 'host' part of the mailer triple, though with sendmail 8.7.x,
putting it into the local part with a '+' would probably be incredibly
clean. In the end, it ends up being passed to procmail (standard
/bin/mail has no way of handling this, but we already knew that) as
another argument (i.e., -a orig-envelope-recip), though with some work
it *might* be possible to do it via a new header, but that's uglier and
no more efficient. I don't have the sendmail.cf (or m4 .mc) mods
necessary to do this, but if you post to comp.mail.sendmail (after
checking the FAQ, I think it might be there) someone may be able to
give you further pointers on saving envelope recipients in virtual
domain situations.
Now that I've thoroughly pissed you off by lecturing, here's the ugly,
wart loaded, mis-feature laden, kludged up, half-assed partial
workaround. This doesn't handle messages addressed to both a valid and
a bogus address correctly (in addition to the failings mentioned
above), but at this point, if you're still going to use it, you've
established that you just want an additional 20% on the 40% correct you
have right now, so what's another few % lost?
:0c
* ^TOfirst(_at_)virtual(_dot_)address
! real-address(_at_)somewhere(_dot_)else
:0c
* ^TOsecond(_at_)virtual(_dot_)address
! another(_at_)real(_dot_)address(_dot_)elsewhere
# etc
# Has it been delivered to anyone yet? If so, we're done.
:0
* LASTFOLDER ?? .
/dev/null
# Otherwise, none of the above matched, so send it to someone who can
# deal with everything else.
:0
! default(_at_)for(_dot_)bad(_dot_)addresses
All comments/rebuttals/code snippets/etc are welcomed. Please send them
directly to me.
Philip Guenther
----------------------------------------------------------------
Philip Guenther UNIX Systems and Network Administrator
Internet: guenther(_at_)gac(_dot_)edu Phonenet: (507) 933-7596
Gustavus Adolphus College St. Peter, MN 56082-1498
Source code never lies (it just misleads). (Programming by Purloined Letter?)