EN JA
CTM_MAIL(1)
CTM_MAIL(1) FreeBSD General Commands Manual CTM_MAIL(1)

名称

ctm_smail, ctm_dequeue, ctm_rmailメールを介して ctm(1) のデルタを送信して受信する

書式

ctm_smail [ -l log][ -m maxmsgsize][ -c maxctmsize][ -q queue-dir] ctm-delta mail-alias

ctm_dequeue [ -l log][ -n numchunks] queue-dir

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

解説

ctm(1) コマンドに関連して、 ctm_smail, ctm_dequeuectm_rmail は、メールを介してソースツリーへの変更を配布するために使用されます。 ctm_smail ユーティリティには、圧縮された ctm デルタとそれを送信するメーリングリストが与えられます。それは、デルタを管理できる単位に分割して、メールメッセージとしてそれらをエンコードし、メーリングリストに送信します (状況に応じて、メールの負荷を分散するためにキューに入れられます)。各受信者は、デルタをデコードして、再構築するために (手動または自動的に) ctm_rmail を使用し、状況に応じてソースツリーにそれを適用するために ctm を呼び出します。現在、いくつかのソースツリーが配布され、いくつかのサイトにあります。これらは、 freefall.FreeBSD.org によって配布される FreeBSD-current のソースと CVS ツリーを含んでいます。

ctm_smail のためのコマンド行引数は、次の通りです:

-l log
stderr に出力する代わりに、(コマンド行のエラー以外の) エラー診断と情報メッセージは、タイムスタンプを付けてファイル log に書き込まれます。
-m maxmsgsize
ctm_smail が送信できるメールメッセージの最大サイズを制限します。メールヘッダと他の細部は、この制限にカウントされないので、大体の値です。指定されないなら、うわさされた 64k のメール制限の前にヘッダの 1535 バイトの余地を残して、64000 バイトをデフォルトとします。
-c maxctmsize
送信されるデルタの最大サイズを制限します。この制限より大きいデルタは、謝罪メールメッセージがメーリングリストに送信されます。これは、ユーザのメールボックスが大きくなるという大規模な変化を防ぐためです。これは、エンコードする前のサイズであることに注意してください。エンコードによって、メールヘッダが追加される前の 4/3 のサイズに増加します。指定されないなら、制限は、ありません。
-q queue-dir
現在、デルタの断片をメールする代わりに、 ctm_dequeue を使用して、後でメールされるように与えられたディレクトリに、それらを格納します。この機能によって、大きなデルタのメールは、制限されたネットワーク回線容量または小さなメールスプール領域しかない受信者への影響を抑えるために、数時間から数日にわたってメールを広範囲に送り続けることができます。

ctm-delta は、送信されるデルタで、 mail-alias は、デルタを送信するメーリングリストです。メールメッセージは、 sendmail(8) を使用して送信されます。

ctm_dequeue: のためのコマンド行引数は、次の通りです:

-l log
stderr に出力する代わりに、(コマンド行のエラー以外の) エラー診断と情報メッセージは、タイムスタンプを付けてファイル log に書き込まれます。
-n numchunks
ctm_dequeue の実行単位ごとに送信されるメールメッセージの数を制限します。デフォルトで、 ctm_dequeue は、実行単位ごとに 1 つのメールメッセージを送信します。

queuedir は、 ctm_smail によって格納されたメールメッセージを含むディレクトリです。 numchunks まで、メールメッセージは、実行ごとに送信されます。受信者のメーリングリストは、キューに入れられたファイルで既にエンコードされています。

ctm_smail がキューにエントリを追加している間、または ctm_smail を同時に複数の回実行することさえ、 ctm_dequeue を実行することは、安全ですが、配布される各ツリーごとに、別々のキューディレクトリを使用するべきです。これは、エントリが、アルファベット順に処理され、デルタの作成時刻でなく、デルタ名に基づいて、1 つのツリーが、他のものより前に不公平に処理されるからです。

ctm_rmail のためのコマンド行引数は、次の通りです:

