At 14:07 2004-06-10 -0600, Scott Wiersdorf wrote:
> I would think he'd want to use something close to the man page
> than re-initiating sendmail, though:
>
> formail -s procmail < some_mbox_not_in_procmail_output_pathway
It sounded like perhaps there were some non-local recipients in there
(though how procmail got a hold of it as the LDA, I woudn't know,
unless they were cc'd or something).
Yea, if they were PERSONAL mail (~/.procmailrc was culprit), then
redelivery via the above formail invocation would be entirely suitable, and
incredibly trivial.
However, I too got the very strong impression that these may have been
munched by an /etc/procmailrc (despite being identified as "my procmail
recipes"), and there are definiate issues with that. Certainly not
impossible to overcome: I scribbled up a script today after seeing the
original post, which is intended to be run as root: it grabs the local SMTP
ID of the message (only possible if the local MTA actually inserts SMTP
IDs), locates the local recipients of that message in the system maillog,
then invokes sendmail in address resolution mode (converting addresses to
local usernames), and then pipes the message to procmail -d (those recipients).
Note that it very particularly looks for mailer=local in the maillog (this
assumes sendmail type logs of course). This solves for recipients who are
not identified in the message headers, avoids delivery to addresses not in
your scope (and in fact, recipients at your domain but who are not local -
file deliveries and users whose email is delivered to remote addresses via
aliases, and program deliveries which wouldn't have been subject to
procmail-as-LDA processing).
The downside is that there's quite a few invoked processes: besides the
master formail which splits the mailbox and invokes procmail for each
message, there are two formails in succession, a grep piping to sed, a
sendmail piping to two seds, and the final procmail redelivery.
Expect some processor hit. Thankfully, one shouldn't need to run it too
often, and hopefully one major mail screwup will teach the admin a lesson.
Unfortunatley, having a ready too to un-fsck the redirected email might
cause some admins to be less cautious about how they process mail.
Might I suggest a *SANDBOX* to the OP?
If delivery just went seriously wrong (i.e., you have external
recipients), the -t flag for sendmail will cause it to read the
message for To:, Cc:, etc. headers and try delivery on those messages
again.
INCLUDING WHEN THOSE RECIPIENTS ARE NOT EVEN LOCAL!
As a mail and listadmin on a large enthusiast site (with approx 29K members
using the discussion lists), I've been at the receiving end of the actions
of some pretty moronic people. The doozie was when some yutz had
reprocessed mail in much the same way (and a LOT of it to boot) - so they
were throwing HUNDREDS of messages back at the list, as well as to every
user who'd been cc'd, etc. Extend that for every other recipient of any
message send to their domain. Ugly. Fortunatley, owing to some filters I
wrote for those same lists, all the resubmissions were identified as loops
and scuttled -- but that didn't keep all the subscribers who'd been
previously cc'd on messages getting from being assaulted from the direct
copies being thrown at them.
Getting that idiot on the phone was a trick too - the ISP he worked for
seemed to think that nobody had a valid reason to talk with their admins
and wanted you you sit in the user support queue instead. The extents some
of us go through to pull other people's heads out of their arses is
astounding at times.
---
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