Subject: snarfing via maildrop loses status flags - bug or feature?

From: Nancy McGough <[email-masked]>
Date: Thu, 20 Nov 2003 10:58:10 +0000 (GMT)

When I use a maildrop to snarf messages, the status info (Read,
Flagged, Answered, etc.) is lost. I have not tested this with all
types of MaildropFolder/DestinationFolder combinations but I know
that this happens when both the MaildropFolder and
DestinationFolder are local mailboxes being accessed by local
file system calls (rather than POP, IMAP, or NNTP), i.e.:

 local box -> local box

Before I spend time testing this with other combinations, most
notably

 IMAP box -> IMAP box
 IMAP box -> local box
 local box -> IMAP box

I have a question: Are the status flags supposed to be preserved
during the snarf?

Thanks,
Nancy

-- 
Nancy McGough
Infinite Ink ~ <http://www.ii.com>
Deflexion & Reflexion ~ <http://deflexion.com>
-- 
-----------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/pine/pine-info/
-----------------------------------------------------------------

---

From: Steve Hubert <[email-masked]>
Date: Mon, 24 Nov 2003 14:44:16 -0800 (PST)

> [...]

This is working as designed. All state is lost when the copy is made. We
didn't have any strong reasons for doing it that way, it just seemed like
the right thing to do to have the messages be New after they were snarfed
from the mail drop. What is it you are doing that would make use of the
state? Thanks.

Steve Hubert <[email-masked]>
Networks and Distributed Computing, Univ. of Washington, Seattle

---

From: Nancy McGough <[email-masked]>
Date: Wed, 26 Nov 2003 13:26:52 +0000 (GMT)

> from the mail drop. What is it you are doing that would make use of the

Well I like having the messages that are snarfed marked Recent
and I'm not suggesting that you change that but I'd definitely
like to have the other status flags preserved, namely:

 Read (aka Seen, sometimes aka 'Not New')
 Answered
 Important

I can think of a lot of scenarios where this makes sense, for
example:

1] You have a remote IMAP-accessible maildrop provided by your
mobile phone company. When you are out and about you access these
messages with your mobile phone. You reply to some, mark some
important, leave some unread. When you get back to trusty pine,
you snarf those messages to your long-term message store location
(either local or another IMAP server).

2] Your university's IMAP server does not support procmail so you
route all your messages to a machine that you've set up with
procmail, spamassassin, virus snaggers, etc. Procmail sorts the
messages into blue, green, yellow, and red mailboxes (or whatever
you call them). Then you use your local mail clients to deal with
these mailboxes (again reading, answering, and flagging some
messages). Then you use Pine's maildrop feature to snarf your
green and blue mailboxes and put them on your University's IMAP
server because they have a groovy web-based front end to their
IMAP server that can only be used with mailboxes that are on the
University's IMAP server. [Note that this is a real scenario that
I've been discussing in private email with an old-time Unix geek
that I've know (electronically) since the good old days of the
early 1990s.]

3] You like your archived mailboxes to be very large, i.e.,
thousands of messages, but you want to be able to deal with Recent
messages quickly. So you set up a two-tier snarf process that
looks like this in your incoming-folder list.

 incoming-folders=whatever,
  #move -cmp =cmp
  #move {usenet.server/nntp}#news.comp.mail.pine -cmp
  etc

The first #move command moves all the messages in the -cmp
mailbox to the =cmp mailbox. The next #move command moves all the
messages in the comp.mail.pine Usenet newsgroup to the (now
empty) -cmp mailbox. You then read, reply to, and flag some these
messages. The next time you use TAB to cycle through your
incoming-folders list, this two-tiered snarf is repeated.
[BTW, I do this!]

In all three of these scenarios, it makes sense to maintain the
status flags. I actually cannot think of a scenario where you
would want to lose this information.

I hope this makes sense,
Thanks!
Nancy