Subject: FYI: L. Wirzenius's "much mail" page

From: "Robin S. Socha" <[email-masked]>
Date: 26 Oct 1997 12:19:29 +0300

Hi there,

I just came across this essay by the esteemed Lars Wirzenius and found it
interesting with respect to pine. I thought I'd put this to discussion in
this forum since I find pine definitly *not* capable of dealing with
large amounts of email. I'm talking 500+ mails a day. Whenever I thought
pine would do the job, I marked the paragraph with a +, when I thought it
didn't, with a - (or -- when pine just plainly sucked). I've marked my
comments with ** 

If you think this mail sucks - no biggie, just drop dead. Actually,
I'd rather hear some constructive criticism, because there hasn't been
much input from the list afaics, except for some creeps whining for
better header munging support. 

So here it goes...

Have a nice Sunday all,
Robin

     _________________________________________________________________
                                      
         Lars Wirzenius, last modified 19 October, 1997.

Some notes about handling large amounts of e-mail
   I used to get a lot of e-mail. At one point, I got around 650 e-mail
   messages per day, from various high and low volume mailing lists, or
   directly from people. I've since cut down my e-mail intake to less
   than a hundred per day, but I think I have some insight on what is
   needed for dealing with large amounts of e-mail.

Automatic filtering
-- When the e-mail comes via many lists, it is imperative that there is a
   way to automatically filter e-mail to different folders, so that lists
   can be separate, and so that it is easier to do important lists first.
-- Filtering does not have to be based only on the list, so the criteria
   should be flexible enough to allow other sorts of filtering as well.
   At least, one should be able to filter based on any header and the
   presence or absence of a string in that header.
** procmail is ok, but not available on some systems. XFmail's stuff
** is a good example how to make filtering user-friendly.
-- The mailer must be able to show which folders have new messages, and
   preferably how many.
** I would have added a couple more minuses if I had the place. Pine's 
** behaviour here is totally braindead - and tabbing is *not* what I
** want when reading a hv-list.

Proper threading
-  When viewing a long discussion, it helps understanding it immensely
   if the messages are shown in a logical order: a reply is shown
   immediately after the message it is a reply to. Merely sorting
   messages by subject and date is not good enough.
** Amen   
-  Most mail user agents add an In-Reply-To or References header when
   replying to a message, and add the Message-ID of the replied-to
   message to that header. This can be used to construct a tree of the
   discussion, with replies being children of the message they are
   replies to.
** mutt does a good job here   

Many inboxes
+  The mailer should be able to fetch mail from several locations: a
   traditional spool file or from POP or IMAP mailboxes. All at the
   same time, and without getting confused even if they may contain
   the same messages.

Form letters
-  Many people will ask identical questions, and the mailer should
   provide some support for using form letters. The easier, the better.
** Have I mentioned Gnus today, yet? However, I don't see form letters 
** as a vital point - except that Gnus' junk.el _really_ kicks ass.

Different sender addresses, signatures, etc
-  One often needs to have slightly different personalities in different
   contexts, and the headers and signatures of the letters should reflect
   this. For example, one might want to use a private address for personal
   mail (I use [email-masked]) than for business mail ([email-masked]), even if
   the mail is actually processed at the same place.
** mutt, Gnus...

Easy to cut away extra addresses when replying
+  A common problem with mailing lists is that their messages collect
   large lists of Cc's. When person A sends a message, it lists only
   the list as a receiver. When B responds, his mailer adds A to the
   Cc list.  When C replies to B's message, his mailer adds B. And so
   on.
+  The mailer should make it easy to reply to messages on lists so
   that only the list is given as a receiver. (It should also be
   possible to keep the other addresses, of course.)

Good MIME support
   MIME is common enough that every mailer must support it, and it's
   so obviously a Good Thing that it should be supported well.
-+ The mailer should do its utmost to show any content type, including
   binary stuff. If nothing else, the mailer should show the printable
   parts of an unknown binary type (perhaps at request). Many bad
   mailers will put a bogus content type, but a good mailer will allow
   the receiver to process the mail anyway.
