how do I fcc: a nnml folder? and what is gcc? (gnus 5.3)

how do I fcc: a nnml folder? and what is gcc? (gnus 5.3)

[Randal L. Schwartz]

OK, I've just taken the plunge, in an effort to get away from using MH
to read my mail, in starting to have my mailreading in GNUS using nnml
folders.

I've already figured out (in about 6 hours... grrrr...) about procmail
incoming's and B-c and a few other cool things.  I'm still puzzling
over exactly how to remove old mail (the expiry thing is a bit fuzzy
so far), but I can at least B-del it for now.

But now I'm stuck.  What's the right Fcc setup to trigger saving into
nnml "groups" called "nnml:outbox" or "nnml:todo" or whatever?  The
docs say that message-fcc-handler-function is rmail-output by default,
but I can't figure out what nnml function corresponds to rmail-output.

And, the docs mention "gcc" once, and the source mentions it twice,
but that's the end of the road.  Is that the remnants of an experiment
gone bad, or is that what I'm looking for?

[please cc: me on the response... I read this list via the FTP archive]

--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <merlyn@stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn@ora.com)
Web: <A HREF="http://www.teleport.com/~merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me

Re: how do I fcc: a nnml folder? and what is gcc? (gnus 5.3)

[David S. Goldberg]

> But now I'm stuck.  What's the right Fcc setup to trigger saving
> into nnml "groups" called "nnml:outbox" or "nnml:todo" or whatever?
> The docs say that message-fcc-handler-function is rmail-output by
> default, but I can't figure out what nnml function corresponds to
> rmail-output.

There doesn't seem to be a good default.  With rmail-output you can do
something like

	Fcc: |/usr/local/lib/mh/rcvstore +folder

but that's way too much typing for me.  So I wrote a fcc handler
function that did the rcvstore for me.  However, I wasn't real
satisfied with that.  Since I've decided to move away from MH as my
primary means of reading mail in favor of Gnus, I didn't want to have
to deal with the Fcc's ending up in my unseen sequence (which I still
use for some colaborative stuff outside of Gnus).  I know I can muck
with the environment and specify a stripped down mh profile but I
didn't want that.  I also didn't like the fact that using rcvstore
meant having to do nnml-generate-nov-databases.  So I came up with the
following message-fcc-handler-function, which does all the right nnml
stuff.  I've only been using it a couple days now which is why I
haven't said anything about it before - I'm still not sure it's
correct although it hasn't burned me yet.

(defun dsg-message-do-mh-fcc (fldr)
  "Store a message into an MH folder given by Fcc header in message-mode."
  (let* ((fldr (substring fldr (1+ (length (getenv "HOME")))))
	 (group (if (= (string-to-char fldr) ?+)
		    (substring fldr 1)
		  fldr)))
    (if (string-match "/$" group)
	(setq group (replace-match "" nil nil group)))
    (while (string-match "/" group)
      (setq group (replace-match "." nil nil group)))
    (nnml-request-accept-article group nil t)))

The replacement of / with . is necessary only if you're like me and
you're used to doing MH style fcc's with recursive folders.  This lets
me use the mh-to-fcc function from mh-e to get folder completion (I
rebind \C-c\C-f\C-w to mh-to-fcc).

> And, the docs mention "gcc" once, and the source mentions it twice,
> but that's the end of the road.  Is that the remnants of an
> experiment gone bad, or is that what I'm looking for?

I am pretty sure that this is basically what gcc is supposed to do,
but I'm used to fcc and prefer to be able to take advantage of
functions I wrote for mh-e to get default fcc folders etc rather than
have to learn gcc and figure out how to do the same thing with that
header.

--
Dave Goldberg
Post: The Mitre Corporation\MS B305\202 Burlington Rd.\Bedford, MA 01730
Phone: 617-271-3887
Email: dsg@mitre.org

Re: how do I fcc: a nnml folder? and what is gcc? (gnus 5.3)

[Steven L Baur]

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:

Randal> But now I'm stuck.  What's the right Fcc setup to trigger
Randal> saving into nnml "groups" called "nnml:outbox" or "nnml:todo"
Randal> or whatever?  The docs say that message-fcc-handler-function
Randal> is rmail-output by default, but I can't figure out what nnml
Randal> function corresponds to rmail-output.

You mentioned using procmail, the magic secret with Gnus procmail
support is that you do not have to use procmail with it ...

What I do is let Gnus process Fcc's as if they were incoming
messages.  Put a line like:
Fcc: ~/spool/sent.spool

or whatever folder you wish, in your headers.  The copy gets saved in
the incoming procmail spool directory.  The next time you M-2 g or g
to incorporate incoming mail, it will get put into the appropriate
nnml group.  The problem with doing a direct rcvstore is that it only
updates the mh unseen file, and you need to keep the .overview updated
with nnml, and I find it easiest to let Gnus do it.

Note that it is not appropriate to Fcc into spool files used by
procmail.

This technique of putting things into the procmail spool directory can
be quite useful.  I've got a little perl program that snarfs news from
the quickly expiring nntp server to put into nnml groups (since they
can be more convenient to read) which uses it.

Randal> And, the docs mention "gcc" once, and the source mentions it twice,
Randal> but that's the end of the road.  Is that the remnants of an experiment
Randal> gone bad, or is that what I'm looking for?

Yup.  It's useful for keeping temporary copies of postings around in
case one gets lost or bounced, but not for much else, IMO.

Randal> [please cc: me on the response... I read this list via the FTP
Randal> archive]

