Raul Barral Tamayo <raul(_at_)gsyc(_dot_)inf(_dot_)uc3m(_dot_)es> writes:
I'll try my opinion out about delivering a whole domain through
a simple account :-)).
In virtualoffice (spain) we are going to resolve such stuff in
this way . ..
One cannot know the destinatary of a message from the message itself,
the message can have several To accounts or even as noted previously Bcc
accounts and even no account reference, but all of you are missing a VERY
SIMPLE point, when a MTA talk with the last MTA, the first one says WHO
is the destinatary of the message, so what we are going to include this
information until the final delivery a "X header field" as X-To with such
information and drop such field when the message get delivered.
We're not missing that point: you changed the problem. The original
problem was "how do I do this in procmail" and you've changed it to
"how do I do this with procmail and with some changes to the MTA".
And you're correct: if you have an "X-Envelope-To:" header then you can
do the sorting in procmail. _However_, I have yet to see a working
implementation of the "X-Envelope-To:" header. The obvious header
declaration in sendmail:
H?l?X-Envelope-To: $u
(That's from memory, and may be wrong) doesn't work because $u isn't
set if there is more than one destination address. You can always
solve this by hacking the sendmail source, or by using an MTA besides
sendmail that does provide this feature, but either way, it is beyond
the scope of procmail.
It appears that there is an alternative. As of sendmail 8.7, if the
procmail mailer is invoked from the mailertable, then it is passed the
envelope sender and recipient addresses in $1 and $2. To quote the
cf/README file in the distribution:
procmail An interface to procmail (does not come with sendmail).
This is designed to be used in mailertables. For example,
a common question is "how do I forward all mail for a given
domain to a single person?". If you have this mailer
defined, you could set up a mailertable reading:
host.com procmail:/etc/procmailrcs/host.com
with the file /etc/procmailrcs/host.com reading:
:0 # forward mail for host.com
! -oi -f $1 person(_at_)other(_dot_)host
This would arrange for (anything)@host.com to be sent
to person(_at_)other(_dot_)host(_dot_) Within the procmail
script, $1 is
the name of the sender and $2 is the name of the recipient.
If you use this with FEATURE(local_procmail), the FEATURE
should be listed first.
If you do this, be aware that you cannot match directly against the $1, $2...
variables with the ?? condition syntax. You have to set a 'real' variable
and match against that, ala:
RECIP = $2
:0
* RECIP ?? ^info(@|$)
! -f $1 info(_at_)another(_dot_)site
Once again I will say: THIS REQUIRES AN ASSIST FROM THE MTA. YOU *CANNOT*
DO THIS PURELY INSIDE PROCMAIL.
...
: > To fetch the mail I use popclient:
: > popclient -3 -s -u $POPUSER -p $POPPASS -o $TEMPMAIL $POPSERVER
: popclient (at least version 2, version 3 seems better) should never be
: used. It doesn't test delivery before deleting the messages on the POP
: server. If your disk is full, you lose mail.
So you have to exec popclient careful, but nothing more than that.
Even I'm surpised you can say seriously that.
He's saying that when considered by itself, popclient V2 is buggy.
Sure, you can workaround this stupidity on popclient part by checking
for free space. But how much do you check for? At point you'll get
more mail than you reserved space for and you'll lose mail. Seems like
a bug to me. It is my understanding that "fetchmail" does not have
this bug. Why not just upgrade to it? Do we have to all be masochists
and use broken software?
...
I forgot a point, saying that procmail makes Bcc-messages non-private
is something without any common sense. I always send my outgoing messages
to me through the BCC field and I filter them with procmail.
Your mailer doesn't provide a Fcc: feature? Ick.
Philip Guenther