* Erik Christiansen <[EMAIL PROTECTED]> [2002-09-12 10:22]: > 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.
that's still the description of a *solution* - and not that of the problem. > b) Archive the same outgoing mail on a server, directed by *the > same header*, either directly or by scripting if necessary. you did not mention any header yet, so "the same header" does not reference it. > o Relying on the Fcc header fails, because that is stripped when the > email is sent, leaving nothing to steer the remote archiving. Fcc is no header line, anyway. > If there is a way to configure its retention, > this would be a clean solution. attach your own X-Fcc header then. > o Currently, an "X-Topic: folder_name" header is used to steer > remote archiving, with an Fcc header steering local archiving. ok - so you already do that then.. > Employing wetware to synchronise the two at all times, and in all > eventualities, is found to stretch its reliability beyond limits. "wetware"? (is there some sexual connotation that i'm not getting?) > Sven's "fcc-hook" proposal had been longingly looked at, .. you mean, multiple copies of one sent mail by use of multiple foldernames in Fcc? > ..but the manpage says *filename*, not command. well, - feature. "one copy suffices". > 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!) how many filters does one need? > 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.) yep.. > a) my_hdr Fcc: default_project_name > 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. i meant "use a '+' sign in front of the folder name, so $folder/name is used rather than './name'." clear now? anyway, i think you should take a look at Gnus - there you can really program it all. the "archiving problem" leads to databases, backup stategies and synchronization problems. and the MUA is *not* the right tool for it. sorry if this burts your bubble.. Sven