For this list, it ought to be sufficient to add
Mail-Copies-To: merlyn@stonehenge.com

to your headers.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

Re: how do I fcc: a nnml folder? and what is gcc? (gnus 5.3)

[Raja R Harinath]

Steven L Baur <steve@miranova.com> writes:
> >>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
> 
> Randal> But now I'm stuck.  What's the right Fcc setup to trigger
> Randal> saving into nnml "groups" called "nnml:outbox" or "nnml:todo"
> Randal> or whatever?  The docs say that message-fcc-handler-function
> Randal> is rmail-output by default, but I can't figure out what nnml
> Randal> function corresponds to rmail-output.
> 
> You mentioned using procmail, the magic secret with Gnus procmail
> support is that you do not have to use procmail with it ...
> 
> What I do is let Gnus process Fcc's as if they were incoming
> messages.  Put a line like:
> Fcc: ~/spool/sent.spool
> 
> or whatever folder you wish, in your headers.  The copy gets saved in
> the incoming procmail spool directory.  The next time you M-2 g or g
> to incorporate incoming mail, it will get put into the appropriate
> nnml group.  The problem with doing a direct rcvstore is that it only
> updates the mh unseen file, and you need to keep the .overview updated
> with nnml, and I find it easiest to let Gnus do it.

It's useful, but not safe.  

Mail spool files _should not_ be accessed arbitrarily, since you have
the danger of corrupting them, and of losing mail.

Spool files in the procmail spool directory should recieve the same
careful handling given to, say, `/usr/spool/mail/$LOGNAME'.  They should
be accessed only when you can lock them in such a way that other
"competing" programs (i.e. procmail) cannot/do not try to access the
spool file simultaneously.  Spool files should be accessed only in
mutex.  (Note that this is why Gnus has special procmail support.)

Procmail and movemail use advisory locks on spool files, for mutual
exclusion.  These locks are useful only when all programs involved
recognize them.

You can craft a lock aware `message-fcc-handler-function', that uses the
lockfile(1) program that comes with procmail (Also, such a handler
function won't cause harm on non spool folders either.)  Only then is it
safe to Fcc: to a mail spool.

Thanks for the idea, however.  I occasionally have wanted to use Gcc:
support without loading the whole of `gnus'.  This idea of Fcc:ing to
the procmail spool is an alternative.

- Hari

-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash

Re: how do I fcc: a nnml folder? and what is gcc? (gnus 5.3)

[Sudish Joseph]

Raja R Harinath <harinath@cs.umn.edu> writes:
> Steven L Baur <steve@miranova.com> writes:
>> What I do is let Gnus process Fcc's as if they were incoming
>> messages.  Put a line like:
>> Fcc: ~/spool/sent.spool

> It's useful, but not safe.  

(push "~/spool/sent.not-nnml-procmail-suffix" nnmail-spool-file)

in conjunction with a fixed Fcc to the same file will do the job
safely, with or w/o procmail.  This is assuming that headers in
outgoing mail contain sufficient info to let you split them
correctly...this is usually true.

[ good stuff on procmail locking deleted ]

> You can craft a lock aware `message-fcc-handler-function', that uses the
> lockfile(1) program that comes with procmail (Also, such a handler
> function won't cause harm on non spool folders either.)  Only then is it
> safe to Fcc: to a mail spool.

The problem with this is the handler runs synchronously...you do not
want to wait for the procmail process running on the way overloaded
mail hub to deliver to the heavily banged upon spool partition and
relinquish the lock under your (possibly NFS-mounted on the mailhub,
eww) $HOME for every message you send.

An asynch variation is to just hand a copy of the message to a
procmail sub-process from the fcc handler.  However, since this
assumes that the message contains sufficient info in the headers to be
split appropriately, it is entirely equivalent to using "Bcc: me" and
loses for the same reasons; using nnmail-spool-file with a fixed Fcc
is better for the same assumptions.

-Sudish "managed not to rant on true asynch delivery, yay" Joseph

PS: How about renaming it to nnmail-spool-files, like vm-spool-files?
Backward compatibility is easy enough.

Re: how do I fcc: a nnml folder? and what is gcc? (gnus 5.3)

[Lars Magne Ingebrigtsen]

Sudish Joseph <sudish@mindspring.com> writes:

> PS: How about renaming it to nnmail-spool-files, like vm-spool-files?
> Backward compatibility is easy enough.

It's not worth it.  Actually, this is a kinda general problem -- quite
a lot of the Gnus variables started out as single-value variables, and
have then mutated into lists as it became clear that a single value
was too restrictive.  Perhaps I should just put an "s" at the end of
all new variables I create, just to be on the safe side.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: how do I fcc: a nnml folder? and what is gcc? (gnus 5.3)

[Lars Magne Ingebrigtsen]

"Randal L. Schwartz" <merlyn@stonehenge.com> writes:

> And, the docs mention "gcc" once, and the source mentions it twice,
> but that's the end of the road.  Is that the remnants of an experiment
> gone bad, or is that what I'm looking for?

It's probably what you're looking for, I think.  

If you say something like:

(setq gnus-message-archive-group 
      '((if (message-news-p)
            "nnml:misc-news" 
          "nnml:misc-mail")))

then outgoing news will go to the nnml news group and mail to the mail
group.   Of course, you can make this setup arbitrarily complex -- I
use:

(setq gnus-message-archive-group
      '((if (message-news-p)
            "nnml:misc-news" 
          (concat "nnml:mail." (format-time-string 
                                "%Y-%m" (current-time))))))

to get a month-by-month mail archive group.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."