| gabriel rosenkoetter on Wed, 7 May 2003 07:13:09 -0400 |
|
On Wed, May 07, 2003 at 12:26:00AM -0400, Martin DiViaio wrote: > Answer: IT CAN'T ACCORDING TO THE SPECIFICATION! Non-spool file types are > supposed to be supported and available. Because the standard doesn't define what a mail spool file looks like, and different systems use different things (not everybody's incoming mail spool is in mbox format; nobody's outgoing mail spool is). > It depends on the command. Some are optional, others are not. That evades the question. Were the commands you used optional or not? > As I said before, my problem is not that I did it but that the response > was CORRECT ACCORDING TO THE SPECIFICATION. And I think you are over-reacting on a galactic scale. > chroot was not an option at the time due to the mail spool files crossing > several filesystems. I eventually went with the code hack as the best > solution at the time. (Especially since I couldn't switch to Courier or > Cyrus.) Sure it was. chroot(2) to a directory with sym links, having already switched to a non-root user. (Only uid 0 can climb sym links back out of a chroot jail, presuming you've done the directory ownership properly.) > Messages are really nothing but blocks of text. Why would you need binary > support at the protocol level? Because people like to attach binary files, like say photographs from vacation to their email. Why shouldn't they be able to? Shouldn't email function as similarly to postal mail does as it can? Should people be able to email Postscript documents? If so, then why shouldn't they be able to email Microsoft Word documents? If not, then how will your IMAP daemon tell the difference between plain text and a Postscript document? (Hint: you can't.) What about things like a shared calendar; should it have to be stored in mbox format for various IMAP clients to use it? (My understanding is that groupware was considered by IMAP designers, though I don't have a reference for that.) > As for jumping into an uploaded file, all you need to do is open the file, > select a byte position and start writing (if you have write access to the > file). Huh? Okay, fine, but that doesn't get you an sort of compromise, because what you need the server to do is not just read(2) but execve(2) the file, which is what I was (pretty obviously, I assumed) implying when I said to JMP into it. JMP's not a write instruction, it tells the IA32 processor to jump to a memory address and continue execution from there. I don't think it's possible to tell any IMAP daemon to do this into an uploaded file. > FTP and SCP are exactly what they claim, file access protocols. IMAP has > file access abilities because of poor protocol design. There is a > difference there. I don't agree. I think that IMAP's protocol design requires that it have file access abilities and that it should come as no shock to anyone who understands what the IMAP daemon is there to do. It's there to provide remote users with access to files on the server. > I could agree with this if the upload was strictly limited to messages. > It's not. I really just don't understand why you think this is a problem. The feature is absolutely necessary to allow users to move mail around and create new mail boxes on the server, not to mention to read their mail in IMAP-client comfort but save attachments out and then deal with them from a command-line. > My mistake, I was distracted at the time and accidentally called up an > older version of the IMAP specs to verify this bit. It did support an EXEC > command. Okay, that's a clear design flaw. But it's been fixed, I take it? > Ok, what happens when your favorite IMAP server's developers decide to do > a full implimentation of the protocol specification? I don't see that you've clearly (or even murkily) shown us that there'd be any problem with that. -- gabriel rosenkoetter gr@eclipsed.net Attachment:
pgp2YSPdZPEX4.pgp
|
|