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