Ouch! Leaving revelation of the nub of the problem till the attempted
solution, was clearly not helpful. Clearer is:
In order to provide a history of correspondence, filed by project, on
originating laptops and on a server, the two-part goal is to:
a) Archive outgoing mail to one of many local mail folders, as
selected by an email header. The archive folder name can be left at
default or edited while composing the mail.
b) Archive the same outgoing mail on a server, directed by *the same
header*, either directly or by scripting if necessary.
o Relying on the Fcc header fails, because that is stripped when the
email is sent, leaving nothing to steer the remote archiving. If
there is a way to configure its retention, this would be a clean
solution.
o Currently, an "X-Topic: folder_name" header is used to steer
remote archiving, with an Fcc header steering local archiving.
Employing wetware to synchronise the two at all times, and in all
eventualities, is found to stretch its reliability beyond limits.
Sven's "fcc-hook" proposal had been longingly looked at, but the
manpage says *filename*, not command. send-hook takes a command, but
generating one header from the other is more than I can synthesise
from the mutt command set, as yet. (Now if command could be an
external post-filter, we'd be cooking!)
One way out may be to add the sender to the Bcc, and then perform the
Fcc operation by means of procmail processing of the received email.
(And accept the unclean dependency.)
sven> use "+name"
Thanks for this suggestion. I've grepped the mutt and muttrc
manpages, and /usr/share/doc/mutt/manual.txt, for +name and all
occurrences of "name", without locating any such reference.
I'll look further, for the significance of this cryptogram.
Regards,
Erik
