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 backgroundvaries wildly from one paragraph to the next.In this file, ``sendmail'' means Allman's creation; ``sendmail-clone''means the program in this package.1. SecurityThere are lots of interesting remote denial-of-service attacks on anymail system. A long-term solution is to insist on prepayment forunauthorized resource use. The tricky technical problem is to make theprepayment enforcement mechanism cheaper than the expected cost of theattacks. (For local denial-of-service attacks it's enough to be able tofigure out which user is responsible.)qmail-send's log was originally designed for profiling. It subsequentlysprouted some tracing features. However, there's no way to verifysecurely that a particular message came from a particular local user;how do you know the recipient is telling you the truth about thecontents of the message? With QUEUE_EXTRA it'd be possible to record aone-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 advertisementsinto 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 soeasily available will deter people from setting up unauthorized MXs.(I've never seen an unauthorized MX, but I can imagine that it would berather 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 machinesthis 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 ituses stdio, which _is_ bloated. Reading /etc/resolv.conf costs lots ofmemory in each qmail-remote process. So it's tempting to incorporate asmaller resolver library into qmail. (Bonus: I'd avoid system-specificproblems with old resolvers.) The problem is that I'd then be writing afundamentally insecure library. I'd no longer be able to blame the BINDauthors and vendors for the fact that attackers can easily use DNS tosteal mail. Solution: insist that the resolver run on the same host; thekernel 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 thestory. Sun knew from the start that NFS was completely insecure. Ittried to hide that fact by disallowing root access over NFS. Intrudersnevertheless broke into system after system, first obtaining bin accessand then obtaining root access. Various people thus decided to compoundSun's error and build a wall between root and all other users: if allsystem files are owned by root, and if there are no security holes otherthan NFS, someone who breaks in via NFS won't be able to wipe out theoperating system---he'll merely be able to wipe out all user files. Thisclueless policy means that, for example, all the qmail users have to bereplaced by root. See what I mean by ``enemy''? ... Basic NFS comments:Aside from the cryptographic problem of having hosts communicatesecurely, it's obvious that there's an administrative problem of mappingclient 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'scontrol, you'll want to map his uids to one local account; it's hisclient's job to decide which of his users get to talk NFS in the firstplace. 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, andthe 822bis draft prohibits even more. qmail-inject could enforce theseabsurd restrictions, but why waste the time? If you will suffer fromsomeone sending you ``flash mail,'' go find a better mail reader.qmail-inject's ``Cc: recipient list not shown: ;'' successfully stopssendmail from adding Apparently-To. Unfortunately, old versions ofsendmail 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 inmore lost and stolen mail over the years than the entire Chicago branchof the United States Postal Service. The qmail system delivers messagesexactly as it's told to do. Along the same lines: qmail-inject is bothunable 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 enveloperecipients what Return-Path does for the envelope sender. Thenqmail-inject -n could print the recipients.Should qmail-inject bounce messages with no recipients? Should there bean option for this? If it stays as is (accept the message), qmail-injectcould 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 ofmain(), then wait until the pids wrap around, then restart qmail-injectand blast the message through, then start another qmail-inject with thesame pid in the same second. I'm not sure how to fix this withoutsystem-supplied sequence numbers. (Of course, the user could just typein his own non-unique Message-IDs.)The bat book says: ``Rules that hide hosts in a domain should be appliedonly to sender addresses.'' Recipient masquerading works fine withqmail. None of sendmail's pitfalls apply, basically because qmail has astraight paper path.I predicted that I would receive some pressure to make up for thefailings 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 thatlegitimate users actually know about, such as fingerd or httpd.RFC 1123 says that VRFY and EXPN are important to track down cross-hostmailing list loops. With Delivered-To, mailing list loops do no damage,_and_ one of the list administrators gets a bounce message that showsexactly 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 practicethere 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 inadvance? 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 inadvance. I wish UNIX had an atomic allocate-disk-space routine... The qmail.h interface (reflecting the qmail-queue interface, which inturn reflects the current queue file structure) is constitutionallyincapable of handling an address that contains a 0 byte. I can't imaginethat 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 extremelydangerous---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 istrue for a fixed-block filesystem such as UFS, and for a loggingfilesystem such as LFS.qmail-send uses 8 bytes of memory per queued message. Double that forreallocation. (Fix: use a small forest of heaps; i.e., keep severalprioqs.) Double again for buddy malloc()s. (Fix: be clever about theheap sizes.) 32 bytes is worrisome, but not devastating. Even on mydisk-heavy memory-light machine, I'd run out of inodes long beforerunning out of memory.Some mail systems organize the queue by host. This is pointless as ameans of splitting up the queue directory. The real issue is what to dowhen you suddenly find out that a host is up. For local SLIP/PPP linksyou know in advance which hosts need this treatment, so you can handlethem 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 aredelivered, make a new, compressed, todo list. But this really isn'tworth 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 thatwork would be a waste: given the triggering mechanism and qmail'sdeferral strategy, it is exceedingly rare for the queue to contain morethan one deliverable message at any given moment.Exception: Even with all the concurrency tricks, qmail-send can end upspending a few minutes on a mailing list with thousands of remoteentries. A user might send a new message to a remote address in themeantime. The simplest way to handle this would be to put big messageson a separate channel.qmail-send will never start a pass for a job that it already has. Thismeans that, if one delivery takes longer than the retry interval, thenext pass will be delayed. I implemented the opposite strategy for theold queue structure. Some hassles: mark() had to understand how jobinput was buffered; every new delivery had to check whether the samempos in the same message was already being done.Some things that qmail-send does synchronously: queueing a bouncemessage; doing a cleanup via qmail-clean; classifying and rewriting allthe addresses in a new message. As usual, making these asynchronouswould require some housekeeping, but could speed things up a bit.(I'm willing to assume POSIX waitpid() for asynchronous bounces; puttingan unbounded buffer into wait_pid() for the sake of NeXTSTEP 3 is notworthwhile.)Disk I/O is a bottleneck; UFS is reliable but it isn't fast. A goodlogging filesystem offers much better performance, but logging