done
fi
-if test ! -f doc/wiki/Authentication.txt; then
- cd doc
- wget https://www.dovecot.org/tmp/wiki2-export.tar.gz
- tar xzf wiki2-export.tar.gz
- if [ $? != 0 ]; then
- echo "Failed to uncompress wiki docs"
- exit
- fi
- mv wiki2-export/*.txt wiki/
- rm -rf wiki2-export wiki2-export.tar.gz
- cd ..
-fi
-
-cd doc/wiki
-cp -f Makefile.am.in Makefile.am
-echo *.txt | sed 's, , \\/ ,g' | tr '/' '\n' >> Makefile.am
-cd ../..
-
autoreconf -i
rm -f ChangeLog
Makefile
doc/Makefile
doc/man/Makefile
-doc/wiki/Makefile
doc/example-config/Makefile
doc/example-config/conf.d/Makefile
src/Makefile
extra_dist_extra =
SUBDIRS = man example-config
-DOCDIRS = wiki example-config
+DOCDIRS = example-config
docfiles = \
- documentation.txt \
- securecoding.txt \
thread-refs.txt \
mkcert.sh \
dovecot-openssl.cnf \
+++ /dev/null
-The documentation in wiki/ directory has been imported from
-http://wiki2.dovecot.org/. The actual Wiki may contain more up-to-date
-information, so unless this is an old Dovecot release, you may want to use
-the Wiki directly.
-
- * <QuickConfiguration.txt> for people in hurry
- * <WhyDoesItNotWork.txt> - Why doesn't Dovecot work?
-
-Generic information about mail servers
-======================================
-
- * Mail protocols: IMAP [http://en.wikipedia.org/wiki/Imap], POP3
- [http://en.wikipedia.org/wiki/Pop3] and SMTP
- [http://en.wikipedia.org/wiki/Smtp]
- * <Mail delivery agents and Sieve> [MDA.txt]
- * <Mailbox formats> [MailboxFormat.txt]
- * <Dovecot's index files> [IndexFiles.txt]
- * <User authentication> [Authentication.txt]
- * <SASL> [Sasl.txt]
-
-Dovecot installation
-====================
-
-It's a good idea to start with a simple Dovecot installation to see that
-everything works. After that you can start changing things one at a time, so if
-you run into trouble you know immediately where the problem is.
-
-If you're in a hurry and you already know enough about mail servers,
-<QuickConfiguration.txt> may be more helpful to you instead.
-
- 1. Installing
- * <Compiling from sources> [CompilingSource.txt]
- * <Installing prebuilt binaries> [PrebuiltBinaries.txt]
- 2. <Checking where mail is delivered to> [FindMailLocation.txt]
- 3. <Configuring Dovecot> [BasicConfiguration.txt]
- 4. <Running Dovecot> [RunningDovecot.txt]
- 5. <Logging.txt>
- 6. <Testing that everything works> [TestInstallation.txt]
- * <Testing POP3 installation> [TestPop3Installation.txt]
- 7. <Finishing the test installation> [FinishBasicConfiguration.txt]
-
-Dovecot configuration
-=====================
-
- * Starting guidelines
- * <System users> [SystemUsers.txt]
- * <Virtual users> [VirtualUsers.txt]
- * <UNIX User IDs used by Dovecot> [UserIds.txt]
- * <Authentication configuration> [Authentication.txt]
- * <Password databases> [PasswordDatabase.txt]
- * <User databases> [UserDatabase.txt]
- * <Multiple authentication databases>
- [Authentication.MultipleDatabases.txt]
- * <Kerberos> [Authentication.Kerberos.txt]
- * <Restricting users' access> [Authentication.RestrictAccess.txt]
- * <Special authentication features> [PasswordDatabase.ExtraFields.txt]
- * <Master users> [Authentication.MasterUsers.txt]
- * <Caching> [Authentication.Caching.txt]
- * <Mailbox location configuration> [MailLocation.txt]
- * <Mails stored in local disk> [MailLocation.LocalDisk.txt]
- * <Mails stored in shared filesystem> [MailLocation.SharedDisk.txt]
- (<NFS.txt>, clustered FS)
- * <Director.txt> for easily proxying same user to same server to
- avoid caching problems.
- * <Maildir configuration> [MailLocation.Maildir.txt]
- * <Mbox configuration> [MailLocation.Mbox.txt]
- * <Namespaces.txt>
- * <Shared mailboxes> [SharedMailboxes.txt]
- * <Login processes and their settings> [LoginProcess.txt]
- * <SSL.txt> settings and certificate creation
- * <Plugins.txt>
- * <Quota.txt>
- * <Access Control Lists> [ACL.txt] (ACLs)
- * <Dovecot as a POP3 server> [POP3Server.txt]
- * <Dovecot's local delivery agent> [LDA.txt]
- * <Sieve.txt> and <ManageSieve.txt>
- * <Post-login scripting> [PostLoginScripting.txt]
-
-HOWTOs, examples and tutorials
-==============================
-
-Some HOWTOs haven't been included in wiki/. Use http://wiki2.dovecot.org/
-instead.
-
- * <HOWTOs, examples and tutorials> [HowTo.txt] for different installations
- * Existing Dovecot installations
- [http://wiki2.dovecot.org/DovecotServerInstallations]
-
-Migration from existing systems
-===============================
-
- * <From other IMAP/POP3 servers> [Migration.txt]
- * <My mailboxes are lost after migrating to Dovecot!>
- [MissingMailboxes.txt]
- * <Upgrading Dovecot to a new version> [Upgrading.txt]
- * <Converting between mailbox formats> [Migration.MailFormat.txt] (mbox <->
- Maildir, etc.)
-
-Troubleshooting
-===============
-
- * <Why doesn't Dovecot work?> [WhyDoesItNotWork.txt]
- * <Finding the error message from logs> [Logging.txt]
- * <Debugging authentication> [Debugging.Authentication.txt]
- * <Process tracing> [Debugging.ProcessTracing.txt] is useful when Dovecot
- seems slow or hangs completely
- * Rawlog [Debugging.Rawlog.txt] can be used to log post-login IMAP/POP3
- traffic
- * <mbox errors and crashes> [MboxProblems.txt]
- * <Client issues and configuration> [Clients.txt]
- * <Negative UIDs / message sets> [Clients.NegativeUIDs.txt]
- * <Debugging using Thunderbird's logging> [Debugging.Thunderbird.txt]
- * <"Time moved backwards" error> [TimeMovedBackwards.txt]
- * <%d expands to empty string> [DomainLost.txt]
- * <pre-authenticated sessions> [PreAuth.txt]
- * Sending bug reports [http://dovecot.org/bugreport.html], debugging crashes
- and sniffing network traffic
-
-Tuning
-======
-
- * <Performance tuning> [PerformanceTuning.txt]
- * <Security tuning> [SecurityTuning.txt]
- * <Chrooting.txt>
-
-Reference
-=========
-
- * <Dovecot's design> [Design.txt]
- * <Client issues and configuration> [Clients.txt]
+++ /dev/null
-Simplicity provides security. The more you have to remember to maintain
-security the easier it is to forget something.
-
-
-Use Multiple Layers of Security
--------------------------------
-
-Input validation is useful to prevent clients from taking too much server
-resources. Add the restrictions only where it's useful. For example a
-simple "maximum line length" will limit the length of pretty much all
-possible client input.
-
-Don't rely on input validation. Maybe you missed something. Maybe someone
-calls your function somewhere else where you didn't originally intend it.
-Maybe someone makes the input validation less restrictive for some reason.
-Point is, it's not an excuse to cause a security hole just because input
-wasn't what you expected it to be.
-
-Don't trust memory. If code somewhere overflowed a buffer, don't make it
-easier to exploit it. For example if you have code:
-
- static char staticbuf[100];
- ..
- char stackbuf[100];
- strcpy(stackbuf, staticbuf);
-
-Just because staticbuf was declared as [100], it doesn't mean it couldn't
-contain more data. Overflowing static buffers can't be directly exploited,
-but the strcpy() overflowing stackbuf makes it possible. Always copy data
-with bounds checking.
-
-
-Prevent Buffer Overflows
-------------------------
-
-Avoid writing to buffers directly. Write everything through buffer API
-(lib/buffer.h) which guarantees protection against buffer overflows.
-There are various safe string APIs as well (lib/str.h, lib/strfuncs.h).
-Dovecot also provides a type safe array API (lib/array.h).
-
-If you do write to buffers directly, mark the code with /* @UNSAFE */
-unless it's _obviously_ safe. Only obviously safe code is calling a
-function with (buffer, sizeof(buffer)) parameters. If you do _any_
-calculations with buffer size, mark it unsafe.
-
-Use const with buffers whenever you can. It guarantees that you can't
-accidentally modify it.
-
-Use "char *" only for NUL-terminated strings. Use "unsigned char *"
-if it's not guaranteed to be NUL-terminated.
-
-
-Avoid free()
-------------
-
-Accessing freed memory is the most difficult problem to solve with C code.
-Only real solution is to use garbage collector, but it's not possible to
-write a portable GC without radical changes in how you write code.
-
-There are a few ways to avoid most free() calls however: data stack and
-memory pools.
-
-Data stack works in somewhat similar way to C's control stack. alloca() is
-quite near to what it does, but there's one major difference: Stack frames
-are explicitly defined, so functions can return values allocated from data
-stack. t_strdup_printf() call is an excellent example of why this is
-useful. Rather than creating some arbitrary sized buffer and using
-snprintf() which may truncate the value, you can just use t_strdup_printf()
-without worrying about buffer sizes being large enough.
-
-Try to keep the allocations from data stack small, since the data stack's
-highest memory usage size is kept for the rest of the process's lifetime.
-The initial data stack size is 32kB and it should be enough in normal use.
-See lib/data-stack.h.
-
-Memory pools are useful when you have to construct an object from multiple
-pieces and you can free it all at once. Actually Dovecot's Memory Pool API
-is just an abstract class for allocating memory. There's system_pool for
-allocating memory with calloc(), realloc() and free() and you can create a
-pool to allocate memory from data stack. If your function needs to allocate
-memory for multiple objects, you may want to take struct pool as parameter
-to allow caller to specify where the memory is allocated from.
-See lib/mempool.h
-
-
-Deinitialize safely
--------------------
-
-Whenever you free a pointer, set it to NULL. That way if you accidentally
-try to free it again, it's less likely to cause a security hole. Dovecot
-does this automatically with most of its free() calls, but you should also
-make it a habit of making all your _destroy() functions take a
-pointer-to-pointer parameter which you set to NULL.
-
-Don't Keep Secrets
-------------------
-
-We don't do anything special to protect ourself against read access buffer
-overflows, so don't store anything sensitive in memory. We use multiple
-processes to protect sensitive information between users.
-
-When dealing with passwords and such, erase them from memory after you
-don't need it anymore. Note that such memset() may be optimized away by
-compiler, use safe_memset().
-
-
-Use GCC Extensions
-------------------
-
-GCC makes it easy to catch some potential errors:
-
-Format string vulnerabilities can be prevented by marking all functions
-using format strings with __attr_format__() and __attr_format_arg__()
-macros and using -Wformat=2 GCC option.
-
--W option checks that you don't compare signed and unsigned variables.
-
-I hope GCC will later emit a warning whenever there's potential integer
-truncation. -Wconversion kind of does that, but it's not really meant for
-it and it gives too many other useless warnings.
-
-
-Use union Safely
-----------------
-
-Suppose there was code:
-
-union {
- unsigned int number;
- char *str;
-} u;
-
-If it was possible for user to set number arbitrarily, but access the union
-as string it'd be possible to read or write arbitrary memory locations.
-
-There's two ways to handle this. First would be to avoid union entirely and
-use a struct instead. You don't really need the extra few bytes of memory
-that union saves.
-
-Another way is to access the union only through macro that verifies that
-you're accessing it correctly. See IMAP_ARG_*() macros in
-lib-imap/imap-parser.h.
+++ /dev/null
-if BUILD_DOCS
-wikidir = $(docdir)/wiki
-wiki_DATA = $(wikifiles)
-endif
-
-EXTRA_DIST = \
- $(wikifiles)
-
-wikifiles =
\ No newline at end of file
projects / thirdparty / dovecot / core.git / commitdiff
