<<< Date Index >>>     <<< Thread Index >>>

Re: domain-name based mailboxes (OT question about terminology)



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday, March 10 at 11:58 AM, quoth Paul E Condon:
> So is it correct to say that the difference between a 'folder' and a 
> 'mailbox' is that a mailbox is a folder that is checked on occasion 
> for the arrival of new mail?

Unfortunately, its not so simple, because these terms are sometimes 
used interchangeably, and are used differently in different contexts 
(for example, "folder" is sometimes used as a synonym for "directory" 
when discussing things that relate to filesystems).

In the context of mutt's configuration, THE $folder value is a 
convenient way to shorten how much you have to type to access your 
folders. *A* folder (as in "folder-hook" or "change folder") is a 
generic way of referring to any place you store email. It could be 
more specifically termed "URI-hook", but "folder-hook" is good enough 
and somewhat more intuitive. The term "mailbox" is often used as a 
synonym for this latter definition "folder", but when being rigorous, 
given that the command `mailboxes` tells mutt to check specific 
locations for email, it seems to me that "mailbox" ought to be 
reserved for just folders/URIs that are checked for email regularly.

Mutt's documentation is *rife* with abuse of the terms "folder" and 
"mailbox" such that anyone attempting to learn how email works based 
on mutt's documentation is destined for confusion. That's generally 
because mutt's documentation was written by lots of different people 
with not much in the way of guidelines who were all trying to be brief 
rather than precise. It makes sense only if you already know (more or 
less) what mutt's doing.

Just as an example, here's the muttrc man page's description of the 
$folder setting:

     folder
         Type: path
         Default: "~/Mail"

         Specifies the default location of your mailboxes. A "+" or "="
         at the beginning of a pathname will be expanded to the value
         of this variable. Note that if you change this variable (from
         the default) value you need to make sure that the assignment
         occurs BEFORE you use "+" or "=" for any other variables since
         expansion takes place when handling the "mailboxes" command.

Isn't that just awful prose? The last sentence barely makes sense, and 
it uses the term "mailboxes" in a way that only serves to confuse. 
Here's what it SHOULD say, if we're being more rigorous about our 
vocabulary:

     folder
         Type: path
         Default: "~/Mail"

         Used as a shortcut for a frequently-used path prefix. Much
         like "~" expands to the value of $HOME when used at the
         beginning of a path, "+" or "=" expand to the value of $folder
         when used in the same way. Be aware that the expansion happens
         when the prefix is interpreted, so set the value of $folder
         before using the shortcut (e.g. with the "mailboxes" command).
         Also keep in mind that the expansion only occurs when mutt is
         expecting a path, not when handling arbitrary strings.

See what I mean?

Here's another example from the muttrc man page:

     folder-hook [!]regexp command
         When mutt enters a folder which matches regexp (or, when
         regexp is preceded by an exclamation mark, does not match
         regexp), the given command is executed.

         When several folder-hooks match a given mail folder, they are
         executed in the order given in the configuration file.

This seems clear enough, until someone asks "My mail is stored in 
Maildir format; why doesn't a regexp '*/new' match all new and unread 
messages?" Note that the question presumes that *folder* is used in 
the sense of "filesystem directory" rather than the URI sense, but 
given that the documentation isn't clear which sense of the word 
"folder" is being used, it's a perfectly legitimate confusion. Now 
imagine someone added a "cd" command to mutt to allow mutt to change 
its current path! This has been discussed on the mutt-dev mailing 
list. If that were implemented, suddenly this documentation would be 
*extremely* confusing. Does a folder-hook trigger after a :cd command   
is executed? By the documentation, you would think so! A better way of 
writing that entry would be:

     folder-hook [!]regexp command
         Just before mutt views a mail URI which matches regexp (or,
         when regexp is preceded by an exclamation mark, does NOT match
         regexp), the given command is executed.

         When several folder-hooks match the URI being viewed, they are
         executed in the order they were defined.

Unfortunately, by trying to be precise, it begins to sound awkward.

Or how about this one:

     mbox-hook [!]pattern mailbox
         When mutt changes to a mail folder which matches pattern,
         mailbox will be used as the "mbox" folder, i.e., read messages
         will be moved to that folder when the mail folder is left.

         The first matching mbox-hook applies.

Note that "mailbox" and "mail folder" and "folder" are all used 
interchangeably! Why? I have no idea. But if we get pedantic, things 
begin to get even more awkward:

     mbox-hook [!]pattern mailURI
         When mutt views a mail URI which matches pattern, the
         specified mailURI will be used as the $mbox setting, i.e.,
         read messages will be moved to that URI when mutt either quits
         or views a different mail URI.

         The first matching mbox-hook applies.

See what I mean? First we've got the confusion about terms for 
"folders/mailboxes/URIs", which could be filesystem directories, URIs 
that specify a canonical name for a location that stores email, or 
URIs that specify a canonical name for a location that stores email 
that is checked periodically for new messages. And then there's the 
potential confusion over what "entering" and "leaving" means. For 
example, when you go to attach a file to a message you're sending, and 
you cause mutt to bring up the "browser" interface, are you "viewing" 
those "folders"? Are you "entering" them? Why are these terms the same 
ones we use for when we're reading email and "viewing" email 
"folders"? It's an ugly mess of confusion.

And then, of course, we have the `mailboxes` command, which is used to 
specify a list of mail URIs to periodically check for new messages. 
This command (unfortunately) thereby reserves the term "mailbox" to 
refer only to URIs that are being monitored, which is unfortunate. It 
would be clearer if the command were renamed `monitor`, because then 
not only would the purpose of the command be obvious, but we could 
then re-use the term "mailbox" as a less-awkward synonym of "mail 
URI". Consider the difference in clarity:

     mailboxes filename [ filename ... ]
     unmailboxes [ * | filename ... ]

         The mailboxes specifies folders which can receive mail and
         which will be checked for new messages. When changing folders,
         pressing space will cycle through folders with new mail. The
         unmailboxes command is used to remove a file name from the
         list of folders which can receive mail. If "*" is specified as
         the file name, the list is emptied.

...versus:

     monitor mailbox [ mailbox ... ]
     unmonitor [ * | mailbox ... ]

         The monitor command specifies mailboxes that will be checked
         periodically for new messages. After triggering the
         <change-folder> command, pressing space will cycle through the 
         set of mailboxes with new messages. The unmonitor command is
         used to remove a mailbox from the list of mailboxes being
         monitored. If "*" is specified, the list is emptied.

You can tell that the original language was written once upon a time 
when the only type of email storage that mutt understood was 
mbox-formatted files ("filename"?!? HA!). These days it only serves to 
confuse.

Of course, this confusion doesn't help when someone (like the OP) asks 
a question and intends to use a term (like "mailboxes") in a specific 
sense, but doesn't give a clear indication of what that sense is.

Consider: what did the OP mean by "mailbox"? What does it mean to "set 
up" a mailbox, and which of the possible interpretations of that word 
makes sense in that context? Really, the only possible definition of 
the word that is *set up* (i.e. "defined" in advance of using it) is 
the sense based on using the `mailboxes` command, so presumably that's 
what the OP meant. But... the OP's question doesn't make sense when we 
think about it that way since, as I said in my reply to him, a mailbox 
(used in the URI-that-is-checked-periodically sense) is defined by the 
URI, which contains both the username (UID) and the server (domain). 
So how should we interpret his question? The only way that the 
question *does* make some sense (to me) is if he's setting up 
mailboxes for *delivery*, e.g. via an MTA or via procmail. Perhaps he 
thinks that mutt behaves like procmail when it fetches mail and that 
it filters messages into folders? That's a common misconception among 
people who have never used mutt before. But he also seems to indicate 
that he knows something about mutt's limitations, since he makes 
reference to some "normal" way that these mailboxes are set up... 
which doesn't make any sense either. Do you see what I mean?

Perhaps I should have just rudely referred him to a "how to ask good 
questions on a mailing list" webpage. But I'm hoping that the way I 
did respond is more useful for him.

~Kyle
- -- 
To invent, you need a good imagination and a pile of junk.
                                                    -- Thomas Jefferson
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iEYEARECAAYFAkm2vg4ACgkQBkIOoMqOI15ABQCgjR7y1ZZ5E3Zvbuk+PyABiLgv
OlsAnAw2pmLZQyAdqSHdqqxs6VThk0Mw
=pOjQ
-----END PGP SIGNATURE-----