untitled(July 10, 2017)

NAME
postconfirm - Mail confirmation system

SYNOPSIS
postconfirmc [-h] [--stop] [--socket SOCKET]
[{ confirm | dmarc-rewrite | dmarc-reverse }]

postconfirmd [options]

DESCRIPTION
postconfirm consists of postconfirmd, which is the long-running (daemon) part, and postconfirmc, which is the client part of a client-server program which handles email confirmations. It is intended as a front-end to mailing lists. It provides funcitonality which is a subset of TMDA, but is adapted to high-volume usage and does not have anywhere near all the bells and whistles which TMDA has. On the other hand, since the whitelist lookup is done by the long-running server part, the overhead of doing a verification that a poster has a confirmed address is much smaller than for TMDA.

Early tests indicate that with a whitelist of 16000 entries a lookup costs about 0.01 seconds and about ~5 Mbytes for the server daemon, in contrast whith TMDA which cost between ~10s and ~600s and ~98 Mb *per lookup* as it was set up in front of the IETF lists.

ACTIONS
confirm (the default action):

Somewhat simplified, the flow for regular mail is as follows:

     mail agent
         |
         v
     postconfirm/mailman wrapper [copy] -> cached in cache dir
         |
         v
     postconfirmc <==> postconfirmd
         |
         v
     postconfirm/mailman wrapper [white] -> Mailman
       [grey]
         |
         v
     (waiting for confirmation)
In the start of the flow above, a message comes in. If the envelope From is in the lists known by postconfirmd, it is passed through the mailman/ postconfirm wrapper, where postconfirmc is called to talk with postconfirmd and get either an OK to pass the message to Mailman, or cache it.

In more detail, this is the sequence of actions that postconfirm goes through when processing an incoming email message:

1.  The mail is put in the cache directory.

2.  If the message is a delivery-status report (content-type multipart/report, report-type delivery-status) then this is logged, and no further action is taken.

3.  If the precedence matches the bulk_regex setting in the configuration file, then:

    a. if the envelope sender is in the whitelist or the white_regex list, then the message is forwarded directly.

    b. if not, the receipt of a bulk message is logged, and no further action is taken.

4.  If the message has an auto-submitted header, and the value matches the auto_submitted_regex in the configuration file, then:

    a. if the envelope sender is in the whitelist or the white_regex list, then the message is forwarded directly.

    b. if not, the receipt of a bulk message is logged, and no further action is taken.

5.  If the subject matches the regex for postconfirm's confirmation email subject, the confirmation is processed, and then:

    a. if the confirmation is valid, the held message is forwarded, and the confirmed address is added to the whitelist.

    b. if not, the failed confirmation is logged, and the message is saved.

6.  If the envelope sender is in the whitelist or the white_regex list, the message is forwarded.

7.  If there was no match earlier, a confirmation request is sent out for the message.

dmarc-rewrite:

For use with mailing lists, aliases, etc., where the presence of strict dmarc rules will prevent acceptance of the list messages unless rewriting is done.

dmarc-reverse:

The inverse operation of dmarc-rewrite. Undoes the rewrite, and replaces the rewritten address with the original address.

OPTIONS
{ confirm | dmarc-rewrite | dmarc-reverse } the action to take

-h, --help
    show this help message and exit

--stop
    stop the postconfirmd daemon

--socket SOCKET
    use the given SOCKET for client-daemon communication

FILES
postconfirmd reads its configuration from the following files (if found), in the given order:

      <bin-dir>/postconfirm.conf
      /etc/postconfirm.conf
      /etc/postconfirm/postconfirm.conf
      ~/.postconfirmrc
where <bin-dir> is the directory where postconfirmd is installed.

AUTHOR
Written by Henrik Levkowetz, <henrik@merlot.tools.ietf.org>. Uses the daemonize module from Chad J. Schroeder, from the Python Cookbook at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/278731, and the readyexec module from Frank J. Tobin, available at http://readyexec.sourceforge.net/.

COPYRIGHT
Copyright 2008-2017 Henrik Levkowetz

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. There is NO WARRANTY; not even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.