CTM_RMAIL(1)

NAME
ctm_rmail - send and receive ctm deltas via mail

SYNOPSIS
ctm_rmail [-Dfuv] [-l log] [-p piecedir] [-d deltadir] [-b basedir] [file ...]

DESCRIPTION
The ctm_rmail program is used (either manually or automatically) to decode and reassemble the delta, and optionally call ctm to apply it to the source tree.

Command line arguments for ctm_rmail:

-l log
    Instead of appearing on stderr, error diagnostics and informational messages (other than command line errors) are time stamped and written to the file log.

-p piecedir
    Collect pieces of deltas in this directory. Each piece corresponds to a single mail message. Pieces are removed when complete deltas are built. If this flag is not given, no input files will be read, but completed deltas may still be applied with ctm if the -b flag is given.

-d deltadir
    Collect completed deltas in this directory. Deltas are built from one or more pieces when all pieces are present.

-b basedir
    Apply any completed deltas to this source tree. If this flag is not given, deltas will be stored, but not applied. The user may then apply the deltas manually, or by using ctm_rmail without the -p flag. Deltas will not be applied if they do not match the .ctm_status file in basedir (or if .ctm_status does not exist).

-D  Delete deltas after successful application by ctm. It is probably a good idea to avoid this flag (and keep all the deltas) as ctm has the ability to recover small groups of files from a full set of deltas.

-f  Fork and execute in the background while applying deltas with ctm. This is useful when automatically invoking ctm_rmail from sendmail because ctm can take a very long time to complete, causing other people's mail to be delayed, and can in theory cause spurious mail retransmission due to the remote sendmail timing out, or even termination of ctm_rmail by mail filters such as MH's slocal. Don't worry about zillions of background ctm processes loading your machine, since locking is used to prevent more than one ctm invocation at a time.

-u  Pass the -u flag to the ctm command when applying the complete deltas, causing it to set the modification time of created and modified files to the CTM delta creation time.

-v  Pass the -v flag to the ctm command when applying the complete deltas, causing a more informative output. All ctm output appears in the ctm_rmail log file.

The file arguments (or stdin, if there are none) are scanned for delta pieces. Multiple delta pieces can be read from a single file, so an entire maildrop can be scanned and processed with a single command.

It is safe to invoke ctm_rmail multiple times concurrently (with different input files), as might happen when sendmail is delivering mail asynchronously. This is because locking is used to keep things orderly.

FILE FORMAT
Following are the important parts of an actual (very small) delta piece:

    From: owner-src-cur
    To: src-cur
    Subject: ctm-mail src-cur.0003.gz 1/4
    CTM_MAIL BEGIN src-cur.0003.gz 1 4
    H4sIAAAAAAACA3VU72/bNhD9bP0VByQoEiyRSZEUSQP9kKTeYCR2gDTdsGFAwB/HRogtG5K8NCj6
    v4+UZSdtUQh6Rz0eee/xaF/dzx8up3/MFlDkBNrGnbttAwyo1pxoRgoiBNX/QJ5d3c9/X8DcPGGo
    lggkPiXngE4W1gUjKPJCYyk5MZRbIqmNW/ASglIFcdwIzTUxaAqhnCPcBqloKEkJVNDMF0Azk+Bo
    dDzzk0Ods/+A5gXv9YyJHjMCtJwQNeESNma7hOmXDRxn
    CTM_MAIL END 61065

The subject of the message always begins with “ctm-mail” followed by the name of the delta, which piece this is, and how many total pieces there are. The data are bracketed by “CTM_MAIL BEGIN” and “CTM_MAIL END” lines, duplicating the information in the subject line, plus a simple checksum.

If the delta exceeds maxctmsize, then a message like this will be received instead:

    From: owner-src-cur
    To: src-cur
    Subject: ctm-notice src-cur.0999.gz
    src-cur.0999.gz is 792843 bytes.  The limit is 300000 bytes.
    You can retrieve this delta via ftpmail, or your good mate at the university.

You are then on your own!

EXAMPLES
To decode every ctm(1) message in your mailbox, assemble them into complete deltas, then apply any deltas built or lying around, you could use:

    ctm_rmail -p ~/pieces -d ~/deltas -b /usr/ctm-src-cur $MAIL

(Note that no messages are deleted by ctm_rmail. Any mail reader could be used for that purpose.)

To create a mail alias called receiver-dude that will automatically decode and assemble deltas, but not apply them, you could put the following lines in your /etc/aliases file (assuming the /ctm/tmp and /ctm/deltas directories and /ctm/log file are writable by user “daemon” or group “wheel”):

    receiver-dude: "|ctm_rmail -p /ctm/tmp -d /ctm/deltas -l /ctm/log"
    owner-receiver-dude: real_dude@wherever.you.like

The second line will catch failures and drop them into your regular mailbox, or wherever else you like.

To apply all the deltas collected, and delete those applied, you could use:

    ctm_rmail -D -d /ctm/deltas -b /ctm/src-cur -l /ctm/apply.log

For maximum flexibility, consider this excerpt from a procmail script:

    PATH=$HOME/bin:$PATH
    :0 w
    * ^Subject: ctm-mail cvs-cur
    | ctm_incoming

together with the shell script ~/bin/ctm_incoming:

    #! /bin/sh
    PATH="$HOME/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin"
    export PATH
    cd $HOME/ctm && ctm_rmail -f -p pieces -d deltas -l log -b /ctm

which will deposit all ctm deltas in ~/ctm/deltas, apply them to the tree in /ctm, and drop any failures into your regular mail box. Note the PATH manipulation in ctm_incoming which allows ctm_rmail to execute ctm(1) on the (non-OpenBSD) machine that this example was taken from.

SECURITY
If you automatically take your mail and pass it to a file tree patcher, you might think you are handing the keys to your system to the crackers! Happily, the window for mischief is quite small. ctm_rmail is careful to write only to the directories given to it (by not believing any “/” characters in the delta name), and the latest ctm disallows absolute pathnames and “..” in files it manipulates, so the worst you could lose are a few source tree files (recoverable from your deltas). Since ctm requires that a md5 checksum match before it touches a file, only fellow source recipients would be able to generate a fake delta, and they're such nice folk that they wouldn't even think of it! :-)

Even this possibility could be removed by using cryptographic signatures. A possible future enhancement would be to use PGP to provide a secure wrapper.

ENVIRONMENT
If deltas are to be applied then ctm(1) and gunzip(1) must be in your PATH.

FILES

QUEUEDIR/*
    Pieces of deltas encoded as mail messages waiting to be sent to the mailing list.

PIECEDIR/*
    Pieces of deltas waiting for the rest to arrive.

DELTADIR/*
    Completed deltas.

BASEDIR/.ctm_status
    File containing the name and number of the next delta to be applied to this source tree.

DIAGNOSTICS
ctm_rmail returns exit status 0 for success, and 1 for various failures. ctm_rmail is expected to be called from a mail transfer program, and thus signals failure only when the input mail message should be bounced (preferably into your regular maildrop, not back to the sender). In short, failure to apply a completed delta with ctm is not considered an error important enough to bounce the mail, and ctm_rmail returns an exit status of 0.

ctm_rmail will report messages like:

    ctm_rmail: src-cur.0250.gz 1/2 stored
    ctm_rmail: src-cur.0250.gz 2/2 stored
    ctm_rmail: src-cur.0250.gz complete

If any of the input files do not contain a valid delta piece, ctm_rmail will report:

    ctm_rmail: message contains no delta

and return an exit status of 1. You can use this to redirect wayward messages back into your real mailbox if your mail filter goes wonky.

These messages go to stderr or to the log file. Messages from ctm turn up here too. Error messages should be self explanatory.

SEE ALSO
ctm(1), ctm(5)

http://www.openbsd.org/ctm.html

AUTHOR
Stephen McKay <syssgm@devetir.qld.gov.au>