John H. Robinson, IV wrote: > It would be nice if someone could point to installation instructions > for > Cyrus. I tried to find some, short of downloading the Cyrus tarball. > > Neil Schneider wrote: >> > >> > [1] http://www.qmail.org/man/man5/maildir.html >> >> If I build buses, and can define that a bus has a 128 inch wheel >> base, >> then a vehicle with a 144 inch wheel base is not a bus, by my >> definition. > > No. Busses already have a definition. Go build a Glamazuul. Then you > can > define a Glamazuul however you like. > >> > *NOW*! Iff Cyrus uses a True Maildir, and _adds_ a db for indexing >> > speedup purposes, this is Well and Fine. Cyrus, however, does not >> like >> > it when users have local accounts on the system, so you still can >> not >> > manipulate your mail as a True Maildir would allow. >> >> Cyrus doesn't care. > > http://cyrusimap.web.cmu.edu/imapd/ > > The Cyrus IMAP server differs from other IMAP server > implementations > in that it is generally intended to be run on sealed servers, where > normal users are not permitted to log in. > > Has something changed?
Well not really, though the server I just set up has user accounts. The mail is still in the mail store accessable though IMAP. >> But you are confusing a mail reader with a server again. If your >> mail >> is received on a server that you do not own or administer, do you >> care >> what the file system is? > > No. I am not confusing it. > > Let's say that we have a scenario where there is a Black Box. Mail > goes > in via SMTP, and comes out via IMAP. Those are the only two ways to > access it. No httpd. No sshd. No in.telnetd. Two ports open, SMTP and > IMAP. In this case, we don't care. We can't care. Until Something Bad > happens, but it being a Black Box, nothing bad can happen. > > In the Real World, you say that we can manipulate the Cyrus mail spool > directly, out of the SMTP/IMAP band. Then format becomes important. If > the MUA can't read it (I have used cat and less as MUAs), then the > format is useless. Even brain-dead MUAs like cat and less can read > Maildir and mbox formats. MMDF is a little harder. Never tried MH. You don't manipulate it directly unless you have the right priveleges. You manipulate it through IMAP. >> Download the mail to your local file system and do whatever you want >> with it. > > This gets us out of the Black Box problem, and what I recommend to > people, and have been saying all along. I think only geeks want to do that much manipulation of their email. I know of several people who have nearly every email they ever received. I also know of businesses that delete all email once it is over a year old. It's company policy. With IMAP they can enforce that, I don't think POP can manipulate it. Also, I recently learned that you can actually upload mail through the client interface in IMAP. Will POP let you do that? <snip> > > I'm starting to think that I misunderstood Cyrus. I thought it was one > of those Input to Output systems, that had an MTA, an MDA, and a > IMAP/POP thing. > > To alleviate my confusion, as the Cyrus Wiki is being no help to me, > how does the mail flow from a remote SMTP to the local Cyrus? I am > particularly interested in the hand-off between the last non-Cyrus > step > to the frst Cyrus step. Yeah, that's one of the problems with Cyrus, it's not user friendly to set up, and the documentation is less the optimal, to be charitable. Cyrus is a MDA. It needs a MTA to do the SMTP part, I usually use Postfix. Could use sendmail or Exim, if your heart is in that place. Dunno about qmail. In my configurations, Postfix hands mail to Cyrus through a LMTP (local mail transport) socket. Cyrus can talk to Postfix, to tell it what local accounts there are. Postfix delivers it directly to Cyrus through the same socket. They can talk other ways, but that's the common way. >> > I am not trying to pick on Cyrus, but any system that uses its >> own, >> > non-standard (ie: mbox or Maildir) database. >> >> It's the MDA!!!!! > > See where my confusion is coming in? But since the MDA takes from a > pipe > or socket, and not a file, and writes to a file, that file is under > the > MDAs control. Typically, that format is mbox or Maildir. So, indeed, > by > your own admission, Cyrus is still responsible for its own > non-standard > format. Each mail is an individual file. A cyrus database tracks the flags, seen, unseen and all that. It also indexes the mails, with a hash table, or Database. The mails themselves are individual files. I just restored a mailstore from backup, ran some cyrus programs pointed to the directory and it built new indexes and databases. I could take a maildir folder, dump it into the cyrus server, run these programs on it and it would be all available through IMAP. >> Take delivery of the mail with your mail reader and do whatever the >> hell you want with it on your local machine!!! > > This is what I am telling people to do. It is far more versatile than > relying upon some remote system that locks up your stuff in a Black > Box. > I don't trust Black Boxes. I don't epxect other people to trust them, > either. I trust them. Knock on wood, I've never lost an email with cyrus. The recipient may lose it, but I haven't. Since we're discussing the differences between IMAP and POP, here's another. Assuming you are reading email with a local client, POP always sends you the entire file. IMAP only sends the headers and subject line. You don't get the body, until you ask for it. So it conserves bandwidth relative to POP. You can actually delete emails on the server without ever downloading the body to your local machine. >> I don't like mail clients having shell accounts on my mail server. > > That's fine. We may be speaking of two different things > simultaneously. > > As a user: non-standard formats are bad because they lock you into > product lines. When that product line no longer meets your needs, you > are screwed. I agree. If you were using my server, and decided you wanted all your email, I could burn it into a CD from my server, and hand it to you. You could load it on your local machine, and never know that it was from Cyrus. The only thing you might have a problem with is the file names. Let me give you a peek. Here's a directory listing from one user's mail store: foo:~# ls /var/spool/imap/user/sales/ 10. 12. 14. 16. 18. 4. 6. 8. Drafts Trash cyrus.header 11. 13. 15. 17. 19. 5. 7. 9. Sent cyrus.cache cyrus.index The files 10,11,12,13 are the individual emails. Drafts, Trash and Sent are all sub folders of the INBOX. IMAP allows you to create multiple folders and with the aid of sieve, filter your email into those folders. I just counted, I have 64 subfolders in my IMAP account. More than 50 of them have filters that deposit mail directly into the folders, very similar to procmail. > As an admin: non-standard formats are bad because they prevent you > from > being able to fix things when they break. And they will break. I agree, one of the very reasons I like cyrus-imapd. > Neither of the two have anything to do with user accounts on the mail > server. > >> > The unusual case is that the MTA != MDA. So I stick with the usual >> > case, for argument. If we want to cover all corner cases, well, >> that >> > is a lot more work and effort than I am willing to put forth. >> >> No, it is not the corner case. Procmail is an MDA, do you consider >> it >> to be an exception? The only case I can think of where MTA == MDA is >> Exchange. > > Sendmail. Postfix. qmail. Exim. They may come with a program similar to deliver that comes with postfix. Do most people use them? I figured they were just throw aways. I thought most people handed off to something like procmail. If there is one user using procmail, then I think all the users have to use procmail for local delivery. I'm pretty sure you can't use deliver for some accounts with Postfix and cyrus for others. Whatver you use you have to use it for all accounts. > A lot. > > If procmail is installed and being used, then procmail is the MDA. I > posit that *MOST* mail installations are not using procmail for most > deliveries. I cannot prove this, though. Delivery is a seperate program from the one that listens for incoming mail. I always looked at things like deliver as something thrown in to make sure there is something to actualy put the mail in a file as oppossed to something that many people use and recommend. >> > Also, the server and client must be able to speak the same >> language. >> > Be it network via HTTP/IMAP/NNTP/POP[2], or read straight >> > off of disk in a mbox/Maildir/MH/MMDF format. >> >> False, what delivered mail into the mbox/Maildir/MH/MMDF format? >> Clue, >> it wasn't the MTA. > > It was the MTA unless there was another, explicit, MDA. Actually from what I can tell, MTA's always hand off to a MDA. It may be "deliver", but it mostly it's another MDA like Cyrus, UWIMAP, maildrop, dovecot, procmail and others. > > POP can do that too. You can also tell IMAP to delete the mail. > > http://www.faqs.org/rfcs/rfc3501.html > > The EXPUNGE command permanently removes all messages that have the > \Deleted flag set from the currently selected mailbox. Before > returning an OK to the client, an untagged EXPUNGE response is sent > for each message that is removed. > > You can also tell POP to not delete the mail, by not issuing the DELE > command. > > http://www.faqs.org/rfcs/rfc1939.html > > DELE msg > > The POP3 server marks the message as deleted. Any future reference > to the message-number associated with the message in a POP3 command > generates an error. The POP3 server does not actually delete the > message until the POP3 session enters the UPDATE state. > > The lesson here is: in this case, there is _nothing_ special about > IMAP. There's nothing special about any of the MTAs either. I like cyrus, because it stores the emails as single files, is easily recoverable and can be set up as a black-box, without user accounts on the system, that could lead to compromise. I can configure it to use ldap for authentiation, because it's already ldap aware. As long as the system is backed up reliably, recovery is possible. -- Neil Schneider pacneil_at_linuxgeek_dot_net http://www.paccomp.com Key fingerprint = 67F0 E493 FCC0 0A8C 769B 8209 32D7 1DB1 8460 C47D I started with nothing and I still have most of it. -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
