Initial revision

--HG--
branch : HEAD

.cvsignore

@@ -0,0 +1,30 @@
+Makefile
+Makefile.in
+aclocal.m4
+config.cache
+config.guess
+config.h
+config.log
+config.status
+config.sub
+configure
+configure.scan
+libtool
+libtool-shared
+ltconfig
+ltmain.sh
+stamp-h
+stamp-h.in
+stamp.h
+version.h
+config.h.in
+.exrc
+install-sh
+missing
+mkinstalldirs
+INSTALL
+intl
+ABOUT-NLS
+COPYING
+build-stamp
+configure-stamp

.inslog2

@@ -0,0 +1,4 @@
+92e1e6668c743330e53b24b2c424b27b47ee62a6e49d1c2b3d9321ec8ae8e79a628ccb
+74a9b29fe624b1e15990fb1c56598fa94c2b93b455e388c9b4a2855f296d0503072fb2
+71b63590cf183ec61f83cc8431c3dd18b93ac37465c33da8abbb40e40695858c46dac8
+3016ee7c4b6ec0ed7f2b9c4ae30b9147cc070188818915e6125a64ae85eeb4

AUTHORS

@@ -0,0 +1,21 @@
+Timo Sirainen <[email protected]>
+
+Solar Designer <[email protected]> (src/auth/userinfo-passwd|shadow|pam.c)
+
+This product includes software developed by Computing Services
+at Carnegie Mellon University (http://www.cmu.edu/computing/).
+(src/lib/base64.c, src/lib-imap/imap-match.c)
+
+GLib Team (src/lib/hash.c, primes.c, strfuncs.c)
+---------
+Shawn T. Amundson  <[email protected]>
+Jeff Garzik        <[email protected]>
+Raja R Harinath    <[email protected]>
+Tim Janik          <[email protected]>
+Elliot Lee         <[email protected]>
+Tor Lillqvist      <[email protected]>
+Paolo Molaro       <[email protected]>
+Havoc Pennington   <[email protected]>
+Manish Singh       <[email protected]>
+Owen Taylor        <[email protected]>
+Sebastian Wilhelmi <[email protected]>

Makefile.am

@@ -0,0 +1,8 @@
+SUBDIRS = src doc
+
+confdir = $(sysconfdir)
+conf_DATA = dovecot-example.conf
+
+EXTRA_DIST = \
+	COPYING.LGPL \
+	$(conf_DATA)

README

@@ -0,0 +1,86 @@
+
+ * Alpha release
+
+This release has not been extensively tested, I don't recommend putting it
+into production usage yet. All the IMAP4rev1 features are fully supported,
+except custom message flags still need to be implemented. There's several
+minor problems left, see TODO file.
+
+ * Mail storages
+
+Maildir is the preferred storage with most robust implementation. mbox
+support is available but currently it relies a little bit on good luck, I
+made it mostly for personal use and I strongly recommend using maildir if
+at all possible.
+
+Maildir folders are done like with courier. INBOX is the ~/Maildir
+directory, all the other folders named as ".<folder>.<subfolder>.<etc>"
+under it, any directories not starting with a dot are simply ignored.
+Deleting folders is made atomic by renaming them as "..<folder name>" and
+deleting the directory after that. So, all directories beginning with ".."
+are deleted whenever they're noticed. Indexes are stored into each folder's
+root directory.
+
+mbox storage currently requires that all mail is in user-writable
+directory, eg. ~/mail. Especially using /var/mail/user is NOT supported.
+You may however create a ~/mail/inbox hardlink (or symlink if not chrooted)
+to pointing to /var/mail/user. All files in the mail directory are
+considered as mailboxes. Directories specify subfolders in IMAP. "inbox"
+file specifies the INBOX folder and can not be named otherwise. Indexes are
+stored into ".imap/<mailbox name>/" directories.
+
+imap process detects the storage from MAIL-environment which is preferred
+to be in format "<storage>:<data>", for example "maildir:~/Maildir". It's
+anyway allowed to be in pretty much any format as long as some of the
+storages recognizes it as a valid data, so for example "MAIL=~/mail" is
+first checked by maildir storage to see if it's valid maildir and
+mbox storage after that.
+
+If the MAIL environment isn't given at all, all the storages are gone
+through which try to find a valid directory for themselves to use. Also as
+a special case, if MAILDIR environment exists, maildir storage is used with
+the directory specified in it.
+
+Maildir storage is autodetected by checking if <directory>/cur/ exists and
+we have rwx access to it. If directory isn't known, / and ~/Maildir are
+checked. / is checked because we could be chrooted.
+
+mbox storage is autodetected by checking if .imap/ (+rwx), inbox (+rw) or
+mbox (+rw) exists in directory. If directory isn't known, / is tried first.
+After that, ~/mail and ~/Mail directories are used if they're found without
+checking if they even contain any files.
+
+ * Code
+
+The code is split into a several libraries and binaries:
+
+ src/master      - imap-master binary (see docs/design.txt)
+ src/login       - imap-login binary
+ src/auth        - imap-auth binary
+ src/imap        - imap binary
+
+ src/lib         - Generic library functions
+ src/lib-mail    - RFC-822 and MIME parsering code
+ src/lib-imap    - IMAP-specific functions for parsing, sending, etc.
+ src/lib-index   - Mailbox indexing library, slightly IMAP-specific
+ src/lib-storage - Mail storage separated into interface and implementation.
+                   imap binary uses only the interface so it's possible to
+		   add support for any kind of mail storage (eg. SQL).
+
+ * RFCs conformed
+
+822  - Standard for ARPA Internet Text Messages
+2822 - Internet Message Format (updated rfc822)
+2045..2049 - Multipurpose Internet Mail Extensions (MIME)
+
+2060 - IMAP4rev1
+2180 - IMAP4 Multi-Accessed Mailbox Practice
+
+2595 - Using TLS with IMAP, POP3 and ACAP
+2831 - Using Digest Authentication as a SASL Mechanism (DIGEST-MD5)
+
+rfc2831
+
+ * Contact info
+
+Timo Sirainen <[email protected]>, http://dovecot.procontrol.fi/

TODO

@@ -0,0 +1,142 @@
+test:
+ - make sure mmap()s work properly with NFS
+ - make sure first_hole_records is updated properly
+ - make sure locking is done properly when opening/switching modifylog 
+ - make sure index->header->flags are updated at correct times
+ - make sure SELECT rebuilds index properly when next_uid is near 32bit value
+ - make sure io_buffer_send() handles huge inputs properly
+ - make sure rfc822_parse_date() works properly
+ - make sure imap_match functions work properly
+ - try imap_message_send() / io_buffer_send_file()
+ - make sure connection limits work
+
+index:
+ - optimization:
+     - optimize so that when all mail is deleted, the indexes will be
+       truncated
+     - could hash function be better..? like uid*uid? what about changing
+       probe strategy from linear to something else?
+     - support shrinking hash file when it becomes 99% empty or so
+     - save part sizes + positions so MessagePart could be regenerated from
+       index..? probably only needed if BODY/BODYSTRUCTURE is saved, as it's
+       only useful with FETCH BODY[mime.sections] and they wouldn't be known
+       without bodystructure..
+     - index->lookup_uid_range(): first_uid could quite often be either the
+       first UID or some UIDs below the first. optimize these by remembering
+       the first UID in index.
+ - mbox:
+     - BUG: adding new mail after indexes are created doesn't work
+     - save MD5 sums for messages?
+     - update Status and X-Status headers when flags are changed
+     - last \n shouldn't be sent for messages. also remember to fix
+       the From-checks to check for [\r]\nFrom instead then..
+     - EXPUNGE doesn't delete the mail from the mbox file
+     - fsck should probably (or optionally?) really scan the message body
+       for "\nFrom " text instead of just jumping over the message body.
+       Quite useless actually, but this would make it fully reliable with md5
+       anyway..
+ - there's some race condition issues when opening mailboxes..
+ - when opening index files, check the flags and do what's needed. fsck and
+   rebuild is supported currently. compression and hash rebuilding is still
+   needed. and the cache_fields .. not sure when that'd be done, preferably
+   in the separate compress-process..
+ - set_lock() is ugly and horrible and should really be done something.
+   does the syncing really need to be there? maybe put it into separate
+   function which can be called after set_lock() by functions which actually
+   care about the sync state (fetch, search, store, etc).
+ - read-only support so we could use an index where we don't have
+   write-access? we should use MAP_PRIVATE everywhere with these boxes to
+   make sure we don't get exploited .. and anyway recheck everything to make
+   sure there wouldn't be a way to exploit them.
+ - if index was just rebuilt, modify log complains about indexid mismatch
+   at first open
+ - does append work?
+
+lib-storage:
+ - support multiple mailbox formats and locations for one user. that would
+   require support for multiple MailStorages, and since we're chroot()ed,
+   usually the only way to communicate with others would be to create
+   RemoteMailStorage which would use TCP/UNIX sockets to connect to another 
+   imap session.
+ - DELETE/RENAME: when someone else had the mailbox open, we should
+   disconnect it (when stat() fails with ENOENT while syncing)
+ - optimize SEARCH [UN]SEEN, [UN]DELETED and [UN]RECENT. They're able to
+   skip lots of messages based on the index header data.
+ - use a trie index for fast text searching, like cyrus squat?
+ - hardlink-COPY doesn't copy flags
+ - maildir: atomic COPY could be done by setting a "temporary" flag into the
+   file's name. once copying is done, set an ignore-temporary field into
+   index's header. at next sync the temporary flag will be removed.
+ - mbox: internal_date isn't saved 
+ - select "" shouldn't work.
+
+general:
+ - capabilities:
+     - acl (rfc2086)
+     - quota (rfc2087)
+     - namespace (rfc2342), id (rfc2971), mailbox-referrals (rfc2193),
+       literal+ (rfc2088), idle (rfc2177), uidplus (rfc2359)
+     - drafts: listext, children, unselect, multiappend, annotatemore
+         - sort, thread: are these really useful for clients? do any actually
+	   use them? i'd think most clients want to know all the messages
+	   anyway and can do the sorting/threading themselves.
+         - http://www.imc.org/ids.html
+ - check if t_push()/t_pop() should be added somewhere
+ - rfc-2231 continuation support
+ - "UID FETCH|SEARCH|STORE *" doesn't work if latest message was deleted.
+   should we bother to fix this? I doubt there's a client that would use this.
+ - RENAME INBOX isn't atomic with Maildir. And in general, RENAME can't
+   be moved to another storage. Maybe support doing also using COPY + delete
+   once COPY is atomic?
+
+ - go through .temp files and delete them
+ - grep for FIXME
+ - cache keeps the last message mmap()ed .. is there some case when it's not
+   a good idea? like the file changes in the background? cache should be
+   updated then. yes, especially with mbox support. the mmap should be
+   removed after unlocking. also, it shouldn't depend on mmap() anyway as
+   it's not possible to use it with eg. SQL storage.. except if we make
+   mmap()ing it optional, just give it some function which in some way
+   generates const char *msg + size_t.
+ - if auth process died and login couldn't immediately reconnect to it, it's
+   left until next user connects. however the connection needs to read the
+   init data before it can be used, so the user gets "NO Unknown
+   authentication method" error the first time
+ - ulimit / setrlimit() should be set somewhere
+ - create indexer binary
+ - SEARCH CHARSET support, iconv()?
+ - Fix the blocking SSL handshake
+ - SRP authentication support?
+ - Digest-MD5: support integrity protection, and maybe crypting. Do it
+   through imap-login like SSL is done?
+ - imap-auth should limit how fast authentication requests are allowed from
+   login processes. especially if there's one login/connection the speed
+   should be something like once/sec.
+ - support executing each login in it's own process, so if an exploit is ever
+   found from it, the attacker can't see other users' passwords
+ - the error messages given in command replies can sometimes be quite
+   specific, eg. rename(/full/path, /full/new/path) failed: xxx. These
+   probably shouldn't be shown to user, instead just print some "internal
+   error" with a timestamp and the real error would be written into syslog.
+   all errors from lib-index should be done this, and maybe some/all
+   lib-storage errors as well (there's separate error vs. critical)
+ - mmap()ing large messages isn't very good idea. we need to support doing
+   everything in pieces .. add mmap() support for iobuffers, and use them
+   everywhere?
+ - Make sure messages of size INT_MAX..UINT_MAX work correctly
+ - allocating readwrite pools now just uses system_pool .. so pool_unref()
+   can't free memory used by it .. what to do about it? at least count the
+   malloc/free calls and make complain if at the exit they don't match
+ - put IMAP_LOGFILE into config file. and the timestamp format.
+ - SIGHUPing master should reload the configuration
+ - Something's wrong with expunging mails from maildir ..
+
+optional optimizations:
+ - provide some helper binary to save new mail into mailboxes with CR+LF
+   line breaks?
+ - disk I/O is the biggest problem, so split the mail into multiple computers
+   based on user and have a proxy in the front redirecting the connection.
+   cyrus had something like this except a lot more complicated - it tried
+   to fix the problem of having shared mailboxes. we have the same problem
+   with local shared mailboxes as we chroot(), so locally we could communicate
+   with UNIX sockets, remotely that could be done with TCP sockets.

acconfig.h

@@ -0,0 +1,23 @@
+/* Build with SSL/TLS support */
+#undef HAVE_SSL
+
+/* build with IPv6 support */
+#undef HAVE_IPV6
+
+/* Define if you have struct tm->tm_gmtoff */
+#undef HAVE_TM_GMTOFF
+
+#undef USERINFO_PASSWD
+#undef USERINFO_PASSWD_FILE
+#undef USERINFO_SHADOW
+#undef USERINFO_PAM
+#undef AUTH_PAM_USERPASS
+
+/* IMAP capabilities */
+#undef CAPABILITY_STRING
+
+/* Index file compatibility flags */
+#undef MAIL_INDEX_COMPAT_FLAGS
+
+/* Required memory alignment */
+#undef MEM_ALIGN_SIZE

autogen.sh

@@ -0,0 +1,4 @@
+aclocal
+automake --add-missing
+autoheader
+autoconf