-l log
stderr に出力する代わりに、(コマンド行のエラー以外の) エラー診断と情報メッセージは、タイムスタンプを付けてファイル log に書き込まれます。
-p piecedir
このディレクトリにデルタの断片を集めます。各断片は、単一のメールメッセージに対応しています。断片は、完全なデルタを構築するとき、削除されます。このフラグが与えられないなら、入力ファイルは、読み込まれませんが、完全なデルタは、 -b フラグが与えられるなら、それでも ctm で適用されます。
-d deltadir
このディレクトリに完全なデルタを集めます。デルタは、すべての断片が存在しているとき、1 つ以上の断片から構築されます。
-b basedir
このソースツリーに完全なデルタを適用します。このフラグが与えられないなら、デルタは、格納されますが適用されません。次に、ユーザは、手動、または -p フラグなしの ctm_rmail を使用することによってデルタを適用できます。デルタは、 basedir.ctm_status ファイルにマッチしないなら、(または、 .ctm_status が存在していないなら)、適用されません。
-D
ctm によって適用が成功した後に、デルタを削除します。 ctm には、デルタのフルセットから、ファイルの小さなグループを回復させる能力があるので、このフラグを避けて (すべてのデルタを保つ) ことは、たぶんよい考えです。
-f
ctm でデルタを適用している間に、バックグラウンドで fork して、 execute (実行) します。 ctm は、完了するためにる非常に長い時間かかり、他の人々のメールを遅らせ、理論的に、リモートの sendmail のタイムアウトのために、誤ったメールの再転送を引き起こす、または MHslocal のようなメールフィルタによって ctm_rmail の終了さえ引き起こすかもしれないので、 sendmail から ctm_rmail を自動的に呼び出すとき、これは役に立ちます。ロックが、一度に 2 つ以上の ctm 呼び出しを防ぐために使用されるので、利用者のマシンに無数のバックグラウンド ctm プロセスをロードすることを心配する必要はありません。
-u
完全なデルタを適用するとき、 -u フラグを ctm コマンドに渡すことによって、作成され更新されたファイルの更新時刻を CTM のデルタ作成時刻に設定します。
-v
完全なデルタを適用するとき、 -v フラグを ctm コマンドに渡すことによって、より有益な出力を行います。すべての ctm 出力は、 ctm_rmail ログファイルに行われます。

ファイル引数 (または、なにもなければ、 stdin) は、デルタの断片のためにスキャンされます。単一ファイルから複数のデルタの断片を読み込むことができるので、単一のコマンドで全体のメールドロップ (メール受け) をスキャンして、処理することができます。

sendmail がメールを非同期に配信されるとき、起こるように、 (異なった入力ファイルで) 同時に複数回 ctm_rmail を呼び出しても安全です。これは、ロックが処理を順序正しく保つために使用されるからです。

ファイル形式

次は、実際の (非常に小さい) デルタの断片の重要な部分です:

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

メッセージの subject は、常に“ctm-mail”で始まり、デルタの名前、これがどの断片か、そして、合計の断片がいくつあるか、が続きます。データは、“CTM_MAIL BEGIN”と“CTM_MAIL END”行によって囲まれ、重複した subject 行の情報、と簡単なチェックサムです。

デルタが maxctmsize を超えているなら、代わりに次のようなメッセージを受け取ります:

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 ftp.

こうなれば、利用者は、自分自身で、取得します!

環境変数

デルタを適用するつもりなら、 ctm(1)gunzip(1) が、利用者の PATH になければなりません。

関連ファイル

QUEUEDIR/*
メーリングリストに送信されることになり待っている、メールメッセージとしてエンコードされたデルタの断片。
PIECEDIR/*
残りが到着するのを待っているデルタの断片。
DELTADIR/*
完全なデルタ。
BASEDIR/.ctm_status
このソースツリーに適用されることになっている次のデルタの名前と番号を含んでいるファイル。

終了ステータス

ctm_smail, ctm_dequeuectm_rmail ユーティリティは、成功すれば終了ステータス 0 を返し、様々な失敗に対して 1 を返します。 ctm_rmail ユーティリティは、メール転送プログラムから呼び出されると予想され、したがって、入力メールメッセージが返信されるべきであるときだけ、 (できれば、送信者に戻さないで、利用者の通常のメールドロップ (メール受け) に) 失敗のシグナルを生成します。要するに、 ctm で完全となったデルタを適用できなかったことは、メールを返信するのに十分重要なエラーであることは見なされず、 ctm_rmail は、0 の終了ステータスを返します。

使用例

メールサイズをおよそ 60000 バイトに制限して、 src-guys として sendmail に認識されている素晴らしいコードハッカーのグループに、 src-cur のデルタ 32 を送信するために、利用者は、次を使用できます:

ctm_smail -m 60000 /wherever/it/is/src-cur.0032.gz src-guys

利用者のメールボックスにあらゆる ctm-mail メッセージをデコードするために、完全なデルタにそれらを組み立てて、次に、構築されるか、またはその辺にあるデルタを適用するために、次を使用できます:

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

(メッセージは、 ctm_rmail によって削除されないことに注意してください。そのために任意のメールリーダを使用できるはずです。)

自動的にデルタをデコードして組み立てますが、それらを適用しない、 receiver-dude と呼ばれるメールエイリアス (別名) を作成するために、利用者は、 /etc/mail/aliases ファイルに次の行を入れることができます ( /ctm/tmp/ctm/deltas ディレクトリと /ctm/log は、ユーザ daemon またはグループ wheel によって書き込み可能であることを、仮定しています):

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

2 番目の行は、失敗を捕らえて、それらを利用者の通常のメールボックスか、または利用者の好きなところに、書き込みます。

集められたすべてのデルタを適用し、適用されたものを削除するために、次を使用できます:

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

最大の柔軟性のためには、 procmail スクリプトから次の引用を考慮してみてください:

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

次のシェルスクリプト ~/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

これは、すべての ctm デルタを ~/ctm/deltas に置き、それらを /ctm のツリーに適用し、失敗したものを利用者の通常のメールボックスに書き込みます。 ctm_incoming での PATH 操作によって、 ctm_rmail は、この例を取って来た ( FreeBSD でない) マシンで ctm(1) を実行することができることに、注意してください。

セキュリティ

そのままでは、CTM は、安全でないプロトコルです - ソースコードに適用された変更が、信頼されているところから送信されたことを確認する認証はありません、それで、CTM デルタが、通常のメールのような認証されていない媒体を通して得られるなら、注意が払われなければなりません。正規のものを置き換えるか、または優先するため、および利用者のソースツリーに悪意のあるコードを挿入するために、攻撃者が、CTM デルタを偽造することは比較的簡単なことです。正規のデルタが到着することをどうにかして防がれるなら、これは、後のデルタが、MD5 チェックサムが失敗する時点で、同じファイルを変更することを試みるまで、見つからずに済みます。

この安全でない状態を改善するために、FreeBSD.org によって生成された CTM デルタの断片は、/usr/ports/security/gpg と Pretty Good Privacy v5 ユーティリティ /usr/ports/security/pgp5 で利用可能な、 GNU Privacy Guard ユーティリティと互換性のある形式で暗号化して署名されます。 ctm@FreeBSD.org を finger することによって、関連した公開鍵を取得することができます。

攻撃者が、このようにして署名された CTM デルタを、検知できないように変更することはできません。したがって、電子メールを通して CTM デルタを受信するなら、署名を確認するために GPG または PGP5 を使用することはお勧めです。

診断

通常の操作では、 ctm_smail は、次のようにメッセージを報告します:

ctm_smail: src-cur.0250.gz 1/2 sent to src-guys

またh、キューに入れられているなら、

ctm_smail: src-cur.0250.gz 1/2 queued for src-guys

ctm_dequeue ユーティリティは、次のようにメッセージを報告します:

ctm_dequeue: src-cur.0250.gz 1/2 sent

ctm_rmail ユーティリティは、次のようにメッセージを報告します:

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

入力ファイルのいずれも有効なデルタの断片を含んでいななら、 ctm_rmail は、次のように報告します:

ctm_rmail: message contains no delta

そして、1 の終了ステータスを返します。利用者のメールフィルタが不安定になるなら、利用者の実際のメールボックスに気まぐれなメッセージをリダイレクトするために、これを使用することができます。

これらのメッセージは、 stderr または、ログファイルに出力します。 ctm(1) からのメッセージもここに現れます。エラーメッセージは、それ自体で説明されるべきです。

関連項目

ctm(1), ctm(5)

作者

Stephen McKay <mckay@FreeBSD.org>
January 24, 1995 FreeBSD