John Conover wrote,
| Has anyone thought about using procmail/smartmail to do a routing slip
| for email, (by this I mean, it is sent to the first person, and is
| edited, etc. and then edited version is sent to the second, and then
| the third, and so on.) The idea is like routing memos, (not that I am
| a fan of administrative environments.)
|
| I think this could be done with a smartlist mailing list, such that a
| mail is sent to the distribution list, and is saved, and forwarded to
| the first person in the routing list, and when he/she/it replies, it
| goes back to the mailing list, where it is saved, and sent to the
| second person in the routing list, etc. Has anyone done this already?
There's a conceptual obstacle for me: sequential memo routing exists the way
it does because a single hard copy has to be shared by all intended recipi-
ents. With email the sender can dispatch it at the start to everyone who is
supposed to get it, and there is no need for the round-robin approach at all.
From what I gather, the editing you are discussing is only to note who has
already seen the item, not to alter its contents. Allowing people to alter
the contents at any step along the way sounds like a bad thing to me anyway.
In the world of passing around a hardcopy item, changing the text by hand is
glaringly evident.
Anyhow, yes, it can be done as John describes (I just don't know why he'd
want to), as long as each version includes a complete list (like the accumu-
lation of monograms in the margin as a single copy of a paper item is passed
around) of who has already seen it. Soren Dayton has already posted one pos-
sible implementation.
Another way is that each person along the way could have a procmail recipe
to recognize such a memo, keep a copy, and forward it to the next person in
line, except for the last person, who just keeps it. If standard altera-
tions need to be made to the headers or text at any point, procmail can do
that too as needed. When there is a change in the chain, people have to
change their recipes. That can present a cooperation problem (whether from
recalcitrance, forgetfulness, or laziness).
Now here's a thought (which conflicts with my other one of why John would
want this sequential distribution in the first place): a single list of all
recipients in appropriate pecking-order sequence can be kept in a world-
readable file, and someone wishing to send something out for hierarchical
delivery can do something to include that file (such as mailing to an alias
that translates to a pipe). The first recipient is named in a To: header and
everyone else in X-Next-To: headers. Each person along the way has a
procmailrc that changes To: to X-Previously-To: and the ONLY THE TOPMOST
remaining X-Next-To: to To: (while preserving any existing X-Previously-To:).
This keeps a trail of who has received it and who has yet to get it.
(Changing the only To: to X-Previously-To: can be done with formail, but
changing only the first X-Next-To: to To: requires sed or perl or something.)
That way only one person would have to maintain the master pecking order list
and there would be no need to ask everyone involved to adjust recipes when
the delivery sequence changes. However, individuals on the list can still
accidentally hose or maliciously distort their procmailrc recipes and sub-
vert the plan.
But I still don't understand why the original can't simply be mailed to the
whole group at once. If it's so critical to fragile executive egos to get
it sooner than the people who'll actually do the work, the pipe in the alias
can call a program that sends out separate copies with politically expedient
delays between successive dispatches. Again, that has the advantage of not
depending on individuals' procmail rcfiles.