On Sat, 14 Nov 1998 09:05:51 -0500, Didier Godefroy <dg(_at_)ulysium(_dot_)net>
wrote:
era eriksson wrote:
Kludge around it, or use the right tool, which is not Procmail. See
<http://www.iki.fi/~era/procmail/mini-faq.html>, look for "virtual
domain".
I looked, but I don't see much of a practical solution for me, for
now, the one I found was to simply not have those msgs get to
procmail at all, by doing the aliasing for those specific addresses
right in the virtusertable and sending each address straight into a
pop mailbox. I'm not 100% sure it'll work in all situations, what
about the BCCs and other things???
What +about+ BCC? Procmail can't cope with BCC, that's precisely why
you shouldn't be using Procmail for this.
Frankly, I've been meaning to rewrite that section of the FAQ, because
it's not really correct. Here are the basic things I think should be
there:
1. Delivery doesn't depend in any way on what's in a message's
headers. It's perfectly normal for a message to be, say, From:
moron-list(_at_)idjit(_dot_)org, To: moron-list(_at_)idjit(_dot_)org and
still in fact
be sent by joe(_at_)morons(_dot_)com and received in your mailbox.
(On the SMTP level, this is basically identical to BCC: but the
fundamental truth is that the headers can say +absolutely+
+anything+ and it doesn't tell anything about who it's really
for.)
2. Procmail can only act on what's in a message (headers or body) or
on parameters set on its command line. This means that Procmail
can handle BCC: and other variations of this scheme correctly,
given one of the following conditions:
* The envelope recipient is passed to Procmail as a parameter.
This is possible and even normal if Procmail is your local MDA
but practically impossible if you are invoking Procmail via a
.forward or equivalent construct.
* The envelope recipient is passed to Procmail by being written
into the headers by your MTA, as in X-Envelope-To:, or
Apparently-To:, or one of the other hacks people use. This
isn't very hard to do with a configurable MTA per se, but most
configurable MTA:s out there are in and of themselves not very
simple to configure ...
3. You can pretend to get along by simply ignoring the above facts,
and create a bigger problem than you had to start with by trying
to kludge around the problems that inevitably crop up by and by,
as you encounter them. This has proven to be an incredibly popular
option. Granted, a lot of the time a lot of the information you
need is coincidentally in the headers, and some fairly big sites
who ought to know better are relying on this for mail delivery.
For example, fetchmail, I believe, rather successfully uses #3. You
can try to emulate its behavior in Procmail, but it's fairly hairy,
and some of its heuristics are rather hard to code in Procmail.
/* era */
--
.obBotBait: It shouldn't even matter whether <http://www.iki.fi/~era/>
I am a resident of the state of Washington. <http://members.xoom.com/procmail/>