When I wrote,
T> How is her .forward set up? Just with your address? Ouch,
T> double ouch. I hope not. Do forwards of her mail come
T> to you with an extra Received: header by which they can
T> be distinguished from mail sent directly to you?
Dallman Ross responded,
R> Well, it's "ouch," I'm afraid. I had a simple dot-forward
R> file put in her directory sending mail to me. I have looked
R> for "To: (her)" to do whatever. Of course, that still happens
R> if it's to both her and me. You made me realize, though,
R> that there's also
R> Received: from munged.munged.munged (unknown [mungedIP])
R> by munged (Postfix) with SMTP id 6962C9835
R> for <munged(_at_)ccc-e(_dot_)net>; Wed, 8 Sep 1999 09:06:20 +0200
(MEST)
Then you do have a way to distinguish mail that came straight to you from
mail that was forwarded to you for her.
T> you can add
T> the -a something option to the procmail command line in your
T> .forward, and then your rcfiles can tell who the envelope
T> recipient is:
As it turns out, that won't do you any good, because her mail is also going
through your .forward.
R> I had not known about the -a flag in the .forward. Will
R> have to read the man pages again. Sounds promising.
R> Okay, I skimmed the man page. I tried this in my .forward:
R> "|IFS=' ';/usr/bin/procmail -a weird -tf- || exit 75 #dross"
R> The only difference from what I had previously is the
R> -a flag and the argument "wierd". I sent myself a
R> message, but the word "weird" did not show up anywhere
R> in the headers.
No, it won't show up in the headers unless you put it there with something
like this:
:0hf
| formail -A "X-Command-Line-Argument: $1"
It will show up as $1 inside your procmail rcfile, and usually the best way
to test it is to assign it to a regular variable as I showed before. But as
long as your friend's .forward contains only your address, whatever your
.forward does to your mail it will also do to her mail, so that won't help
you tell the two apart.
What I was suggesting was that, if you have a setuid root procmail binary to
run, or if your OS permits it [check the procmail(1) man page there; if it
was installed at compile time and not copied from another site, it will say
whether that is allowed] and you have a procmail binary that is setuid to you
and setgid to your login group, her .forward could read
"|/path/to/special/procmail -a hername -d yourid"
and your own .forward could read
"|/path/to/special/procmail -a yourname"
Then your .procmailrc could start as follows:
ARG=$1 # sets ARG to hername or yourname
:0
* ARG ?? hername
{ INCLUDERC=$HOME/.rcfileforhermail
HOST }
Another way would be to have the same thing in her .forward and this in
yours,
"|/path/to/procmail -a yourname .differentrcfile"
and then your ~/.procmailrc would handle her mail and ~/.differentrcfile
would handle yours. Technically, you wouldn't even need the two -a options
then.
Finally, even with no special procmail binary, if her .forward were like
this,
"|/path/to/formail -A 'X-Envelope-To: hername(_at_)site(_dot_)domain' |
/path/to/MTA yourname"
then at the least your .procmailrc could tell her mail from yours by the
presence of that header line.
The main thing is that the distinction between her mail and your own must be
made while the MTA still knows whose address is on the envelope and it cannot
depend solely on inference from the visible headers. This boils down to the
same thing as Era's FAQ says about virtual domains.
If the extra Received: header is doing the job, that's great.
If your site's MTA has full support for suffixing ... not just delivering
mail for user+suffix to user but somehow making `suffix' known, and you
could have her .forward changed to
yourid+hername(_at_)your(_dot_)site
that might be the simplest of all. I've a login on a site that runs sendmail
8.9.0, and while I can't source the suffix from .procmailrc, it does allow
this if I know that a particular suffix might be on my mail: if
~user/.forward+suffix exists, it will override ~user/.forward for mail to
user+suffix(_at_)site(_dot_)domain(_dot_) Then you could have in
~/.forward+hername,
"|/path/to/procmail -a hername"
or
"|/path/to/procmail .rcfileforhermail"
with no need for setuid bits or the -d option, because her mail is now yours,
being processed under your permissions.