commit e276badd22c5bb81d6c0ebdde6da4d670a9332d9
parent 8b510badbbbbb5e4888f1b2d2ba525c9aa51a2c6
Author: Amitai Schleier <schmonz-web-git@schmonz.com>
Date: Sat, 23 May 2020 16:11:53 +0200
Replace --- with -- when it's simulating em-dash.
Diffstat:
12 files changed, 51 insertions(+), 51 deletions(-)
diff --git a/BLURB.md b/BLURB.md
@@ -16,7 +16,7 @@ his mail over NFS, but any number of NFS clients can deliver mail to him
at the same time.
Efficient: On a Pentium under BSD/OS, qmail can easily sustain 200000
-local messages per day---that's separate messages injected and delivered
+local messages per day -- that's separate messages injected and delivered
to mailboxes in a real test! Although remote deliveries are inherently
limited by the slowness of DNS and SMTP, qmail overlaps 20 simultaneous
deliveries by default, so it zooms quickly through mailing lists. (This
diff --git a/BLURB2.md b/BLURB2.md
@@ -9,7 +9,7 @@ touches ~user/.qmail-whatever-owner, all bounces will come back to him.
* qmail supports VERPs, which permit completely reliable automated
bounce handling for mailing lists of any size.
-* SPEED---qmail blasts through mailing lists an order of magnitude
+* SPEED -- qmail blasts through mailing lists an order of magnitude
faster than sendmail. For example, one message was successfully
delivered to 150 hosts around the world in just 70 seconds, with qmail's
out-of-the-box configuration.
diff --git a/BLURB3.md b/BLURB3.md
@@ -1,16 +1,16 @@
Here are some of qmail's features.
Setup:
-* automatic adaptation to your UNIX variant---no configuration needed
+* automatic adaptation to your UNIX variant -- no configuration needed
* AIX, BSD/OS, FreeBSD, HP/UX, Irix, Linux, OSF/1, SunOS, Solaris, and more
* automatic per-host configuration (config, config-fast)
-* quick installation---no big list of decisions to make
+* quick installation -- no big list of decisions to make
Security:
* clear separation between addresses, files, and programs
* minimization of setuid code (qmail-queue)
* minimization of root code (qmail-start, qmail-lspawn)
-* five-way trust partitioning---security in depth
+* five-way trust partitioning -- security in depth
* optional logging of one-way hashes, entire contents, etc. (QUEUE_EXTRA)
Message construction (qmail-inject):
@@ -27,9 +27,9 @@ SMTP service (qmail-smtpd):
* RFC 821, RFC 1123, RFC 1651, RFC 1652, RFC 1854
* 8-bit clean
* 931/1413/ident/TAP callback (tcp-env)
-* relay control---stop unauthorized relaying by outsiders (control/rcpthosts)
+* relay control -- stop unauthorized relaying by outsiders (control/rcpthosts)
* no interference between relay control and forwarding
-* tcpd hook---reject SMTP connections from known abusers
+* tcpd hook -- reject SMTP connections from known abusers
* automatic recognition of local IP addresses
* per-buffer timeouts
* hop counting
@@ -37,18 +37,18 @@ SMTP service (qmail-smtpd):
Queue management (qmail-send):
* instant handling of messages added to queue
* parallelism limit (control/concurrencyremote, control/concurrencylocal)
-* split queue directory---no slowdown when queue gets big
-* quadratic retry schedule---old messages tried less often
+* split queue directory -- no slowdown when queue gets big
+* quadratic retry schedule -- old messages tried less often
* independent message retry schedules
-* automatic safe queueing---no loss of mail if system crashes
+* automatic safe queueing -- no loss of mail if system crashes
* automatic per-recipient checkpointing
* automatic queue cleanups (qmail-clean)
* queue viewing (qmail-qread)
* detailed delivery statistics (qmailanalog, available separately)
Bounces (qmail-send):
-* QSBMF bounce messages---both machine-readable and human-readable
-* HCMSSC support---language-independent RFC 1893 error codes
+* QSBMF bounce messages -- both machine-readable and human-readable
+* HCMSSC support -- language-independent RFC 1893 error codes
* double bounces sent to postmaster
Routing by domain (qmail-send):
@@ -62,22 +62,22 @@ SMTP delivery (qmail-remote):
* RFC 821, RFC 974, RFC 1123
* 8-bit clean
* automatic downed host backoffs
-* artificial routing---smarthost, localnet, mailertable (control/smtproutes)
+* artificial routing -- smarthost, localnet, mailertable (control/smtproutes)
* per-buffer timeouts
-* passive SMTP queue---perfect for SLIP/PPP (serialmail, available separately)
+* passive SMTP queue -- perfect for SLIP/PPP (serialmail, available separately)
Forwarding and mailing lists (qmail-local):
* address wildcards (.qmail-default, .qmail-foo-default, etc.)
* sendmail .forward compatibility (dot-forward, available separately)
* fast forwarding databases (fastforward, available separately)
* sendmail /etc/aliases compatibility (fastforward/newaliases)
-* mailing list owners---automatically divert bounces and vacation messages
-* VERPs---automatic recipient identification for mailing list bounces
-* Delivered-To---automatic loop prevention, even across hosts
+* mailing list owners -- automatically divert bounces and vacation messages
+* VERPs -- automatic recipient identification for mailing list bounces
+* Delivered-To -- automatic loop prevention, even across hosts
* automatic mailing list management (ezmlm, available separately)
Local delivery (qmail-local):
-* user-controlled address hierarchy---fred controls fred-anything
+* user-controlled address hierarchy -- fred controls fred-anything
* mbox delivery
* reliable NFS delivery (maildir)
* user-controlled program delivery: procmail etc. (qmail-command)
diff --git a/BLURB4.md b/BLURB4.md
@@ -3,7 +3,7 @@ it the fastest available message transfer agent. Here's how it stacks up
against the competition in five different speed measurements.
* Scheduling: I sent a message to 8192 ``trash'' recipients on my home
-machine. All the deliveries were done in a mere 78 seconds---a rate of
+machine. All the deliveries were done in a mere 78 seconds -- a rate of
over 9 million deliveries a day! Compare this to the speed advertised
for Zmailer's scheduling: 1.1 million deliveries a day on a
SparcStation-10/50. (My home machine is a 16MB Pentium-100 under BSD/OS,
@@ -11,17 +11,17 @@ with the default qmail configuration. qmail's logs were piped through
accustamp and written to disk as usual.)
* Local mailing lists: When qmail is delivering a message to a mailbox,
-it physically writes the message to disk before it announces success---
+it physically writes the message to disk before it announces success --
that way, mail doesn't get lost if the power goes out. I tried sending a
message to 1024 local mailboxes on the same disk on my home machine; all
the deliveries were done in 25.5 seconds. That's more than 3.4 million
deliveries a day! Sending 1024 copies to a _single_ mailbox was just as
fast. Compare these figures to Zmailer's advertised rate for throwing
-recipients away without even delivering the message---only 0.48 million
+recipients away without even delivering the message -- only 0.48 million
per day on the SparcStation.
* Mailing lists with remote recipients: qmail uses the same delivery
-strategy that makes LSOFT's LSMTP so fast for outgoing mailing lists---
+strategy that makes LSOFT's LSMTP so fast for outgoing mailing lists --
you choose how many parallel SMTP connections you want to run, and qmail
runs exactly that many. Of course, performance varies depending on how
far away your recipients are. The advantage of qmail over other packages
@@ -40,5 +40,5 @@ minutes. End-to-end rate: more than 200000 individual messages a day!
* Overall performance: What really matters is how well qmail performs
with your mail load. Red Hat Software found one day that their mail hub,
a 48MB Pentium running sendmail 8.7, was running out of steam at 70000
-messages a day. They shifted the load to qmail---on a _smaller_ machine,
-a 16MB 486/66---and now they're doing fine.
+messages a day. They shifted the load to qmail -- on a _smaller_ machine,
+a 16MB 486/66 -- and now they're doing fine.
diff --git a/FAQ.md b/FAQ.md
@@ -100,7 +100,7 @@ do I stop that?
Answer: Remove af.mil from /var/qmail/control/locals. If qmail-send is
running, give it a HUP. Make sure the MX is set up properly before you
-do this. Also make sure that pokey can receive mail for af.mil---see
+do this. Also make sure that pokey can receive mail for af.mil -- see
question 3.1.
@@ -537,7 +537,7 @@ qmail-remote leaves it alone for an hour.
7.3. How do I rejuvenate a message? Somebody broke into Eric's computer
again; it's going to be down for at least another two days. I know Eric
-has been expecting an important message---in fact, I see it sitting here
+has been expecting an important message -- in fact, I see it sitting here
in /var/qmail/queue/mess/15/26902. It's been in the queue for six days;
how can I make sure it isn't bounced tomorrow?
@@ -602,7 +602,7 @@ One difficulty is that you can't get a consistent snapshot of the queue
while qmail-send is running. Another difficulty is that messages in the
queue must have filenames that match their inode numbers.
-However, the big problem is that backups---even twice-daily backups---
+However, the big problem is that backups -- even twice-daily backups --
are far too unreliable for mail. If your disk dies, there will be very
little overlap between the messages saved in the last backup and the
messages that were lost.
diff --git a/INSTALL.alias.md b/INSTALL.alias.md
@@ -7,7 +7,7 @@ dot-qmail.0 for the full story.
qmail doesn't have any built-in support for /etc/aliases. If you have a
big /etc/aliases and you'd like to keep it, install the fastforward
package, available separately. /etc/aliases should already include the
-aliases discussed below---Postmaster, MAILER-DAEMON, and root.
+aliases discussed below -- Postmaster, MAILER-DAEMON, and root.
If you don't have a big /etc/aliases, you'll find it easier to use
qmail's native alias mechanism. Here's a checklist of aliases you should
@@ -25,7 +25,7 @@ mail messages to root every night; if you don't have an alias for root,
those messages will bounce. (They'll end up double-bouncing to the
postmaster.) Set up an alias for root in ~alias/.qmail-root. .qmail
files are similar to .forward files, but beware that they are strictly
-line-oriented---see dot-qmail.0 for details.
+line-oriented -- see dot-qmail.0 for details.
* Other non-user accounts. Under qmail, non-user accounts don't get
mail; ``user'' means a non-root account that owns ~account. Set up
@@ -37,4 +37,4 @@ home directories owned by root.
* Default. If you want, you can touch ~alias/.qmail-default to catch
everything else. Beware: this will also catch typos and other addresses
that should probably be bounced instead. It won't catch addresses that
-start with a user name---the user can set up his own ~/.qmail-default.
+start with a user name -- the user can set up his own ~/.qmail-default.
diff --git a/INSTALL.ctl.md b/INSTALL.ctl.md
@@ -6,7 +6,7 @@ qmail does allow quite a bit of easy post-installation configuration. If
you care how your machine greets other machines via SMTP, for example,
you can put an appropriate line into /var/qmail/control/smtpgreeting.
-But this is all optional---if control/smtpgreeting doesn't exist, qmail
+But this is all optional -- if control/smtpgreeting doesn't exist, qmail
will do something reasonable by default. You shouldn't worry much about
configuration right now. You can always come back and tune things later.
@@ -28,8 +28,8 @@ config also looks up your local IP addresses in DNS to decide which
hosts to accept mail for.
(Why doesn't qmail do these lookups on the fly? This was a deliberate
-design decision. qmail does all its local functions---header rewriting,
-checking if a recipient is local, etc.---without talking to the network.
+design decision. qmail does all its local functions -- header rewriting,
+checking if a recipient is local, etc. -- without talking to the network.
The point is that qmail can continue accepting and delivering local mail
even if your network connection goes down.)
diff --git a/INSTALL.maildir.md b/INSTALL.maildir.md
@@ -4,8 +4,8 @@ mbox format to a new format, maildir.
1. The trouble with mbox
-The mbox format---the format of ~user/Mailbox, understood by BSD Mail
-and lots of other MUAs---is inherently unreliable.
+The mbox format -- the format of ~user/Mailbox, understood by BSD Mail
+and lots of other MUAs -- is inherently unreliable.
Think about it: what happens if the system crashes while a program is
appending a new message to ~user/Mailbox? The message will be truncated.
@@ -18,7 +18,7 @@ Other formats, such as mh folders, are just as unreliable.
qmail supports maildir, a crashproof format for incoming mail messages.
maildir is fast and easy for MUAs to use. Even better, maildir works
-wonders over NFS---see below.
+wonders over NFS -- see below.
I don't want to cram maildir down people's throats, so it's not the
default. Nevertheless, I encourage you to start asking for maildir
@@ -29,7 +29,7 @@ you can.
2. Sun's Network F_ail_u_re System
Anyone who tells you that mail can be safely delivered in mbox format
-over NFS is pulling your leg---as explained above, mbox format is
+over NFS is pulling your leg -- as explained above, mbox format is
inherently unreliable even on a single machine.
Anyway, NFS is the most unreliable computing environment ever invented,
@@ -39,7 +39,7 @@ You should switch to maildir, which works fine over NFS without any
locking. You can safely read your mail over NFS if it's in maildir
format. Any number of machines can deliver mail to you at the same time.
(On the other hand, for efficiency, it's better to get NFS out of the
-picture---your mail should be delivered on the server that contains your
+picture -- your mail should be delivered on the server that contains your
home directory.)
Here's how to set up qmail to use maildir for your incoming mail:
diff --git a/INSTALL.mbox.md b/INSTALL.mbox.md
@@ -49,5 +49,5 @@ all your mail software to look at ~user/Mailbox directly:
Some vendors, in a misguided attempt to solve the security problems of
/var/spool/mail, have made all their mail software setgid mail. After
-you move the mailboxes, you can---and, for security, should---remove
+you move the mailboxes, you can -- and, for security, should -- remove
those setgid-mail bits.
diff --git a/INTERNALS.md b/INTERNALS.md
@@ -118,8 +118,8 @@ If the computer crashes while qmail-queue is trying to queue a message,
or while qmail-send is eliminating a message, the message may be left in
state S2 or S3.
-When qmail-send sees a message in state S2 or S3---other than one
-it is currently eliminating!---where mess/457 is more than 36 hours old,
+When qmail-send sees a message in state S2 or S3 -- other than one
+it is currently eliminating! -- where mess/457 is more than 36 hours old,
it deletes intd/457 if that exists, then deletes mess/457. Note that any
qmail-queue handling the message must be dead.
@@ -134,7 +134,7 @@ acknowledges successful receipt of the message? The client must assume
the worst and send the message again. Similarly, if the computer crashes
just before qmail-send marks a message as DONE, the new qmail-send must
assume the worst and send the message again. The usual solutions in the
-database literature---e.g., keeping log files---amount to saying that
+database literature -- e.g., keeping log files -- amount to saying that
it's the recipient's computer's job to discard duplicate messages.)
diff --git a/SECURITY.md b/SECURITY.md
@@ -1,5 +1,5 @@
Background: Every few months CERT announces Yet Another Security Hole In
-Sendmail---something that lets local or even remote users take complete
+Sendmail -- something that lets local or even remote users take complete
control of the machine. I'm sure there are many more holes waiting to be
discovered; sendmail's design means that any minor bug in 46000 lines of
code is a major security risk. Other popular mailers, such as Smail, and
@@ -60,8 +60,8 @@ run as root.
4. Move separate functions into mutually untrusting programs.
-Five of the qmail programs---qmail-smtpd, qmail-send, qmail-rspawn,
-qmail-remote, and tcp-env---are not security-critical. Even if all of
+Five of the qmail programs -- qmail-smtpd, qmail-send, qmail-rspawn,
+qmail-remote, and tcp-env -- are not security-critical. Even if all of
these programs are completely compromised, so that an intruder has
control over the qmaild, qmails, and qmailr accounts and the mail queue,
he still can't take over your system. None of the other programs trust
@@ -82,7 +82,7 @@ files or start any other programs as root.)
I have discovered that there are two types of command interfaces in the
world of computing: good interfaces and user interfaces.
-The essence of user interfaces is _parsing_---converting an unstructured
+The essence of user interfaces is _parsing_ -- converting an unstructured
sequence of commands, in a format usually determined more by psychology
than by solid engineering, into structured data.
diff --git a/THOUGHTS.md b/THOUGHTS.md
@@ -56,7 +56,7 @@ 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
+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
@@ -65,7 +65,7 @@ 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---
+place. Sun's original map -- root to nobody, everyone else left alone --
is, as far as I can tell, always wrong.
@@ -153,7 +153,7 @@ 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!
+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
@@ -252,7 +252,7 @@ multiple RCPTs per SMTP aren't an ``efficiency feature''; they're a
_slowness_ feature. Separate SMTP transactions have much lower latency.
I've heard three complaints about bandwidth use from masochists sending
-messages through a modem through a smarthost to thousands of users---
+messages through a modem through a smarthost to thousands of users --
without sublists! They can get much better performance with QMQP.
In the opposite direction: It's tempting to remove the @host part of the
@@ -347,7 +347,7 @@ Minimum number of disk blocks: Yes, via tunefs -m. (Or quotas; the right
setup has qmailq with a small quota, qmails with a larger quota, so that
qmail-send always has room to work.)
-Checkpointing: Yes, but not configurable---qmail always checkpoints.
+Checkpointing: Yes, but not configurable -- qmail always checkpoints.
Error message configuration: Nope.
