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

Re: another silly question



On Sun, May 08, 2005 at 11:05:48AM +0200, Vincent Lefevre wrote:
> On 2005-05-07 22:12:21 -0400, Derek Martin wrote:
> > You cut off part of that... There was a bit about reading mail in a
> > group.
> 
> Do you mean several users reading the same mailbox? This is rare and
> I'd never recommend that; in particular, the read status is shared,
> which makes no sense. Instead, you should use either aliases / mailing
> lists to send the mail to each user or a local news server.

You're being narrow minded.

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.  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.

At my current job, we have a similar situation, though we don't
implement that method of monitoring.  I've seen things like it
elsewhere though.

Just because YOU think something is a bad idea doesn't mean it can't
work for someone else, and more importantly it doesn't mean there
aren't people doing it.  You need to open your mind.

> > As others have pointed out, it is also not so uncommon for users to
> > read mail with more than one MUA. Sometimes I do this, when I have
> > to read my mail from a machine that doesn't have mutt installed...
> > mail(x) doesn't understand maildir. That makes it a bit tough to do,
> > if I have mail in maildir format, n'est pas?
> 
> 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.

Besides which, mailx may not understand mime, but that doesn't mean it
has no facilities to handle MIME messages...  It can pipe them to
other programs, for instance.  This point is bogus.

> > I don't doubt it...  But on modern unix systems, the likelihood of
> > that happening is pretty low.  Most vendors have NFS locking fixed,
> > and on local filesystems it just shouldn't be an issue.  If you're
> > experiencing mbox corruption today, the problem is probably
> > application-specific bugs, not OS locking problems...
> 
> 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.

The reality is, locking on local fs's works.  Locking over NFS on v3+
works, at least so long as server and client are the same platform,
and most of the time even if they aren't.  Locking on NFS v2 usually
works in homogenous environments.  Basically, anything released in the
last 5 years or so just isn't a problem, in almost all practical
situations.  The odds of experiencing locking-related corruption is
dependent on what OSes are involved; but on modern OSes, provided the
application does locking properly, is just about zero, and in the
majority of cases, is actually zero.

Locking-related corruption has pretty much ceased to be an issue for
mbox.

> > [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
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.  Or if you have
login access to the server, you can run programs there to ciphon your
mail off to some other location.

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.

> > > Also, some messages get corrupted when they are stored in a mbox
> > > mailbox, due to the "From " problem. In fact, this is a sufficient
> > > condition for not using mbox at all.
> > 
> > There's no good reason for this to occur.  I've been using mbox for
> > years without ever seeing that problem.  If you're seeing it, again,
> > your MUA (or possibly MDA or MTA, or the sender's) sucks... it's not
> > an inherent mbox problem.
> 
> 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.

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).  One is to do proper From quoting.  There are others.  This is
absolutely, unequivocally not a format problem, it's an application
problem.

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail.  Sorry for the inconvenience.  Thank the spammers.

Attachment: pgpK2ihkMKyZv.pgp
Description: PGP signature