On Wed, 14 Feb 2007, Joel Reicher wrote:
So then, I modified my delivery agent (procmail in this case) to deliver
to ~/.mail.
My understanding is that the nature of a file is really only determined by
the applications that access it. What makes the "system" mailboxes tricky
is that applications like sendmail are relatively unsophisticated MDAs
(when they're expected to do this job), and perhaps don't share the file
with MUAs very well. It is also that sendmail might be doing the delivery
which causes these to be regarded as "system" mailboxes, but really
there's nothing inherently "system" about them.
Except that their format is more forced by the MTA, in some cases. I am
NOT quite sure I am ready to force everyone through a format change (it
would likely require customizing procmail so that new behaviors emulated
old behaviors based on the same config. (I don't relish the idea of
hand-scanning 400 .procmailrc files).
Now, as I become more familiar with IMAP and whatnot, I'm beginning to be
of the realization that apparently your mail spool is only supposed to be
a "take things out on first sight" type of thing, which should be done
automatically by imapd if you have a special file called INBOX.
(http://www.faisal.com/docs/mbx.html)
This breaks any familiarity I would have with things like using procmail
to deliver to ten different folders (since after all, what would be the
difference, they're *all* inbound folders that will be delivered to).
All of this comes down to having healthy interaction between your MUA
and MDA. The simplest way to achieve it is to simplify your MUA's access
to the file(s) that your MDA write(s) to, and AFAICT the simplest access
is "read-and-remove".
If you have sufficiently friendly MDAs and MUAs, as is (probably) the case
with procmail and pine, you don't have to do things that way.
"don't have to" does not mean "should not". There's a twinging annoyance
that what I've been doing is a recipe for disaster in the event something
bad happens. (In fact, on reboot, I corrupted a mailbox, which is the
subject of my other ongoing thread that you answered, basically the
mailbox "swelled" for some reason I can't understand, I suspect a garbage
message in the middle -- it splits down to a maildir fine, but as soon as
I recombine it to a single unix mailbox, it fails to open again because
it's still too big).
I've been a pine whore for years, but it's been my understanding that pine
should also work that way in theory -- but for me it's not. When I move
things out of my .mail folder, they're "off the radar". Given, this is my
personal flow of work, but since pine only showed one folder at a time, I
wanted to be able to work within a reasonable timeframe (say, three
months) all without having to wait for pine to chunka-chunka-chunka
another folder open.
Sorry, I didn't really follow that so I can't comment.
Meaning my current .mail file is 8000 messages big, which is the timeframe
back to about mid-november, and the average volume of messages I need to
be able to access and search quickly, search for things that are flagged
important, etc. Once I move those messages to "saved-messages" they are
literally "no longer on the radar". Dropping anything and looking to more
"historical" folders requires opening them. Pine takes time to do this,
time to search those folders, time to close them and redisplay INBOX
(which in MY case is my .mail file, but as I understand it, POSSIBLY
should not be, instead with INBOX being a place files are auto-moved to
FROM .mail (i.e. they'd be similar but not the same thing)).
This is PROBABLY bad in my mind.
My workflow patterns are not going to change. To apply a real life
analogy, I actually have a physical PO Box -- there are days where I will
see that I have a package (my post office tells me this with a yellow
slip). I look at the line for the pickup window, and place the yellow
slip back in the box to read another day, even though in theory the USPS
PO box is also "remove on access". So in short, I may not feel like
dealing with the attachment at that exact time, so I flag the message as
"new". In the same analogy, I do all my mail sorting while *at* the post
office. Anything I don't want is thrown away before it ever makes it to
my car. Anything relating to business is saved, indefinitely (in my home
analogy, that means scanned -- in the pine, that means eventually moved to
saved-messages once it's old enough).
So, based on the above, is what I've been doing all these years "Wrong" by
the usual standards?
"Wrong"? What's "wrong"? You don't want to lose mail, obviously; beyond
that anything which enables you to work quickly and effectively is
probably the best.
Meaning should I not be doing routine operations on the system INBOX, and
should I be making EVERY effort to read-and-remove (and just have pine
moving the messages in the background before I see them)? If so, what's
the setting in pine to do so, and how do I cause the SAME behavior for my
IMAP users (it's assumed that pop3 users will already be doing this).
I ask all this in possible preparation for switching to a new mail format.
Most of my users are pop3 and imap types, and a lot of them complain about
the slow speed of squirrelmail (which seems to not work nicely with imapd
anyway (for which there are a multitude of alleged symptoms ranging from
the sorting to the locking to the format --
http://www.squirrelmail.org/wiki/SpeedWithUW)
Squirrelmail does not access any folders directly, so it should not
be a factor in your choice of a file format.
Yes it should. Squirrelmail is an IMAP client. Aparently there are
issues there with UW's imap (I don't have any, but the SQ people find them
-- I am NOT planning on switching and LIKE having all my mail software "in
sync", which I will not have if I go any other route. Anyway, the Evil
Squirrel People have blamed everything from mailbox size, to the lack of a
SORT function, to the stateless nature of HTTP versus imap (get a proxy,
they say), right down to the volume of files in a mailbox, and then they
blame the FORMAT of the mailbox. Hence the link I pasted:
http://www.squirrelmail.org/wiki/SpeedWithUW
For your pop3 and imap users, pick pop3 and imap servers that work well,
and the file format for remote folders will be both a consideration and
a consequence of this decision.
The format of local folders can be different, however. It depends on the
MUA (and what MDA you may want delivering directly to them).
If folders are being used both remotely and locally, you have to choose
a format correspondingly, and my understanding is that this is one of
the design goals of c-client's "native" formats.
Sorry all that is so general, but I hope it helps.
It does, somewhat? I understand the goals of having Native formats, but
at the same exact time, my question wasn't a format one so much as this:
is it WRONG to actually save messages back TO your .mbox file once you
realize you still need them (presumably having deleted them).
Pine (again, we're talking about pine on an imap list and I apologize) has
an option that I believe is along the lines of "automatically move
messages to saved-messages when they're read" but no run-time option
to do the same for system-inbox to pine-inbox (except that it's
apparently the default and you have to disable the MBOX driver if
you don't want it)...and the only thing I find on a quick google search is
http://www.washington.edu/pine/getpine/mbox.html and
http://www.math.washington.edu/~chappa/pine/pine-info/build/
The latter says that if I have an MBX format INBOX in my home directory,
files will be auto-moved, but they are not being.
However, all that is generally beside the point of this, since my question
wasn't about pine, per se OR about imap -- it was as to whether I should
be using my "system" (your quotes not mine) "system" mailbox interactively
instead of just as a drop-box.
Apologies if I get long here.
-Dan
--
"You recreate the stars in the sky with cows?"
-Furrball, March 7 2005, on Katamari Damacy
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