** better MIME support is under way (or so I've heard ;-)), but
** currently pine depends too much on hacking the mailcap. Especially
** html crap isn't handled well.
-  Supports for attachments (receiving and sending), various encodings,
   and so on, are essential.
** With Gnus, I can select several kinds of encoding types. This is
** certainly an advantage
Address completion
   Most mail user agents have some kind of alias feature, but that is
   not good enough. When you're having a large correspondence, it is
   impossible to define an alias for every person you ever discuss
   anything with.
+  Instead, the systems should keep track of all addresses in all
   messages and provide a way to search them. This works much better
   than aliases.
** pine's address book is pretty good. bbdb is better, of course,
** since it will let me search _and_ mark recipients by regexps.
   Aliases good for things that are needed often, but they break when
   there are too many of them, or when you use them rarely enough
   that you forget them.

Automatic expansion of aliases and local addresses
+  To prevent mistakes, the user interface for using aliases (if they
   are implemented at all) must expand the aliases automatically. This
   will make it much harder to use an alias by mistake.
-  Also, if an address is local, the system should expand it to show
   the full name of the local user, if possible. This also prevents
   mistakes.

Fast
-  When processing lots of mails, the mailer had better be fast. Even
   small delays cumulate to large irritation. Large amounts of mail
   will mean large folders, but that is no excuse for using much time
   to process them.
** mutt (in my experience, which is Intel Linux and Alpha Linux only)
** is faster. Pine tends to get _really_ slow when the inboxes get
** quite large. In fact, it took pine about 70% of the time to open a
** mailbox that Gnus needed to open, sort, score, kill, wash and
** thread the same mailbox.

Many folders
-  There will be a need to save messages in various folders for
   archival.  To keep things manageable, the folders have to be
   hierarchical, since a one-level structure breaks when there are
   many folders. There will be many.
** Ok, I can open several folder collections, but (and this goes along 
** with pine's lack of threading) this is not very "intuitive". My
** Gnus message tree is 100x easier to scan than the kluge I had with
** pine.[1]
+  It must be easy to select a different folder to view, and to copy
   and move messages between folders, one by one or en masse.  It must
   be easy to create, delete, rename and move folders.
   
Archiving, expiration
+- Moving messages one by one to archives is too much work for many
   messages. For example, when following an important mailing list, it
   may be necessary to archive all messages to it. The mailer should
   support this in some suitable way, e.g., by providing an `archive'
   button that move the messages from the folder with new messages for
   the list to its archive folder, or by making it easy to keep the old
   message in the same folder (but still keeping it easy to find the new
   stuff).
** Pine's archiving is ok, but an "archive now" function would be
** neat. Did I ever mention that lack of macros sucks?
-- At the same time, some lists do not require eternal archiving, so
   it is necessary to provide some automatic expiration of archived
   messages. The period of expiration needs to be settable for each
   archive separately, and it must not apply to all saved messages.
** Ok, here comes one of Gnus' strongest points: it expires mail and
** news alike, and in an intelligent manner. 
-- The archival and expiration should also be rule based, so that only
   messages matching some particular rules are archived or expired. For
   example, one might want to archive only messages whose subject
   contains "ANNOUNCE" or "IMPORTANT", or expire only messages that don't
   have such subjects.
** <rant> GnusGnusGnusGnus </rant>   

Searching
-- The archives should be searchable: full text searches, and for certain
   authors, subjects, dates, and other such criteria. One often needs to
   refer to old correspondence, but finding it in even a modest archive
   will be difficult, regardless of how it is organized, unless there is
   some way to search it in addition to just browsing it.
** XEmacs -> Gnus -> igrep -> >KeWL<   

Who said what? Did I say that?
-  The mailer must keep copies of all messages sent, and save replies
   with the replied-to messages. It must be able to find messages
   written by a certain author, and find messages that are replies to
   a given message, or the message that a given message is a reply to,
   whether in the same folder or not.
** Pine's behaviour is ok, except for the latter part of this paragraph.  

Many concurrent operations
+  It must be possible to start several concurrent drafts at once,
   and to suspend and continue writing on the drafts at will. And,
   while writing, one must still be able to view other messages, move
   messages around and delete them (including the one being replied
   to), and otherwise function normally.
-  It must be possible to view several messages at once, and have several
   folders open at once.
** Running multiple copies of Pine is just not it, is it?   

Compatibility
+  The larger the correspondence, the larger the diversity of the
   software the correspondents use. The mailer must spend much effort in
   being compatible with all of them.
** I don't quite get this, but I don't give a **** about being
** compatible with Microsuck. Pine handles u*ix mail ok, period.
+  The mailer should not store messages in special formats, unless
   absolutely necessary. It should use folder and message file formats
   that are compatible with other mailers, in case it is ever necessary
   to switch to another mailer.
   
Security
   In the global Interent, security is everyone's problem. Eavesdropping,
   forgeries, mailbombs, and such are commonplace. The mailer must do its
   best not to compromise security, e.g., by using APOP instead of normal
   POP, when the server supports APOP.
   
-- The mailer should provide support for encryption (at least using PGP,
   but other formats as well, if possible). The support should be as
   comfortable as possible: most of the time the user should just be able
   to ignore it. E.g., the mailer should keep the PGP password in memory
   (for some specified time), instead of asking the user to re-type it
   all the time. Also, the mailer should have an option to always encrypt
   messages, if the receiver's PGP key is known (but this should be
   overrideable).
** I'm getting the impression Mr. Wirzenius is using an Emacs mailer
** himself. Now, I've been deploring pine's pgp-integration for some
** time, but I can see why it isn't done. It still sucks.   

Spam filtering
-- The mailer should support spam filtering, some way or another.
** We've had this up there somewhere, but the point is still valid.

Easy list subscription and unsubscription
-  People active on the Internet will need to subscribe and unsubscribe
   to mailing lists all the time, and the mailer should make this easy.
   For example, when subscribing, it should offer to create a new folder
   and a filtering rule to place everything from that mailing list to the
   new folder.
-  On the other hand, one stays subscribed to some lists for a very long
   time, and it is easy to lose the unsubscription messages during that
   time. The mailer should make it easy to remember how to unsubscribe.
   
Bounce processing
+- The mailer should be able to process most common types of bounce
   messages (and DSN messages), and track which messages have not reached
   their destination. It should make it easy to re-send (possibly after
   editing the addresses), and to mark the offending addresses as
   non-deliverable in the address database.
** while Pine handles bounces ok, it does not do the database
** stuff. Needless to say that Gnus does, I gues...
   
Priority alarms, and other biffy features
-- The mailer should be able to recognize (some) important messages, and
   raise an alarm when such a message arrives. The user must be able to
   configure what is considered important and what is not, using the
   filtering mechanism.
-- The mailer should also be able to recognize unimportant new messages,
   and not signal them in intrusive ways (for example, by not beeping
   when such mail arrives, even if it changes the icon to show there is
   new mail).
** Score files. Pine needs score files and kill files. Badly.

Footnotes: 
[1]  Here's what it looks like:
[ Gnus -- 2724 ]
  [ Privat -- 0 ]
*        0: nnml+robin:robin
  [ Mailing Lists -- 0 ]
    [Linux Mailing Lists -- 0 ]
*        0: Bonn LUG
	 0: Koeln LUG
	 0: Manchester LUG
  [ News -- 22 ]...

-- 
Robin S. Socha M.A.
Political Science Dept., Bonn University 
Customer: "I'm using Windows 95"          Tech Support: "Yes..."
Customer: "My computer isn't working now" Tech Support: "Yes, you said that"

---

From: Dean Gaudet <[email-masked]>
Date: Sun, 26 Oct 1997 05:22:40 -0800 (PST)

I read well over 300 messages a day with pine and a collection of scripts
just fine.  But I'm of the "vi" school of thought, meaning I am completely
content augmenting and expanding my system through a series of external
programs.  It would appear you're from the emacs school of thought.  So
this is a somewhat religious argument ... but anyhow.

It's also worth noting that I'm in a position where I can set up an
always connected server exactly as I like it.  I could do this with a
periodically connected server (or desktop) as well, it's not that much
different.

>    can be separate, and so that it is easier to do important lists first.

Use procmail filtering, or use subaddressing via qmail or procmail (I
choose the latter, it's far more reliable).

>    messages by subject and date is not good enough.

Huh?  It works fine for me.  "Proper threading" depends on mailer features
that not all mailers use -- so the messages just simply do not have the
data in them to be threaded.  I found when I wrote a threading mail to
news gateway that the threads (as seen by trn) were pretty useless and
pine's "ordered subject" sorting did a better job.

> ** as a vital point - except that Gnus' junk.el _really_ kicks ass.

^rform

>    the mail is actually processed at the same place.

Yep I need this too, so I added it.  See
<http://www.arctic.org/~dgaudet/patches/pine3.95dg3.patch>.

IMHO signatures are overrated... even if I didn't put this url here
you can probably derive my homepage from the From address.  So any
information I put into a signature is redundant.

>    Cc list.  When C replies to B's message, his mailer adds B. And so

Reply-To: for mailing lists has received a bad rap for reasons I can't
agree with.  In particular I think folks who accidentally send sensitive
private mail to the public Reply-To learn after one mistake.  If they
don't learn then they probably shouldn't be trusted with sensitive data
in the first place ;)  Pine deals with this excellently.

>    the receiver to process the mail anyway.

Ok I agree with you here.  Pine also has no way to override a display
filter.  For example I had a pgp display filter, however when PGP 5
came out and I hadn't had a chance to upgrade yet, and folks started
sending PGP 5 signed messages I could not read them at all... because
my display filter couldn't decode them.  I just ended up disabling the
filter until I could fix the situation.  It would have been nice to be
able to keep the filter but override it occasionally.

> ** Gnus message tree is 100x easier to scan than the kluge I had with

I have a very flat hierarchy, there is some depth, but it's mostly to
build a tree of archives.  All my incoming mail is automatically copied
to an archive of the appropriate inbox.  These archives are automatically
rotated and compressed (and marked read-only so that pine can deal with
them a lot more efficiently).

In my experience I'll dig through archives about twice a week, and
usually that's looking only at last week's mail which is easy to access.
This method allows me to completely avoid making the decision of what
I should keep -- I keep everything.  Then my inboxes essentially become
"todo" lists, and I rarely have to save messages elsewhere.

>    archive separately, and it must not apply to all saved messages.

$300 gets you at least 1Gb of high quality scsi disk.  gzip -9 helps
wonderfully.  I doubt any human is really reading enough mail to fill
1Gb of disk with compressed archives.  Why make the decisions?  You
never know when you'll want a particular message.  I've dug things out
a year and a half later, and thanked myself that I just keep everything.

> ** XEmacs -> Gnus -> igrep -> >KeWL<   

On small archives, maybe.  For something large the only solution is far
more complicated, and should involve technology like glimpse.  I
occasionally long for this, but it's only once a month or so that I
have to dig something out of long term compressed files.

> ** Running multiple copies of Pine is just not it, is it?   

Definately not.  In fact I can't stand pine's behaviour when you
accidentally start two of them.  There are many operations that I
used to perform in mh involving multiple message cross referencing
when generating a reply which I find a real chore in pine.  (Yes I
switched from mh to pine.)

>    to switch to another mailer.

I honestly believe that IMAP is the way of the future, and I consider
mailers without IMAP to be worthless.  For example, if your mail
environment involves NFS then you must not care about your mail -- because
NFS mail access is terribly unreliable.  The above is meaningless with
IMAP because you only care that your IMAP server is efficient -- you can
change the client without changing the files.  (qmail's Maildirs solve
NFS problems nicely, but are not a replacement for IMAP.)

>    POP, when the server supports APOP.

If you spend time looking at pine's code you'll probably conclude it
has buffer overruns, some of which may be remotely exploitable.
I'm not saying for certain there's an exploit, I'll just say it's
something that worries me.

>    messages, if the receiver's PGP key is known (but this should be

You can do this with any of the numerous pine+pgp wrappers and the display
filter and outgoing filter support.  The outgoing filters are trivial to
use, I just hit ^N or ^P to select one.  My filters do avoid re-asking
for the password, pine provides all the hooks necessary to only ask once.
(I use something called PAPP, use hotbot or something to find it.)

> ** We've had this up there somewhere, but the point is still valid.

procmail.

>    and a filtering rule to place everything from that mailing list to the

I have a script "majorsub" which does all the magic required to subscribe
me to a majordomo-style list, and set up the folder.  Because I use
subaddressing the "filter" is created implicitly and is never wrong.

It is impossible to get a traditional (header based) mail filter right
without seeing the first message from a mailing list.  Your mailer
can try to guess... but guessing is a bad scene in my books.  Software
shouldn't try to guess what's right.  Even if it were to show you the
filter and say "is this the filter I should use?"  you probably won't
know the answer until you've seen the first message.

>    time. The mailer should make it easy to remember how to unsubscribe.

The first archive folder for each mailing list necessarily contains this
message.

> ** stuff. Needless to say that Gnus does, I gues...

You get that many bounces that this is an issue?  I get maybe a bounce
a week, out of 250 messages I sent.

>    configure what is considered important and what is not, using the

Use procmail to trigger some external program... I generally let other
humans make the effort to tell me some other way when something is
really important.  If it's a machine that needs to tell me something is
important, it does it via pager.  i.e. you're not online 24 hours a day,
or at least you shouldn't be ;)  If it's important when you're logged
in then it's important when you're in the washroom, or out eating lunch,
so you better have an out-of-band signalling method ...

Dean

---

From: "Adam H. Kerman" <[email-masked]>
Date: Sun, 26 Oct 1997 10:39:13 -0600 (CST)

>From: "Robin S. Socha" <[email-masked]>
>Date: 26 Oct 1997 12:19:29 +0300

>** want when reading a hv-list.

Since fine tools for filtering exist, it's not something I would like to see
added to pine. I don't understand your comment about tabbing.

>   discussion, with replies being children of the message they are

This is a feature that should be added to pine. Please bear in mind, however,
that it won't result in proper threading, or an article tree. Linking an
In-Reply-To to a Message-ID will help a little. We can have proper threading
and an article tree in news, using trn for example, because many news messages
contain Message-IDs for all earlier messages in the thread, especially the
Message-ID that began the topic, to anchor the tree. Unfortunately, most
message composers fail to retain these necessary earlier Message-IDs.

Perhaps pine's behavior could be improved in this respect.

>   and so on, are essential.

Yes, it will be lovely when we can pick and choose which attachments to include
in reply, or if they are merely plain text, merely inserted into the body of
the reply text.

But, dammit, sending html-encoded messages is such an abuse of e-mail that I
would rather pine continue to fail to support this, in the hopes that other
products that generate this code for mail composing will wither and die.

>   the full name of the local user, if possible. This also prevents

Hm. Good suggestion.

>** We've had this up there somewhere, but the point is still valid.

No. Use other filtering tools which do the job well.

---

From: "Adam H. Kerman" <[email-masked]>
Date: Sun, 26 Oct 1997 10:55:59 -0600 (CST)

>From: Dean Gaudet <[email-masked]>
>Date: Sun, 26 Oct 1997 05:22:40 -0800 (PST)

>that not all mailers use--so the messages just simply do not have the

Did you convert In-Reply-To to Reference headers?

How can "ordered subject" sorting do a better job? In-Reply-To sorting, where
it is possible, should be the superior rule, then ordered subject.

As it happens, trn will give you a choice: It allows messages to be ordered by
date and subject, or, subthreads are arranged within the article tree in date
order, based on the date of the anchoring message.

There are 2 choices to read messages within the article tree, either read
subthread after subthread, or read each first generation reply, followed by
second generation replies.

Without all those earlier Message-IDs retained, it is impossible to have a
proper article or message tree. But, if In-Reply-To exists, there is no
advantage to ignoring it.

---

From: Dean Gaudet <[email-masked]>
Date: Sun, 26 Oct 1997 12:19:36 -0800 (PST)

> Did you convert In-Reply-To to Reference headers?

Yes, where they existed.

> it is possible, should be the superior rule, then ordered subject.

If In-Reply-To exists on all messages then I agree with you.  What's the
algorithm you'll use for those it doesn't exist on?

> advantage to ignoring it.

Note that a filter could be written which keeps a tree of message-ids in a
database based on in-reply-to, and from that generate a more complete
reference list.  But it's not perfect, mainly because in-reply-to isn't
always there... and because of that I find orderedsubject far more
reliable. 

Dean

---

From: Shoeless in San Jose <[email-masked]>
Date: Sun, 26 Oct 1997 20:09:22 -0800 (PST)

>    can be separate, and so that it is easier to do important lists first.

Yup.  If Pine can read separate folders, why can't it separate incoming
mail into those folders.  Seems to me it's only doing half the job right
now.

Along the idea of doing important lists first, I would like to ge able to
rearrange the folders so that the most important (or most active) could be
placed first, but it would be left up to the user as to which folder went
first, second, etc.  The way it is now, you have to delete folders and
recreate them in the new order.

>    presence or absence of a string in that header.

It should be as flexible as procmail if it's going to be done at all:
filtering on any header, or even on a keyword in the body of the message.

> -- The mailer must be able to show which folders have new messages, and

I fully agree with this one.  I do that now with a script at login, which
is also available any time I'm at the prompt, but I think it would be nice
to have the mail program show me this when I start it so I know where I
need to go to read mail, and which folders have a *lot* of mail that needs
to be taken care of.

One final word on filtering, though.  I'd like to see Pine include mail
filtering since there's obviously a lot of interest in filtering out spam,
separating mailing lists, etc., but it needs to be easy for the newbies to
get set up.  Otherwise, it's no better than installing a 'filter' script
or installing procmail. 

On the other hand, I'd hate to see Pine get to be like some of today's
programs. Some of them try to do everything but wash your dishes, and they
end up being worthless for every task, not to mention crashing because
they *are* trying to do it all.  I'd rather keep Pine a fairly simple,
straightforward mailing-reading program if adding lots of bells and
whistles like filtering will just slow it down or cause a lot of problems.

>    messages by subject and date is not good enough.

Sounds good, but I'd also like to be able to sort the mail in their
folders differently from how I sort the newsgroup.  The way it is now, I
have to run Pine with a different .pinerc file to do that when reading
newsgroups.

"Adam H. Kerman" <[email-masked]> writes:

> But, dammit, sending html-encoded messages is such an abuse of e-mail
> that I would rather pine continue to fail to support this, in the
> hopes that other products that generate this code for mail composing
> will wither and die.

I have to agree with Adam.  I'd like to see the html-encoded messages
disappear, but if they continue, then have Pine strip them off as an
option in the Setup / Config so we don't have to see them if we don't
want to.

> ** thread the same mailbox.

It takes *way* too long to have it sort a newly-subscribed-to newsgroup.
Fortunately, I don't get tons of e-mail so that's not a problem for me,
but I can imagine that it *is* for some.

>    contains "ANNOUNCE" or "IMPORTANT", or expire only messages that don't

There are too many people who write in complaining about running out
of disk space.  I think there should be a way to have Pine archive /
delete old mail.  It should be set up to check for any mail in any
folders that it older than a given time period.  This, like other
things, should be settable in the Setup / Config.

>    and a filtering rule to place everything from that mailing list to the

This *would* be a nice feature, but I think making the process of
creating a new folder should suffice.  If filtering is added to Pine
eventually, being able to add the new list to the filter *would* be a
good thing to have.  Then it could create a new folder automatically,
or prompt the user to choose from the existing ones.

>    time. The mailer should make it easy to remember how to unsubscribe.

This, too, would be a nice feature, but I think a simple *save* of the new
subscriber info. should be appropriate.  Besides, one can always mail to
the list and ask how to unsubscribe...someone out there can help them out.
I would, therefore, consider this another 'bell' or 'whistle' that I
personally could live without.

>    non-deliverable in the address database.

Again, filtering would help this.

>    configure what is considered important and what is not, using the

Excellent idea!

Overall, I like Pine, especially its range of user-settable features.  I
think that's the number one feature that makes me use Pine over any other
program.  If I want to be able to set something a certain way, I usually
can.  On the other hand, if I'm a clueless newbie who just wants to be
able to read mail, they can do that.  The settings are there and, when
they learn more about Pine (as I did from this mailing list), they can
adjust things to suit their tastes. 

I would like to see Pine have *some* sort of filtering available, again
with the option to use or not use it, and with the flexibility of procmail
or Eudora Pro's filtering.  However, I'd hate to see Pine get to be so
'busy' that it has more features (read problems) than are absolutely
necessary to keep it a simple, yet reliable mail tool.

Greg
[email-masked]

---

From: "Robin S. Socha" <[email-masked]>
Date: 27 Oct 1997 23:42:39 +0300

>> "DG" == Dean Gaudet <[email-masked]> writes:

DG> I read well over 300 messages a day with pine and a collection of
DG> scripts just fine.  But I'm of the "vi" school of thought, meaning
DG> I am completely content augmenting and expanding my system through
DG> a series of external programs.  It would appear you're from the
DG> emacs school of thought.  So this is a somewhat religious argument
DG> ... but anyhow.

No. I used to use pine. Until I started subscribing to high volume
mailing lists. And read news heavily. Then there was only one
alternative: Gnus.

DG> It's also worth noting that I'm in a position where I can set up
DG> an always connected server exactly as I like it.  I could do this
DG> with a periodically connected server (or desktop) as well, it's
DG> not that much different.

That's not the point. I do the same. Still, pine and slrn couldn't
handle the load. I'm still looking for a nice, fast cli mail
reader. Mutt is ok, but I like pine and would like to see it improve
to a point where I can use it without heavy procmailing and digestion
problems when the next 100 mails come in.

DG> On 26 Oct 1997, Robin S. Socha wrote:
>> Automatic filtering
>> -- When the e-mail comes via many lists, it is imperative that
>>    there is a way to automatically filter e-mail to different
>>    folders, so that lists can be separate, and so that it is
>>    easier to do important lists first.

DG> Use procmail filtering, or use subaddressing via qmail or procmail
DG> (I choose the latter, it's far more reliable).

As I said, that's out of the question for novice users, and too much
hassle for me. Check XFmail and see what I mean. Pegasus-style
filtering rules - >KeWL< for newbies.

>> Proper threading
>> - When viewing a long discussion, it helps understanding it
>>    immensely if the messages are shown in a logical order: a reply
>>    is shown immediately after the message it is a reply to. Merely
>>    sorting messages by subject and date is not good enough.
>> ** Amen

DG> Huh?  It works fine for me.  "Proper threading" depends on mailer
DG> features that not all mailers use -- so the messages just simply
DG> do not have the data in them to be threaded.  I found when I wrote
DG> a threading mail to news gateway that the threads (as seen by trn)
DG> were pretty useless and pine's "ordered subject" sorting did a
DG> better job.

Not in my experience. Ever tried mutt? I mean - order by subject is
kinda nice, but you loose all the subthreads - and you don't get
visualization of hierarchies. Not good.

>> ** Have I mentioned Gnus today, yet? However, I don't see form
>>    letters as a vital point - except that Gnus' junk.el _really_
>>    kicks ass.

DG> ^rform

Not really. Cannot be done context-sensitively. As so many things in
pine, this is a kluge. Works for some, but not for beginners - or
non-u*ixers. 

>> Different sender addresses, signatures, etc
DG> Yep I need this too, so I added it.  See
DG> <http://www.arctic.org/~dgaudet/patches/pine3.95dg3.patch>.

Fine - will it be included? Pine isn't gpl'ed. I know and respect the
reasons, but it's... not very satisfactory?

DG> IMHO signatures are overrated... even if I didn't put this url
DG> here you can probably derive my homepage from the From address.
DG> So any information I put into a signature is redundant.

Too much of a hassle. Gnus gives me clickable urls and mail
addresses, the latter being of importance in an age of braindead
lusers invalidating their own addresses. 

>>   Cc list.  When C replies to B's message, his mailer adds B. And so

DG> Reply-To: for mailing lists has received a bad rap for reasons I
DG> can't agree with.  In particular I think folks who accidentally
DG> send sensitive private mail to the public Reply-To learn after one
DG> mistake.  If they don't learn then they probably shouldn't be
DG> trusted with sensitive data in the first place ;) Pine deals with
DG> this excellently.

Yes, but it needn't be that way, right?  Besides, I like the
possibilty to use reply-to on a regular basis based on context - like
I'd never openly post to gnu.emacs.gnus...

>> -+ The mailer should do its utmost to show any content type,
>>    including binary stuff. If nothing else, the mailer should
>>    show the printable parts of an unknown binary type (perhaps at
>>    request). Many bad mailers will put a bogus content type, but
>>    a good mailer will allow the receiver to process the mail
>>    anyway.

DG> Ok I agree with you here.  Pine also has no way to override a
DG> display filter.  For example I had a pgp display filter, however
DG> when PGP 5 came out and I hadn't had a chance to upgrade yet, and
DG> folks started sending PGP 5 signed messages I could not read them
DG> at all... because my display filter couldn't decode them.  I just
DG> ended up disabling the filter until I could fix the situation.  It
DG> would have been nice to be able to keep the filter but override it
DG> occasionally.

That's one of pine weakest spots imvho. I had pgp5 running in no
time. I can snarf and finger pgp...

>>   many folders. There will be many.
DG> I have a very flat hierarchy, there is some depth, but it's mostly
DG> to build a tree of archives.  All my incoming mail is
DG> automatically copied to an archive of the appropriate inbox.
DG> These archives are automatically rotated and compressed (and
DG> marked read-only so that pine can deal with them a lot more
DG> efficiently).

And just how much time did it take you to create the scripts? I lost 2 
months' worth of mail when my prune script screwed up. Ok - it didn't, 
I did ,-) And why is such a mechanism not part of pine *nagnagnag*

DG> In my experience I'll dig through archives about twice a week, and
DG> usually that's looking only at last week's mail which is easy to
DG> access.  This method allows me to completely avoid making the
DG> decision of what I should keep -- I keep everything.  Then my
DG> inboxes essentially become "todo" lists, and I rarely have to save
DG> messages elsewhere.

Sorry, but that's not an argument. The list keeps getting "quota"
questions. A smarter archiving mechanism is badly needed. And deeper
hierarchies, too. I want to have *one* Archive and then mail/news, and 
then months, but also...

>>    archive separately, and it must not apply to all saved messages.
DG> $300 gets you at least 1Gb of high quality scsi disk.  gzip -9
DG> helps wonderfully.  I doubt any human is really reading enough
DG> mail to fill 1Gb of disk with compressed archives.  Why make the
DG> decisions?  You never know when you'll want a particular message.
DG> I've dug things out a year and a half later, and thanked myself
DG> that I just keep everything.

Not a valid argument. I got 9 GB here, but that's not the point. With
pine, this amount of mail simply cannot be handled. I ended up tweaking
Apache to eat gz's and converted everything with MHonArc, with webglimpse
as search engine. Flashy, but it sucked like hell...

>> Searching
>> -- The archives should be searchable: full text searches, and for
>>    certain authors, subjects, dates, and other such criteria. One
>>    often needs to refer to old correspondence, but finding it in
>>    even a modest archive will be difficult, regardless of how it is
>>    organized, unless there is some way to search it in addition to
>>    just browsing it.

DG> On small archives, maybe.  For something large the only solution is
DG> far more complicated, and should involve technology like glimpse.
DG> I occasionally long for this, but it's only once a month or so that
DG> I have to dig something out of long term compressed files.

Not prob. Hook that into XEmacs - a friend of mine already did, and I
will RSN. Very good results on this side of the ocean.

>> Many concurrent operations
DG> Definately not.  In fact I can't stand pine's behaviour when you
DG> accidentally start two of them.  There are many operations that I
DG> used to perform in mh involving multiple message cross referencing
DG> when generating a reply which I find a real chore in pine.  (Yes I
DG> switched from mh to pine.)

Hehehe...

[...]
>> -- The mailer should provide support for encryption (at least using
>>    PGP, but other formats as well, if possible). 
DG> You can do this with any of the numerous pine+pgp wrappers and the
DG> display filter and outgoing filter support.  The outgoing filters
DG> are trivial to use, I just hit ^N or ^P to select one.  My filters
DG> do avoid re-asking for the password, pine provides all the hooks
DG> necessary to only ask once.  (I use something called PAPP, use
DG> hotbot or something to find it.)

Aldo and I are good friends, but guess which mailer he now uses?  Besides,
his idea to store the password locally is utterly braindead. Ever seen
XEmacs' mailcrypt at work? Now, that's what I call comfort, and I cannot
(yes, I can...) see why pine shouldn't have this. Hey, guys at the pine
tower - come up with an export edition .-)

>> ** We've had this up there somewhere, but the point is still valid.
DG> procmail.

No. Definitly not. Not for Joe Random User, and definitly not for just 
filtering. There are cleaner solutions than procmail, and there are
easier ones.

>> - People active on the Internet will need to subscribe and
>>   unsubscribe to mailing lists all the time, and the mailer
>>   should make this easy.  For example, when subscribing, it
>>   should offer to create a new folder and a filtering rule to
>>   place everything from that mailing list to the new folder.
DG> I have a script "majorsub" which does all the magic required to
DG> subscribe me to a majordomo-style list, and set up the folder.
DG> Because I use subaddressing the "filter" is created implicitly and
DG> is never wrong.

Could everybody have it? How about a "good ideas that Really Work(tm)" 
page on the pine site?

[...]
>> -- The mailer should be able to recognize (some) important messages,
>>    and raise an alarm when such a message arrives. The user must be
>>    able to configure what is considered important and what is not,
>>    using the filtering mechanism.

DG> Use procmail to trigger some external program... I generally let
DG> other humans make the effort to tell me some other way when
DG> something is really important.  If it's a machine that needs to
DG> tell me something is important, it does it via pager.  i.e. you're
DG> not online 24 hours a day, or at least you shouldn't be ;) If it's
DG> important when you're logged in then it's important when you're in
DG> the washroom, or out eating lunch, so you better have an
DG> out-of-band signalling method ...

I have that, and it's ok, but I hate procmail. ;-) XEmacs has nice
biffy stuff like that, like a yellow envelope with a number beside
it. What more could you ask for?

DG> Dean
>> "AHK" == Adam H Kerman <[email-masked]> writes:
>> From: Dean Gaudet <[email-masked]> Date: Sun, 26
>> Oct 1997 05:22:40 -0800 (PST)

DG> Dean
>> "AHK" == Adam H Kerman <[email-masked]> writes:
>> From: "Robin S. Socha" <[email-masked]> Date: 26
>> Oct 1997 12:19:29 +0300

>> Automatic filtering
>> ** procmail is ok, but not available on some systems. XFmail's stuff is
>>    a good example how to make filtering user-friendly.  I would have
>>    added a couple more minuses if I had the place. Pine's behaviour
>>    here is totally braindead - and tabbing is *not* what I want when
>>    reading a hv-list.
AHK> Since fine tools for filtering exist, it's not something I would
AHK> like to see added to pine. I don't understand your comment about
AHK> tabbing.

I don't like to jump around blindly amidst 200 or so messages, when it 
might take a minute to open a folder. Gnus gives me the opportunity to 
fetch just the headers if needed, and that's really fast.

>> Good MIME support 
AHK> Yes, it will be lovely when we can pick and choose which
AHK> attachments to include in reply, or if they are merely plain
AHK> text, merely inserted into the body of the reply text.

Yup. Is it coming?

AHK> But, dammit, sending html-encoded messages is such an abuse of
AHK> e-mail that I would rather pine continue to fail to support this,
AHK> in the hopes that other products that generate this code for mail
AHK> composing will wither and die.

Only over my dead body.

>> the full name of the local user, if possible. This also prevents
AHK> Hm. Good suggestion.

>> "SiSJ" == Shoeless in San Jose <[email-masked]> writes:

>> Automatic filtering
SiSJ> Along the idea of doing important lists first, I would like to
SiSJ> ge able to rearrange the folders so that the most important (or
SiSJ> most active) could be placed first, but it would be left up to
SiSJ> the user as to which folder went first, second, etc.  The way it
SiSJ> is now, you have to delete folders and recreate them in the new
SiSJ> order.

Even better: Gnus' adaptive scoring. It remembers which folders you
enter most and arranges them for you. Perfect.

>> -- Filtering does not have to be based only on the list, so the
>>    criteria should be flexible enough to allow other sorts of
>>    filtering as well.  At least, one should be able to filter
>>    based on any header and the presence or absence of a string in
>>    that header.
SiSJ> It should be as flexible as procmail if it's going to be done at
SiSJ> all: filtering on any header, or even on a keyword in the body
SiSJ> of the message.

That's not procmail's domain. Overkill. You can use elm's filter for
such primitive tasks. 

>> -- The mailer must be able to show which folders have new messages,
>>    and preferably how many.
SiSJ> I fully agree with this one.  I do that now with a script at
SiSJ> login, which is also available any time I'm at the prompt, but I
SiSJ> think it would be nice to have the mail program show me this
SiSJ> when I start it so I know where I need to go to read mail, and
SiSJ> which folders have a *lot* of mail that needs to be taken care
SiSJ> of.

Another one for a page on the pine site, right? Alternately, I'd
volunteer to collect this stuff (Sven, would you?) and put all the
links on my server. I feel this would be a Good Thing to have. Also,
I'd like to put "good" pinercs there.

SiSJ> On the other hand, I'd hate to see Pine get to be like some of
SiSJ> today's programs. Some of them try to do everything but wash your
SiSJ> dishes, and they end up being worthless for every task, not to
SiSJ> mention crashing because they *are* trying to do it all.  I'd
SiSJ> rather keep Pine a fairly simple, straightforward mailing-reading
SiSJ> program if adding lots of bells and whistles like filtering will
SiSJ> just slow it down or cause a lot of problems.

But XEmacs *is* simple. It's kinda big, allright, but it's simple and
customizable. Hey, this is not MS-Country, you know? ;-)

>> Proper threading
>> - When viewing a long discussion, it helps understanding it
>>    immensely if the messages are shown in a logical order: a reply
>>    is shown immediately after the message it is a reply to. Merely
>>    sorting messages by subject and date is not good enough.
SiSJ> Sounds good, but I'd also like to be able to sort the mail in
SiSJ> their folders differently from how I sort the newsgroup.  The
SiSJ> way it is now, I have to run Pine with a different .pinerc file
SiSJ> to do that when reading newsgroups.

Kluge -> Bad Thing.

SiSJ> "Adam H. Kerman" <[email-masked]> writes:

SiSJ> Overall, I like Pine, especially its range of user-settable
SiSJ> features.  I think that's the number one feature that makes me
SiSJ> use Pine over any other program.  If I want to be able to set
SiSJ> something a certain way, I usually can.  On the other hand, if
SiSJ> I'm a clueless newbie who just wants to be able to read mail,
SiSJ> they can do that.  The settings are there and, when they learn
SiSJ> more about Pine (as I did from this mailing list), they can
SiSJ> adjust things to suit their tastes.

I see it just the other way around. Why not have a "I'm scared, give
me interactive help" and a "I'm a u*ix God, gimme all NOW" button? I
hated sitting there re-configuring pine after I lost one pinerc.

SiSJ> I would like to see Pine have *some* sort of filtering available,
SiSJ> again with the option to use or not use it, and with the flexibility
SiSJ> of procmail or Eudora Pro's filtering.  However, I'd hate to see
SiSJ> Pine get to be so 'busy' that it has more features (read problems)
SiSJ> than are absolutely necessary to keep it a simple, yet reliable mail
SiSJ> tool.

Again, mutt, XFmail and Gnus handle this stuff well, without being
slower than pine AFAICS.

BTW, did you guys have a hard time quoting this mail? Pico must die
RSN... ]:-> Hehehe...

Cheers,
Robin

-- 
Robin S. Socha M.A.
Political Science Dept., Bonn University 
GMC d++ s+: a- C++ UL++ P++$>+++$ L++$>+++$ E+++ W-- N++ w--- O- M--
V-- PS--- PE+++ Y+ PGP++ t++ 5-- X-- tv++ b+++ DI++ D+ g e++ h r++ y+

---

From: Dean Gaudet <[email-masked]>
Date: Tue, 28 Oct 1997 12:44:25 -0800 (PST)

> recreate them in the new order.

quit pine, and type "pico .pinerc".  You'll find the list of folders in
there, quite easy to edit and order however you like.  My folders are
prioritized this way.

> things, should be settable in the Setup / Config.

This is what crontab and shell scripts do quite well.

> personally could live without.

Ha ha, mail to the list to ask to be unsubscribed?  Do you realise how
rude/annoying that is to 99% of mailing list readers?  You got the message
when you subscribed, save it to a folder called "unsub" and keep that
folder forever. 

Dean

---

From: Dean Gaudet <[email-masked]>
Date: Tue, 28 Oct 1997 13:28:08 -0800 (PST)

> problems when the next 100 mails come in.

Try subaddressing.  Filtering is a pain in the butt, I used to do it.
I used to have a 1000 line procmailrc.  Then I switched to qmail as my
MTA and started using subaddressing heavily.  I'm not even using procmail
at the moment.  (You can do subaddressing with sendmail+procmail by
enabling procmail as the local delivery agent... but I didn't find it
as nice to use.)

I have no problem when 100 mails come in.  They'll come in on my lower
priority folders typically.  Unless it's a whack of cron jobs finishing
around the same time.  But I can easily avoid the busy folders when I
need to.

> filtering rules - >KeWL< for newbies.

How many newbies need to handle 500 messages per day?

> pine, this is a kluge. Works for some, but not for beginners - or

Oh fine then, hit |form and write a script called form which does the
context sensitive crap.

> reasons, but it's... not very satisfactory?

I don't understand what you're asking.  Will that patch be included in
pine?  No, I doubt it.  It uses a qmail feature to set the envelope from,
because I couldn't be bothered to do it in a way that works with sendmail.
But isn't this the point of having the source code?

Furthermore, GPL is not a holy grail that all software must meet.
I'm one of the Apache devlopers.  Apache is not GPL'd.  GPL has various
limitations that can actually hinder its use; or hinder the involvement
of some developers.  Apache is available under a variant of the Berkeley
license.

> lusers invalidating their own addresses. 

It doesn't matter to me if folks have to construct my web page address,
or if they have to construct my email address.  It takes some basic
skills, but those are skills that I haven't seen anyone not pick up
in 10 seconds.

> I'd never openly post to gnu.emacs.gnus...

Pine is missing per-folder configuration.

> time. I can snarf and finger pgp...

Uh, it's not pine's fault that I didn't have pgp5 going.  It's my fault
for not installing pgp5.  The only thing pine didn't do right was allow
me to override my broken filter without completely disabling it.

> I did ,-) And why is such a mechanism not part of pine *nagnagnag*

What prune script?  I never delete anything in the archives.  My scripts
amount to:

    date="`date +\%Y\%m\%d`"
    cd $HOME/mail/archive
    for folder in *; do
	if [ -f $folder/$date ]; then
	    echo "$folder/$date already exists!"
	elif [ -f $folder/current ]; then
	    mv $folder/current $folder/$date && chmod 400 $folder/$date
	fi
    done

And then two days later:

    find $HOME/mail/archive -name '[0-9]*[0-9]' -mtime +14 -print0 \
	| xargs -0r gzip -9

Nothing is deleted.  

> hierarchies, too. I want to have *one* Archive and then mail/news, and 

What's not an argument?  I never have to make the decision of what to
keep.  It's all kept.  I'm saying that the problem you presented just
doesn't exist for me.

> as search engine. Flashy, but it sucked like hell...

Yes, this sucks like hell.  You're not managing your data well -- if you
break things up into individual messages you'll blow one of many limits
on your filesystem (inodes, or just simply the directory scan time).
This is why news spools are going to cyclic files instead of the hierarchy
they've been for the past 15+ years.

> will RSN. Very good results on this side of the ocean.

If you're willing to split things into individual files and suffer the
performance/resource overhead of doing that then glimpse is trivial
yes.

> Could everybody have it? How about a "good ideas that Really Work(tm)" 

Sure, it's attached.  I release it into the public domain.  But it
requires qmail subaddressing.

> fetch just the headers if needed, and that's really fast.

Oh try pine via IMAP with the server running on an efficient mail
format ... headers only.  It works OK over slow serial lines too
(although I tunnel it via ssh with compression).

> hated sitting there re-configuring pine after I lost one pinerc.

One of pine's best features in my opinion is that it scales from the
newbie up to the expert.  The newbie doesn't even need to read anything
before using it -- it's the mailer I always set up newbies with.

> BTW, did you guys have a hard time quoting this mail? Pico must die

I've never had pico flake out on me.  I'm using vi at the moment however,
which I usually do when I need to actually edit.  pico is great for quick
answers.  Anything more than a half-dozen lines and I hit ^_. 

My number one feature request for pine is IMAP 4 disconnected support.  A
lot of the things you're arguing to be put into pine are things that I
would always do on the server -- because I access mail from three
locations IMAP is important to me.  I'd have to ensure all the three pine
configs agreed on filtering settings; which I know is possible, but I find
it easier to let other things running on the server itself take care of
the filtering.

Dean
#!/bin/sh

listname=$1
major=$2

if [ -z "$listname" -o -z "$major" ]; then
    echo "usage: $0 listname majordomo@host"
    exit 1;
fi

cd $HOME

mkdir $HOME/mail/arc/$listname

cat >.qmail-list-$listname <<EOF
./mail/lists/$listname
./mail/arc/$listname/current
EOF

/var/qmail/bin/qmail-inject -f [email-masked] $major <<EOF
From: [email-masked]
To: $major

subscribe $listname
EOF

---

From: "Robin S. Socha" <[email-masked]>
Date: 29 Oct 1997 01:38:34 +0100

>> Regarding Re: FYI: L. Wirzenius's "much mail" page; Dean Gaudet
>> <[email-masked]> adds: 
DG> On Sun, 26 Oct 1997, Shoeless in San Jose wrote:

Preface: I put Lars' stuff to discussion under the impression that
pine was to be used by "the average user"... ;-)

DG> On Sun, 26 Oct 1997, Shoeless in San Jose wrote:
[important lists]
DG> quit pine, and type "pico .pinerc".  You'll find the list of
DG> folders in there, quite easy to edit and order however you like.
DG> My folders are prioritized this way.

Mine were, too, but that's not "user friendly". (see preface)

[archiving]
DG> This is what crontab and shell scripts do quite well.

If the sysop sets pine up this way, yes.

[...]
>> Dean Gaudet writes:

DG> On 27 Oct 1997, Robin S. Socha wrote:
[handling large amounts of mail]
DG> Try subaddressing.  Filtering is a pain in the butt, I used to do
DG> it.  I used to have a 1000 line procmailrc.

Same here. Modularized. Refined. Goldlisted. Not handlable.

DG> Then I switched to qmail as my MTA and started using subaddressing
DG> heavily.  I'm not even using procmail at the moment.  (You can do
DG> subaddressing with sendmail+procmail by enabling procmail as the
DG> local delivery agent... but I didn't find it as nice to use.)

Yup. But that's not an end-user thing, is it?

DG> I have no problem when 100 mails come in.  They'll come in on my
DG> lower priority folders typically.  Unless it's a whack of cron
DG> jobs finishing around the same time.  But I can easily avoid the
DG> busy folders when I need to.

Sure, but that's not the point - unless (HELLO, FELLOW POSTMASTERS) we
want to talk "how to make pine more usable for the end-user". That's
what this list is supposed to be here for, lately. Anyone wanna join?

>> As I said, that's out of the question for novice users, and too
>> much hassle for me. Check XFmail and see what I mean. Pegasus-style
DG> How many newbies need to handle 500 messages per day?

Not many, good point. But what about, say, 50? That's the err... crucial
(?) amount of mail, when pine starts to be no longer usable. YMMV.

DG> ^rform
>> Not really. Cannot be done context-sensitively. As so many things
>> in pine, this is a kluge. Works for some, but not for beginners -
>> or non-u*ixers.
DG> Oh fine then, hit |form and write a script called form which does
DG> the context sensitive crap.

;-) Sure. You want to set that up for my 14 users? And explain it to
them?

>> Fine - will it be included? Pine isn't gpl'ed. I know and respect
>> the reasons, but it's... not very satisfactory?
DG> I don't understand what you're asking.  Will that patch be
DG> included in pine?  No, I doubt it.  It uses a qmail feature to
DG> set the envelope from, because I couldn't be bothered to do it
DG> in a way that works with sendmail.  But isn't this the point of
DG> having the source code?

I think it is. Can I use the modified source in a commercial
environment?  What if the UoW decides to change their licence?  This
is purely hypothetical, and I'm not imposing they would, but that's a
"business" decision - if you spent a lot of time (=money) to set up a
site "for pine".

DG> Furthermore, GPL is not a holy grail that all software must meet.
DG> I'm one of the Apache devlopers.  Apache is not GPL'd.  GPL has
DG> various limitations that can actually hinder its use; or hinder
DG> the involvement of some developers.  Apache is available under a
DG> variant of the Berkeley license.

Which is different from the pine licence. Correct me if I'm wrong, but 
I may distribute modified versions of Apache, may I not? Anyway,
that's not the point (my point, that is) here. As I see it (and I
don't subscribe to RSM's communists drivel), the GPL and similarly
oriented licences promote the development of software. IMHO, the pine
licence does it not in the same way. But that, again, is not the point 
here. Let's bury the licence discussion, shall we?

[sigs and clickable urls]
DG> It doesn't matter to me if folks have to construct my web page
DG> address, or if they have to construct my email address.  It takes
DG> some basic skills, but those are skills that I haven't seen anyone
DG> not pick up in 10 seconds.

It's still hostile towards people who want to help on the internet. We've
had this very same discussion here when Good Ole Bruce was desperately
trying to understand sendmail so that he could forge his address. Sure I
can disassemble a "nospam" address - but do I want to. Ultimately, the
decision lies with the poster, but I will not condone this behaviour, nor
will I encourage it by being polite or helpful. The point I was trying 
to make, though, was that pine could be a lot more user-friendly if it 
treated correct sigs in a sensible manner.
[...]
[archiving]
DG> What's not an argument?  I never have to make the decision of what
DG> to keep.  It's all kept.  I'm saying that the problem you
DG> presented just doesn't exist for me.

That's *your* presonal view. The point *I* was trying to make was
that Gnus' expiry mechanism is something pine should have. I don't
expect an on-and-off user to understand archiving. If I tell her that
all mail that isn't archived will be deleted after 2 weeks, she'll
understand.

[...]
>> BTW, did you guys have a hard time quoting this mail? Pico must die
DG> I've never had pico flake out on me.  I'm using vi at the moment
DG> however, which I usually do when I need to actually edit.  pico is
DG> great for quick answers.  Anything more than a half-dozen lines
DG> and I hit ^_.

Exquise me - but what's the advantage of pico over vi? It's not faster,
and that's about the only thing I could ever think of if I were to say
something positive about pico. You simply *cannot* yank the quotes I use
properly with pico. Mine and some less fancy ones. I remember clearly
cursing heavily when several people on one list I subscribed to as a
newbie were using supercite. Pine needs a better editor, that's all I'm
saying. I don't expect bells and whistles (actually, I quite like the
way quotes from different posters get different colours here), but
pine's editor should provide more in the yanking area than it
currently does.

DG> My number one feature request for pine is IMAP 4 disconnected support.
DG> A lot of the things you're arguing to be put into pine are things that
DG> I would always do on the server -- because I access mail from three
DG> locations IMAP is important to me.  I'd have to ensure all the three
DG> pine configs agreed on filtering settings; which I know is possible,
DG> but I find it easier to let other things running on the server itself
DG> take care of the filtering.

Yup. Who else does? ;-)

Cheers,
Robin

-- 
Robin S. Socha M.A.
Political Science Dept., Bonn University 
main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}