Re: Processing /etc/procmailrc first?
At 18:39 2002-06-06 -0500, Shane Williams did say:
What led me to ask my original question was the fact that I do have a
global rc, and I was seeing situations where it wasn't coming first.
It'd help if you actually lay out the situation that doesn't seem to be
working for you then. As has been pointed out on this list many times in
the past, those of us who have latent psychic ability aren't wont to waste
them on tech support issues. If I've got to waste my psychic powerse, high
stakes blackjack and the Lottery are better uses. That, and the singles scene.
From my own digging, I realize my confusion has more to do with my
confusion over whether sendmail aliases get "delivered" by procmail,
or if sendmail expands them, then hands them to procmail (apparently
Sendmail expands its aliases. If they expand to local addresses, then they
get delivered by the LDA (Mlocal), if they're programs "|something", then
they're invoked by Mprog. Remote addresses, via the appropriate mailer, if
files, they get handled by the file mailer, etc.
In any event, at no time was this little detail mentioned in your query.
So, if I have an alias that calls procmail with a named rc file which
In which case procmail was invoked with an rcfile on the commandline, which
not surprisingly is addressed in that short paragraph I referred you to.
forwards based on content, it doesn't go through the global rc till
sendmail has been called again and hands it off to a real address.
That assumes the rc actually delivers to a MTA-invocation. Even then, the
"hand off" to a "real address" is in fact, a whole NEW message insofar as
the MTA is concerned. It isn't "still delivering" the message, it is
delivering a new message.
Is there a way, while naming an rc in the procmail command, to have
the global rc processed first?
ObQ: why not put your flame before your question?
It isn't automatic, but if you need to use the global rc, have you tried
_including_ it? It WILL NOT be executed as root though (same goes for
including an rc file from /etc/procmailrcs, which can be a useful way of
having /etc/procmailrc set up an environment indended for LDA deliveries,
but the included RC to be for, well, included scripts).
I don't know who you are Sean, so I may be criticizing one of the
Not nearly, but suffice it to say I've been here for many years and
answered a great number of questions freely with my time. Whether I'm
'leet or not should have no bearing - if you don't like my answer, you're
free to ignore my post and ask someone else to read the manpage to you.
That said, I found both your responses condescending at best,
If first directing someone directly to the documentation, then highlighting
specific passages to them is condescending, then I'm guilty as charged. I
beg the courts mercy in sentencing me for this heinous crime.
and rude at worst. Other posts of yours have a similar tone.
There's the matter-of-fact tone, then there's the
you-really-should-read-the-manpages-and-FAQ-first tone, and THEN there's
tone. I use the first one the most, and the second one as needed. The
third I keep locked up in a cage in the cellar, ready to be let out on the
rare occasion that it is needed. Oh, and there's the
Increasingly, people seem to feel they don't need to refer to the
documentation when they can just post their questions online (frequently
not providing any useful backgrounder at all). Thus, when something IS
documented, the answer which best serves everyone is to direct them to the
where they can find it in the documentation. If they learn anything from
it, they might consider looking to the resources next time before posting a
question, and have the answer to their question instead of waiting several
hours for it.
Maybe you're tired of newbies asking the same questions over and over
A good newbie will accept the answer of being told which manpage to look
to, and generally being given their answer in the process. In fact, they
sometimes even say "thanks" in the process. The ones who get indignant for
being referred to the documentation are a different matter.
I apologize if I asked a dumb question. I apologize if I should have
understood the manpage without further clarification.
I quoted the short paragraph directly from the manpage because it contained
the answer you indicated was so elusive. Being written in plain English, I
assumed that you must have missed it. When you indicated that they still
didn't make sense, I then highlighted the passages which spoke directly to
your question, posed as it was.
I apologize if my response to your first post contained some rudeness
of my own, but rudeness tends to ilicit rudeness.
My first reply was far from rude. It certainly isn't my fault if you take
offence at being directed to the passage in the manpage with the answer to
But none of that excuses the tone of your responses.
You're not going to cane me, are you? If so, I've got one little request -
can you have Helga do it? In that little black outfit.
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