My Understanding Of How UCE Actually Works

         My Understanding Of How UCE Actually Works
	     v1.2, [email protected] 20010111
     http://www.mengwong.com/misc/postfix-uce-guide.txt

   http://www.postfix.org/uce.html exhaustively describes
   the syntax and semantics of several configuration
   options, but not their pragmatics.  How come
   configuration values can appear in multiple places?  What
   does it mean when they do?

Let's start by getting some preliminaries out of the way
before we move on to discussing the more complex UCE
restriction options.

First, a dress code requirement.  If the smtp client fails
either of the following variables, it's thrown out.

        smtpd_helo_required = yes/no
    strict_rfc821_envelopes = yes/no

The header_checks and body_checks variables define regexp
lookup table maps, which we'll look at later.

    header_checks = maptype:mapname (usually regexp.)
      body_checks = maptype:mapname (usually regexp.)

Maps are lookup tables.  Postfix supports several kinds of
maps (hash and regexp are the most common; see postconf -m),
and uses them for several functions, including alias maps
(which rewrite one address into another), transport maps
(which specify a transport for a given address), and access
maps, which tell postfix whether to permit or deny a given
smtp transaction, and can do other things besides --- things
weird and wonderful, such as recursively calling other
restriction lists, but I'm getting ahead of myself.

The meat of postfix's UCE configurations are found in
parameters that are all named smtpd_*_restrictions.

Access maps are one possible kind of smtpd restriction.
there are others.

Think of a restriction as a function that returns one of OK,
REJECT, or DUNNO.  If you're reminded of router access-lists,
good: you've recognized the pattern.  Some restrictions only
return OK or DUNNO, some return only REJECT or DUNNO, and some
are empowered to return a verdict either way.  If the
restriction doesn't have a strong feeling one way or the
other, it just returns a DUNNO, and postfix goes on to
evaluate the next restriction.  All restrictions may DUNNO
except check_relay_domains, which has to return either OK or
REJECT.  For that reason people generally set it as the last
restriction to be evaluated.

The restrictions are grouped into lists and evaluated in
order within each list.

If the restriction returns either OK or REJECT, the
list short-circuits and immediately concludes with that
value.

If a list concludes in REJECT, the smtp client will be denied.

The default result for all lists is OK.

Here's a symbolic representation:

  listA { r0; r1; r2;                     }
  listB {         r2; r3; r4;             }
  listC { r0;     r2; r3; r4; r5; r6;     }
  listD {         r2;         r5; r6; r7; }

Note that later lists have access to more and more
restrictions:

  listA may run                      r0, r1, and r2.
  listB may run all of listA's, plus r3 and r4.
  listC may run all of listB's, plus r5 and r6.

>>> Why "plus all of the previous list's restrictions"?

  We'll get to that later.  For now just keep in mind that
  each list has certain restrictions that belong to it; in
  addition to those, it can run other restrictions that
  belong to the preceding lists.

>>> So, what are the lists really called?

  listA:  smtpd_client_restrictions
  listB:  smtpd_helo_restrictions
  listC: