Re: another silly question
On 2005-05-08 11:14:41 -0400, Derek Martin wrote:
> Even if I agree with you (which I do, as it happens), as I've already
> said several times, /YOU/ DON'T GET TO DECIDE HOW OTHERS USE MAIL.
You didn't provide an explanation.
> An example of where this is somewhat practical is where someone from
> each shift is designated to monitor a particular e-mail account. All
> the other workers on that shift have no reason to care about that
> e-mail.
OK. Now on this example, I don't think that Mutt's *default* mailbox
format would change anything. You should use the right tool instead.
Mutt definitely isn't (to create the mailbox). Indeed, if the mailbox
creator chose a different mailbox format in his Mutt configuration,
then the common mailbox would be in the wrong format!
> > mail(x) doesn't understand MIME either. Non-English messages will be
> > very difficult to read, if not impossible. Some users with stupid MUA
> > even encode all their messages (even English ones) in base64; mail(x)
> > won't help there.
>
> So what? Around 90% of the mail I read is plain-text ASCII-encoded
> English. Mailx works fine for me most of the time. When it doesn't,
> I probably don't really care about the content I can't see anyway.
Perhaps for you, but not for many people.
> > There are both problems. Mailbox corruptions (in fact this was due to
> > a bug in Mutt dotlocking detection at configure time, still not fixed
> > AFAIK) and locking problems due to NFS (the problem disappeared only
> > after a reboot of the NFS server).
>
> I've been managing Unix systems and supporting users reading e-mail on
> Unix systems, including NFS-mounted spools, for nearly 10 years.
> These sites all used mbox by default, and most of the users were not
> sophisticated to change that on their own (though a few out of
> thousands were). I have RARELY encountered any mailbox corruption,
> and in all cases the users were using developmental releases of their
> mailers, so it couldn't conclusively be pinned on locking-related
> causes. Most probably it wasn't... it was probably buggy mailers.
As I've said, it was due to a bug in Mutt, which disabled dotlocking.
> Locking-related corruption has pretty much ceased to be an issue for
> mbox.
I think the bug is still there in Mutt. So this is still an issue.
> > > [Which isn't to say I think it's a good idea to keep mail on NFS
> > > dirs... But locking isn't the only reason for that.]
> >
> > There are some places where you don't have the choice.
>
> You almost always have a choice, if it matters to you enough. You
> could compile procmail locally and use a .forward file to have
No, this is not possible everywhere. I can't on the account I have at
my lab, for instance. My $HOME isn't even mounted on the mail server.
> procmail deliver mail onto a local disk or onto a pen drive, if you
> can run programs from your home directory. You can use fetchmail to
> do the same, if your server supports POP or IMAP.
There are drawbacks, starting by the fact that fetchmail has the bad
habit of losing mail (and getmail is bad for security as it needs a
password stored on the disk). Moreover, data on local disks are not
saved.
> But you're right, sometimes you don't have a choice. You're making my
> point for me: Sometimes you can't use maildir, because you don't have
> a choice.
So what? The user could still change the default configuration.
> > Yes, it *is* a mbox problem. This is the mbox format that requires
> > ">" (or whatever) to be added (by the MDA or the MUA), as not all
> > software knows the Content-Length header (if you want
> > compatibility with anything...).
>
> How is that a problem with the format? This is issue has been
> well-known for *decades* -- working around it is an application
> problem, not a format problem. That's like blaming the DHCP protocol
> for Microsoft's lack of adherence to it... It makes no sense.
Perhaps it is well-known for decades, but there are still applications
that corrupt messages.
Then, why do you blame the use of the maildir format just because
applications do not support it? This is an application problem too.
> There are numerous ways to solve this problem. One is to use an
> alternative encoding for your e-mail (like base64, since you
> mentioned it).
No, base64 is really bad for that. QP is probably much better. But
anyway, most mail software (MUA or MDA) won't choose an alternative
encoding magically.
> One is to do proper From quoting. There are others. This is
> absolutely, unequivocally not a format problem, it's an application
> problem.
A good format shouldn't force applications to do this kind of things.
So yes, first, this is a format problem.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA