procmail
[Top] [All Lists]

forbidding invocation from .forward (was "several messages")

2002-04-30 22:52:08
Mark from asarian-host.net wrote,

| At the risk of alienating ever-so many people, I believe the whole concept
| of extracting recipients from a header is per definition flawed; headers
| are part of the DATA stream, and you cannot rely on any type of "To:"
header
| to contain the actual recipient(s).

There was no risk of alienating anyone by preaching to the converted (or in
this case, to the enlightened); it's well-known on this list that envelope
information cannot always be found in the visible headers.  The only people
you risk alienating are the managers of ISPs who promise virtual domains for
email by dumping all mail for a hosted domain to one user address and trying
to convince the user that the destination address will be in the existing
visible headers (as contrasted to a visible header that the host's MTA adds
specifically for that purpose, such as X-Envelope-To: or Delivered-To:, but
as I understand very few do.)

| 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.

Even that doesn't do the whole job.  A number of different aliases on a
system might belong to a single UID, and the logname alone isn't enough
information.  The best way to invoke procmail as an LDA is not only -d the
logname of the user to whom it is bound but also -a the envelope recipient,
or better yet, to place the envelope recipient address into a visible header
before invoking the LDA so that it will be available if (1) the user invokes
a different thrower via .forward or (2) the user reprocesses the stored
message later.

However, you certainly are persistent.  When you failed to alienate anyone
here in your first two paragraphs, you kept on trying until you did:

| I have always been amazed at why procmail keeps supporting the .forward
| schemes.

For starters, what you said there is incorrect: it is the MTA, not procmail,
that supports .forward.  If you put

 |/bin/true

or

 /dev/null

into .forward, the MTA will happily let all your incoming email vanish, and
procmail would not even be involved.

But your comment that it should be impossible to invoke procmail from
.forward was outright rude.  Either you are dismissing the existence of
systems with more than one user, or you are declaring that a non-admin user
has no right to use any mail thrower except whatever the sysadmin has
installed as the LDA.

Yes, *if* the MTA has been configured to put the envelope recipient onto the
LDA's command line or into the LDA's environment without adding it to the
visible headers, then procmail can do more as LDA than it can as a thrower;
but note that if (a) the MTA doesn't tell it to the LDA at all, procmail as
LDA can do no more than procmail as thrower, and (b) the MTA adds it to the
headers and the user knows where to tell procmail to find it, then procmail
as thrower can do as much as procmail as LDA.

Where procmail isn't the LDA, users can still benefit from it by invoking it
from .forward (as I've been doing for ten years) or by post-processing their
inboxes (as I've often had to do in a pinch).  Yet you have just come out
against that.  What do you propose for users who are not sysadmins?



_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>