At 02:35 2002-05-01 +0200, Mark did say:
part of the DATA stream, and you cannot rely on any type of "To:" header to
contain the actual recipient(s).
No real argument there.
The only truly reliable way to run procmail, is to invoke it as your LDA
from within your sendmail.cf (or other config file where you define your
mailers), so that recipients ($u) can be parsed as parameter to the LDA.
Ur, the recipients are the LOCAL userids, not their email addresses. If
you've got two dozen domains and one login, $u is pretty much meaningless
to you - if you recieved the message, you were obviously a recipient,
whether directly or indirectly. As to which email address it was addressed
to, you'll have to check the headers, or expect that the MTA is going to
provide more information than it might normally provide. If you want to
configure your MTA to provide more info, procmail is there to receive it,
and you can write your recipes to manipulate based on that.
The standard LDA certainly gets no more information than is passed to procmail.
I have always been amazed at why procmail keeps supporting the .forward
schemes.
... because many users don't have administrative control over the hosts
which they use, and .forward is their only option. I don't see why
procmail discard support for a method which may be the ONLY method many of
its users have to invoke it.
FTR, insofar as procmail is concerned, invoking it from .forward isn't
really different from manually running it and providing the same arguments,
except that error output and result values are seen and acted upon by the
MTA if it is invoked as LDA or via .forward.
The only thing you can know for sure when you invoke procmail from
a .forward file, is that the user who the .forward file belongs to, is one
of the recipients. That is all.
Good argument. Now, what I want to know is who's arguing otherwise?
Trying to extract other recipients from the headers is inherently flawed,
and doomed to be either inaccurate, or very unreliable at best.
Okay. The point?
People are filtering the message based on whatever criteria they choose to
filter the messages on. The subject and the body, and other headers are
all characteristics which people use. In many instances, the ^TO is used
to identify that it _appeared_ to be addressed to some specific address
(perhaps not even the local user). It is still a characteristic of the
message -- if people feel that forged "I'm claiming I'm sending it to you,
but really I sent it to this other address and from there forwarded it to
you" messages are a problem, they can change their approach. Since you
cannot identify OTHER (non-you) recipients of a message (even from the
envelope), except by trusting that the headers are valid, that's what
people have to work with.
If you have a suggestion for a specific workaround, feel free to detail it.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail