At 15:22 2003-03-29 -0600, Shane Williams did say:
I don't know how Ross' system is set up, but I'm using sendmail with
procmail as mda. In this setup, if a user has a .forward file with
simple email addresses, procmail is never called (/etc/procmailrc or
.procmailrc).
Right, ~/.procmailrc calling some global filter isn't going to do much of
anything if the user is going to bypass it with a .forward. Of course, it
isn't clear whether the user is really local at all - if they're not
_really_ a local user (why is it a given that the mail is being _forwarded_
for these specific users?), then why bother having a home directory for
them? Yea, obviously if they have a home dir, they're a "local user", but
if the home dir is created expressly to allow for some mail delivery bodge,
things should be re-thought. Better to just accomplish this via an alias.
If the user does exist locally, the mail could be run through the alias and
then forwarded from there to a local account name. All the real trickery
is within the MTA aliasing, and has virtually nothing to do with procmail,
except perhaps what you opt to pass as $1 to the script. After doing
whatever else it might do with the message, procmail for instance could
forward the message to the actual local account:
:0
! $1.localuser
or something like that, and the MTA would THEN deposit the message in the
individual account (paying attention to the user's own .forward, etc - or
perhaps even that address is a different alias at the MTA level).
Now, as you suggested later in your email, I think you could add an
entry to /etc/alias for any such user and the alias would get
interpreted before the .forward, and give you a chance to stick
procmail in the middle. Of course, this solution doesn't seem
particularly scalable to me.
Oddly, neither does having to maintain a .procmailrc in each of the user's
dirs, so where does that leave us?
/etc/procmailrc and ~/.procmail are both intended to be invoked for
_LOCAL_DELIVERY_. If the user has a .forward that is doing anything other
than manually invoking procmail (necessary only if procmail isn't already
the LDA), then the message isn't being delivered locally.
they just have to have some .procmailrc so the system-wide recipes get
called as well. Considering that a .procmailrc acting as a forward is only
slightly longer than a .forward this seems most reasonable to me.
Certainly. If the user is managing their account, or you even WANT the
user to have such control. Perhaps it's not an opt-in system - what then?
Nonetheless, if anyone knows of a way to force sendmail to invoke
procmail regardless of a .forward, I'm all ears (though it also seems
this would break the expected functionality of .forward thus confusing
more knowledgeable users).
Well, forcing invocation of an /etc/procmailrc would be completely
different functionality from invoking the users ~/.procmailrc. Then, it's
more of an issue of confusing knowledgeable sysadms. <g>
---
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