Date: Tue, 29 Oct 1996 17:43:51 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: MRC@CAC.Washington.EDU (Mark Crispin) Cc: terry@lambert.org, j@uriah.heep.sax.de, roberto@keltia.freenix.fr, current@FreeBSD.org, scrappy@ki.net Subject: Re: /var/mail (was: re: Help, permission problems...) Message-ID: <199610300043.RAA22382@phaeton.artisoft.com> In-Reply-To: <MailManager.846631031.13515.mrc@Tomobiki-Cho.CAC.Washington.EDU> from "Mark Crispin" at Oct 29, 96 03:17:11 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Actually, I would think that if it didn't go through mail.local, then > > it isn't in a local user's mailbox: it's still in the delivery queue for > > sendmail/smail/mmdf/IMAP/etc. > > Let me try one more time: > My car is a BMW; therefore, all cars are BMWs. > My system uses a mail delivery program called mail.local that uses > flock() for locking; therefore all systems use a mail delivery > program called mail.local that uses flock() for locking. > Do you see the fallacy yet? I don't agree that your examples are analogous. In the first, you are arguing from the general to the specific; this is a well known logical fallacy involving the distinction between necessicity and sufficiency. In the second, you are arguing that you should somehow *care* how the mail.local does locking, and that therefore the distinction between flock() locking vs. some other locking methodology is also somehow important. Why do you care how the specific locking is done, so long as it is done? > > I think the only legal access to the local user's mailbox is via > > mail.local (incoming) and POP3/IMAP4/ELM/other-mail-reader (content > > browsing and manipulation). > > This is presuming that mail.local is the program installed to do mail > delivery. This may also be presuming that the version of mail.local that is > installed is one that is written to behave in a certain way, as opposed to > some other way. > > I can't afford to make such presumptions. mail.local for any system will be written in such a way as to succesfully interact via some method with mail user agents for the system for which it is the mail.local. Thus this is only an issue if you are: 1) Writing mail.local 2) Writing a mail user agent, and not using the same message store interface code as was used to implement mail.local In the first case, you must conform to the defined interface for the system. In the second case, you must conform to the schma used by mail.local. >From your desription of c-client's and in "docs/locking", it seems pretty clear that what you really need is another "driver" type that is that same as the flock() driver type, but which uses fcntl(). It's not unreasonable for an application to expect fcntl() to work correctly locally, and over NFS (FreeBSD doesn't have the NFS client side, has the unintegrated patches for the NFS server side, and does work locally. This is *without* the "bug" you note in the exclusive locking of read-only files. I think it's probably reasonable to expect the mail.local (sendmail on BSD) to determine the local locaking state machine, and for the driver in IMAP4 to implement the same machine. It's not clear why sendmail and smail haven't been modified to use the c-client library to make this transparent. 8-(. > > That basically means that the storage type is abstracted from the > > act of transport for most purposes, and *should* be abstracted from > > the act of reference. There is a MIME library, but licensing > > restrictions make it practically useless. 8-(. > > ftp://ftp.cac.washington.edu/mail/imap.tar.Z is a free MIME library. The c-client code is the code you refer to, right? This is a bit more than a database interface to a MIME-capable message store (basically, most UNIX mail programs fit into your "otherwise not generally useful" category: all they would want is per message access to 822 compliant messages). So in conclusion: 1) There should be an fcntl() awar "driver" to go with the flock() aware "driver", since this is the best approach to locaking on FreeBSD (and NetBSD and OpenBSD, etc.). 2) There needs to be a subset interface for non-MIME-aware mail transport agents (which only care about the encapsulated message, not how to break out contents other than addressing tags, which are seperate anyway, by definition). 3) Sendmail (out "mail.local") should use the subset interface. A tall order, unfortunately. 8-(. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610300043.RAA22382>