thoughts

linux下qmail的源码 本人加了一些注释

Please note that this file is not called ``Internet Mail For Dummies.''
It _records_ my thoughts on various issues. It does not _explain_ them.
Paragraphs are not organized except by section. The required background
varies wildly from one paragraph to the next.

In this file, ``sendmail'' means Allman's creation; ``sendmail-clone''
means the program in this package.


1. Security

There are lots of interesting remote denial-of-service attacks on any
mail system. A long-term solution is to insist on prepayment for
unauthorized resource use. The tricky technical problem is to make the
prepayment enforcement mechanism cheaper than the expected cost of the
attacks. (For local denial-of-service attacks it's enough to be able to
figure out which user is responsible.)

qmail-send's log was originally designed for profiling. It subsequently
sprouted some tracing features. However, there's no way to verify
securely that a particular message came from a particular local user;
how do you know the recipient is telling you the truth about the
contents of the message? With QUEUE_EXTRA it'd be possible to record a
one-way hash of each outgoing message, but a user who wants to send
``bad'' mail can avoid qmail entirely.

I originally decided on security grounds not to put qmail advertisements
into SMTP responses: advertisements often act as version identifiers.
But this problem went away when I found a stable qmail URL.

As qmail grows in popularity, the mere knowledge that rcpthosts is so
easily available will deter people from setting up unauthorized MXs.
(I've never seen an unauthorized MX, but I can imagine that it would be
rather annoying.) Note that, unlike the bat book checkcompat() kludge,
rcpthosts doesn't interfere with mailing lists.

qmail-start doesn't bother with tty dissociation. On some old machines
this means that random people can send tty signals to the qmail daemons.
That's a security flaw in the job control subsystem, not in qmail.

The resolver library isn't too bloated (before 4.9.4, at least), but it
uses stdio, which _is_ bloated. Reading /etc/resolv.conf costs lots of
memory in each qmail-remote process. So it's tempting to incorporate a
smaller resolver library into qmail. (Bonus: I'd avoid system-specific
problems with old resolvers.) The problem is that I'd then be writing a
fundamentally insecure library. I'd no longer be able to blame the BIND
authors and vendors for the fact that attackers can easily use DNS to
steal mail. Solution: insist that the resolver run on the same host; the
kernel can guarantee the security of low-numbered 127.0.0.1 UDP ports.

NFS is the primary enemy of security partitioning under UNIX. Here's the
story. Sun knew from the start that NFS was completely insecure. It
tried to hide that fact by disallowing root access over NFS. Intruders
nevertheless broke into system after system, first obtaining bin access
and then obtaining root access. Various people thus decided to compound
Sun's error and build a wall between root and all other users: if all
system files are owned by root, and if there are no security holes other
than NFS, someone who breaks in via NFS won't be able to wipe out the
operating system---he'll merely be able to wipe out all user files. This
clueless policy means that, for example, all the qmail users have to be
replaced by root. See what I mean by ``enemy''? ... Basic NFS comments:
Aside from the cryptographic problem of having hosts communicate
securely, it's obvious that there's an administrative problem of mapping
client uids to server uids. If a host is secure and under your control,
you shouldn't have to map anything. If a host is under someone else's
control, you'll want to map his uids to one local account; it's his
client's job to decide which of his users get to talk NFS in the first
place. Sun's original map---root to nobody, everyone else left alone---
is, as far as I can tell, always wrong.


2. Injecting mail locally (qmail-inject, sendmail-clone)

RFC 822 section 3.4.9 prohibits certain visual effects in headers, and
the 822bis draft prohibits even more. qmail-inject could enforce these
absurd restrictions, but why waste the time? If you will suffer from
someone sending you ``flash mail,'' go find a better mail reader.

qmail-inject's ``Cc: recipient list not shown: ;'' successfully stops
sendmail from adding Apparently-To. Unfortunately, old versions of
sendmail will append a host name. This wasn't fixed until sendmail 8.7.
How many years has it been since RFC 822 came out?

sendmail discards duplicate addresses. This has probably resulted in
more lost and stolen mail over the years than the entire Chicago branch
of the United States Postal Service. The qmail system delivers messages
exactly as it's told to do. Along the same lines: qmail-inject is both
unable and unwilling to support anything like sendmail's (default)
nometoo option. Of course, a list manager could support nometoo.

There should be a mechanism in qmail-inject that does for envelope
recipients what Return-Path does for the envelope sender. Then
qmail-inject -n could print the recipients.

Should qmail-inject bounce messages with no recipients? Should there be
an option for this? If it stays as is (accept the message), qmail-inject
could at least avoid invoking qmail-queue.

It is possible to extract non-unique Message-IDs out of qmail-inject.
Here's how: stop qmail-inject before it gets to the third line of
main(), then wait until the pids wrap around, then restart qmail-inject
and blast the message through, then start another qmail-inject with the
same pid in the same second. I'm not sure how to fix this without
system-supplied sequence numbers. (Of course, the user could just type
in his own non-unique Message-IDs.)

The bat book says: ``Rules that hide hosts in a domain should be applied
only to sender addresses.'' Recipient masquerading works fine with
qmail. None of sendmail's pitfalls apply, basically because qmail has a
straight paper path.

I predicted that I would receive some pressure to make up for the
failings of MUA writers who don't understand the concept of reliability.
(``Like, duh, you mean I'm supposed to check the sendmail exit code?'')
I was right.


3. Receiving mail from the network (tcp-env, qmail-smtpd)

qmail-smtpd doesn't allow privacy-invading commands like VRFY and EXPN.
If you really want to publish such information, use a mechanism that
legitimate users actually know about, such as fingerd or httpd.

RFC 1123 says that VRFY and EXPN are important to track down cross-host
mailing list loops. With Delivered-To, mailing list loops do no damage,
_and_ one of the list administrators gets a bounce message that shows
exactly how the loop occurred. Solve the problem, not the symptom.

Should dns.c make special allowances for 127.0.0.1/localhost?

badmailfrom (like 8BITMIME) is a waste of code space.

In theory a MAIL or RCPT argument can contain unquoted LFs. In practice
there are a huge number of clients that terminate commands with just LF,
even if they use CR properly inside DATA.


4. Adding messages to the queue (qmail-queue)

Should qmail-queue try to make sure enough disk space is free in
advance? When qmail-queue is invoked by qmail-local or (with ESMTP)
qmail-smtpd or qmail-qmtpd or qmail-qmqpd, it could be told a size in
advance. I wish UNIX had an atomic allocate-disk-space routine... 

The qmail.h interface (reflecting the qmail-queue interface, which in
turn reflects the current queue file structure) is constitutionally
incapable of handling an address that contains a 0 byte. I can't imagine
that this will be a problem.

Should qmail-queue not bother queueing a message with no recipients?


5. Handling queued mail (qmail-send, qmail-clean)

The queue directory must be local. Mounting it over NFS is extremely
dangerous---not that this stops people from running sendmail that way!
Diskless hosts should use mini-qmail instead.

Queue reliability demands that single-byte writes be atomic. This is
true for a fixed-block filesystem such as UFS, and for a logging
filesystem such as LFS.

qmail-send uses 8 bytes of memory per queued message. Double that for
reallocation. (Fix: use a small forest of heaps; i.e., keep several
prioqs.) Double again for buddy malloc()s. (Fix: be clever about the
heap sizes.) 32 bytes is worrisome, but not devastating. Even on my
disk-heavy memory-light machine, I'd run out of inodes long before
running out of memory.

Some mail systems organize the queue by host. This is pointless as a
means of splitting up the queue directory. The real issue is what to do
when you suddenly find out that a host is up. For local SLIP/PPP links
you know in advance which hosts need this treatment, so you can handle
them with virtualdomains and serialmail.

For the old queue structure I implemented recipient list compression:
if mail goes out to a giant mailing list, and most of the recipients are
delivered, make a new, compressed, todo list. But this really isn't
worth the effort: it saves only a tiny bit of CPU time.

qmail-send doesn't have any notions of precedence, priority, fairness,
importance, etc. It handles the queue in first-seen-first-served order.
One could put a lot of work into doing something different, but that
work would be a waste: given the triggering mechanism and qmail's
deferral strategy, it is exceedingly rare for the queue to contain more
than one deliverable message at any given moment.

Exception: Even with all the concurrency tricks, qmail-send can end up
spending a few minutes on a mailing list with thousands of remote
entries. A user might send a new message to a remote address in the
meantime. The simplest way to handle this would be to put big messages
on a separate channel.

qmail-send will never start a pass for a job that it already has. This
means that, if one delivery takes longer than the retry interval, the
next pass will be delayed. I implemented the opposite strategy for the
old queue structure. Some hassles: mark() had to understand how job
input was buffered; every new delivery had to check whether the same
mpos in the same message was already being done.

Some things that qmail-send does synchronously: queueing a bounce
message; doing a cleanup via qmail-clean; classifying and rewriting all
the addresses in a new message. As usual, making these asynchronous
would require some housekeeping, but could speed things up a bit.
(I'm willing to assume POSIX waitpid() for asynchronous bounces; putting
an unbounded buffer into wait_pid() for the sake of NeXTSTEP 3 is not
worthwhile.)

Disk I/O is a bottleneck; UFS is reliable but it isn't fast. A good
logging filesystem offers much better performance, but logging