Clarify docs.

README

@@ -42,7 +42,7 @@ Quick Installation
 1. Build and install Sendmail, enabling libmilter (see libmilter/README).
 2. Build and install Python, enabling threading.
 3. Install this module: python setup.py --help
-4. Add these two lines to sendmail.cf:
+4. Add these two lines to sendmail.cf[*]:
 
 O InputMailFilters=pythonfilter
 Xpythonfilter,        S=local:/home/username/pythonsock
@@ -55,6 +55,13 @@ some email will be rejected (see the "header" method).  Edit and play.
 See spfmilter.py for a functional SPF milter, or see bms.py for an complex
 milter used in production.
 
+[*] This is for a quick test.  Your sendmail.cf in most distros will get
+overwritten whenever sendmail.mc is updated.  To make a milter permanent,
+add something like:
+
+INPUT_MAIL_FILTER(`pythonfilter', `S=local:/home/username/pythonsock, F=T, T=C:5m;S:20s;R:5m;E:5m')
+
+to sendmail.mc instead.
 
 Not-so-quick Installation
 -------------------------
@@ -91,8 +98,10 @@ some options associated with it.  In this case, we have the "S" option, which
 names the socket that sendmail will use to communicate with this particular
 milter.  This milter's socket is a unix-domain socket in the filesystem.
 See libmilter/README for the definitive list of options.
+
 NB: The name is specified in two places: here, in sendmail's cf file, and
 in the milter itself.  Make sure the two match.
+
 NB: The above lines can be added in your .mc file with this line:
 
 INPUT_MAIL_FILTER(`pythonfilter', `S=local:/home/username/pythonsock')

TODO

+Don't match dynamic ptr in bestguess.
+
+When content filtering is not installed, reject BLACKLISTed MFROM
+immediately.  There is no use waiting until EOM.
+
 Configuration is problematic when handling incoming, but not outgoing mail.
 The problem comes when alice@example.com sends mail to bill@example.com,
 and we are the MX for example.com, but alice is sending from some other
@@ -7,6 +12,9 @@ CBV, we get "fraudulent MX", because the MX is ourself!  So we need to
 avoid doing CBV on such domains.  Currently, we try to make sure the SPF
 policies don't do CBV.
 
+We now don't check internal domains for incoming mail if there is an
+SPF record.
+
 On the other hand, if alice is sending internally, or with SMTP AUTH, she
 *does* need the domain to be in internal_domains.  The solution to that 
 is to use the new SMTP AUTH access configuration to specify which domains