http://www.sendmail.org/m4/features.html
FEATURE 定義
良く使う様々の機能については、
"FEATURE" 定義を使って指定します。
たとえば、.mc ファイルで、
FEATURE(`use_cw_file')
という行を書くと、sendmail にクラス {w} の値として
/etc/mail/local-host-names というファイルを読むように指定することが出来ます。
FEATURE には、引数を 9 個まで追加することが出来ます。
引数は、例えば次のように指定します。
FEATURE(`mailertable', `dbm /usr/lib/mailertable')
(訳注: 上で dbm と指定していますが、これに関連して)
表機能用のデータベースの形式の既定値を、
define(`DATABASE_MAP_TYPE', `dbm')
のように設定できます。
この例では、(dbm と書いてありますが)
ndbm データベースを使用するように指定しています。
この設定がなければ、つまり既定では、
Berkeley DB のハッシュ化したデータベース形式 (hash) を意味します。
FEATURE に何か引数を指定したい場合には、
データベースの形式指定の宣言も必要なことに注意してください。
上記例の define('DATABASE_MAP_TYPE'...) の設定は、
FEATURE に何も引数の指定がない場合にのみ参照されます。
また、マップを使用するどの機能よりも前に指定する必要があります。
FEATURE で
設定可能な機能を以下に挙げます。
- use_cw_file
-
自分の機械の別名を /etc/mail/local-host-names ファイルから読みます。
他の機械に対するメールを自分の機械で受信するように
MX をこの機械に向けているような場合で、
宛先の機械の名前が変動するような場合に用いることができます。
MX をこの機械に向けていても、
機械の名前が固定的に決まっている時には、むしろ、
"Cw<name1> <name2> ..." (ここで、ホスト名には
FQDN を指定します) という行を記述するのがよいでしょう。
実際のファイル名は、
confCW_FILE
を設定すれば変更出来ます。
- use_ct_file
-
"信頼された" ユーザのユーザ名を、
/etc/mail/trusted-users ファイルから読みます。
信頼されたユーザ (Trusted user) とは、
-f オプションで envelope from
アドレスを設定しても警告メッセージを出されることがないようにするユーザです。
実際のファイル名は、confCT_FILE の設定によって変更可能です。
- redirect
- "address.REDIRECT" 宛てのすべてのメールについて、
``551 User has moved; please try <address>''
というメッセージとともに拒否します。この機能は、
いなくなってしまった人たちの新しいアドレスの末尾に ".REDIRECT" をつ
けたものを alias に指定するようにして利用します。
- nouucp
- UUCP アドレスの配送をしません。引数は次の二つです。
- `reject'
- @ の左側(local part)に
"!" がついたアドレスが、
転送を許可されたシステムから出されたものでない場合には、拒否します。
- `nospecial'
- "!" を含む宛先について、特別な処理を一切しません。
注意:
- 「SPAM 対策用設定」の章の NOTICE を参照のこと。
- `reject' を指定した場合には、"!" を OperatorChars
から削除してはいけません。
nocanonify
「$[ ... $] にアドレスを渡してアドレスを正規化することは行なわない」
を既定とします。
すなわち、ホスト名/ドメイン名は
(非正当名は (つまり@ がない)
このモードでは(標準違反として)使用が禁止されていて別ですが)
通常は、既に正規化されていると見なされます。
この動作は DaemonPortOptions
修飾子 (M=) を設定することで変更できます。
つまり、'c' フラグを設定することで、
FEATURE(`nocanonify') を上書きすることができます。
逆に言うと、
この FEATURE(`nocanonify') がない場合は、
'C' フラグを設定することで、これと同等の効果が得られます
(DaemonPortOptions=Modifiers=C)。
一般的にこれは、
メールゲートウェイとしてしか働かないサイトや、
ユーザエージェントが正規化をきちんと自分で行なっているようなサイトでのみ用いられます。
あるいは、 define(`confBIND_OPTS', `-DNSRCH -DEFNAMES')
という指定をすることで、通常のレゾルバオプションを停止し、
同様の効果を得ることもできます。
一度設定した FEATURE(`nocanonify') の適用の例外を説明することも出来ます。
それには以降の項目で説明するように、
CANONIFY_DOMAIN
または CANONIFY_DOMAIN_FILE を使用します。
この機能を使えば、
ある一部のアドレスだけを $[ ... $] に渡して正規化することも出来ます。
これは、ローカルなドメインだけは正規化する、という場合に有用です。
たとえば、"my.domain" や "my" で
終わるアドレスを正規化するには、 CANONIFY_DOMAIN(`my.domain my') とします。
あるいは、ローカルドメインを正規化をするには、他に
CANONIFY_DOMAIN(`$=m') と
する方法もあります。
一つ以上のドメイン要素からなる
(訳注 login@host でなく login@host.domain のような)アドレス
の末尾には "."
が付加されます。それは、ドメインの最後に "." がついて
いることを想定した機能 (例: virtusertable) が存在する
ためです。
もし、
FEATURE(`nocanonify', `canonify_hosts') のように、
'canonify_hosts' が引数に指定されている場合は、
<user@host> のように、ホスト名だけがついたアドレス
が、FQDN に正規化されます。
stickyhost (こだわり機械) この機能は
LOCAL_RELAY との関連で使われるのですが、
MAIL_HUB の指定がある時と無い時では違う意味になります。
- MAIL_HUB の指定のない場合、"user@local.host" 宛
てのメールは "sticky" (こだわりのある) として扱われます。
これは、
そのローカルアドレスがユーザデータベースにない場合、
ルールセット 5 に渡されず、
LOCAL_RELAY が定義されていても LOCAL_RELAY には渡されません。
- MAIL_HUB の指定がある場合は、
(stickyhost の設定の有無にかかわらず)
"user@local.host" 宛て
のメールは、メールハブに転送されます。
ただし、stickyhost の指定があると、
envelope address は "user@local.host" のままですし、
もし stickyhost を指定していない場合には、
メールループを防ぐために envelope address が
"user@mail_hub" に書き換えられます。
mailertable
"mailer table" を有効にします。これによって、
特定ドメイン (クラス {w}、つまりローカルホスト名、
に含まれないドメイン) 宛てメールのルーティングを書き換えます。
この FEATURE
の引数には、キーを定義するデータベースを指定します。
何も指定がない時の解釈(既定値)は次のようになります:
hash /etc/mail/mailertable
このデータベースのキーは、FQDN か、または "." で始まる
ドメインの一部分です。たとえば、
"vangogh.CS.Berkeley.EDU" や ".CS.Berkeley.EDU" などです。
後者の特殊な場合として、"." は、
他のキーに一致しないすべてのドメインに一致します。値は次のような形式になります
mailer:domain
ここでは、"mailer" は内部のメイラの名前で、"domain"
はメッセージの配送先です。
これによる変換の結果でメッセージのヘッダが書換えられることはありません。(: の右側が domain でなく)
local:user
のような特殊な形式の場合、ローカルメイラを用いて指定のユーザへ転送します。
local:
とすると、ローカルメイラを用いて元々メールに書いてある(ローカルの)宛先へ配送します。
error:code message
error:D.S.N:code message
とすると、
指定の SMTP 応答コードとメッセージによってエラーメッセージを返します。
この応答コードは、RFC 1893
準拠の D.S.N. エラーコードです。
domaintable ドメイン名の対応機能を提供する "domain table"
機能を有効にします。
これは、
自分の所有するドメインに対してのみ使用するようにしてください。
これは、自分のドメイン名を移行する場合などに便利です
(たとえば、あなたの会社の名前が oldname.com から newname.com に変わった場合)。
この FEATURE の引数には、キーを定義するデータベースを指定します。
指定がなければ、
hash /etc/mail/domaintable
という意味になります。
この表のキーはドメイン名、値は新ドメイン (FQDN) です。
domaintable は、ヘッダにも反映されます。つまり、
このアドレス書き換えは、ルールセット 3 に組み込まれます。
bitdomain
BITNET
のホストをインターネットのアドレスに変換するために表を参照します。
John Gardiner Myers による
bitdomain プログラムを使用してこの表を構築することができます。
この FEATURE の引数はキーを定義するデータベースで、
指定がない場合には、次の意味になります。
hash /etc/mail/bitdomain
キーには bitnet のホスト名、値には対応するインターネッ
トのホスト名を設定します。
uucpdomain UUCP ホストと同等の機能です。既定の対応の定義は
次のとおりです。
hash /etc/mail/uudomain
現在、このデータベースを自動的に生成するツールはありま
せん。
always_add_domain
ローカル配送されたメールにもローカルなホストのドメイン
を付加します。
(この機能が無い時には)
通常は、アドレスのドメイン名が正当でなくても(訳注: @domain 部分が存在しなくても)、
そのままで何も付加しません。
しかし、共有メールスプールを使用しているのにサイト内で
ユーザ名空間が統一されていないようならば、この機能を使って
ローカル名にホスト名を付加した方がよいでしょう。
allmasquerade MASQUERADE_AS を使用してマスカレード機能を有効にしてい
る場合、この機能を使うことで、受信者アドレスについても
マスカレードされたものが補われます。通常は、ローカルの
ホスト名がつきます。普通のユーザにとってはそれで問題な
いと思いますが、ローカルエイリアスについて問題が起こる
場合があります。たとえば、"localalias" というアドレス
に送ると、送信元の sendmail は、そのエイリアスのメンバ
全員に送信しようとしますが、
"To: localalias@masqueradehost" とヘッダを書き換えて送
信してしまいます。そのようなエイリアスはおそらく (訳註:
masqueradehost には) 存在しないので、そのメールへの返
信は失敗してしまうでしょう。この機能は、マスカレード名
を持つホストの名前空間全体が、ローカルなエントリすべて
を網羅している場合に *のみ* 使うようにしてください。
limited_masquerade
通常、クラス {w} にあるホストはすべてマスカレードされ
ます。この機能が有効になっている場合、クラス {M}
(後述の MASQUERADE_DOMAIN 参照のこと) にあるホストのみ
がマスカレードされるようになります。これは、同じマシン
で、名前空間がばらばらのドメインをいくつも扱っているよ
うな場合に役に立つでしょう。
masquerade_entire_domain
MASQUERADE_AS を用いてマスカレード機能を有効にしていて、
MASQUERADE_DOMAIN (後述) を設定している場合にこの機能
を用いると、マスカレードするドメイン全体を完全に隠すよ
うにアドレス書換えが行なわれます。マスカレードするドメ
インに属するすべてのホストが MASQUERADE_AS に設定され
たマスカレード名に書換えられます。たとえば、
MASQUERADE_AS(`masq.com')
MASQUERADE_DOMAIN(`foo.org')
MASQUERADE_DOMAIN(`bar.com')
このように設定してあれば、*foo.org と *bar.com が、
masq.com に変換されます。この機能が有効でなければ、
foo.org と bar.com だけがマスカレードの対象になります。
注意: これを用いてマスカレードできるのは、直接自分
の管理下にあるドメインだけです。
genericstable
この機能によって、正当でないアドレス
(たとえばドメイン部がないなど) や、
クラス {G} に定義されているドメインのアドレスに対してマップ検索を行ない、
別の ("generic" な) 形式に変換します。
ドメイン名とユーザ名のどちらも変換できます。
これは、userdb 機能と似ています。
マスカレーディングの場合と同様に、
アドレス形式について検索が行なわれ、
allmasquerade や
masquerade_envelope 機能
の指定がない場合には、
ヘッダの発信者アドレスだけが書き換えの対象になります。
正当でないアドレスの場合は、
ドメイン部がクラス {G} に含まれている必要があります。
クラス {G} には、
マクロ
GENERICS_DOMAIN か
GENERICS_DOMAIN_FILE を用いてドメイ
ンを定義します
(MASQUERADE_DOMAIN や
MASQUERADE_DOMAIN_FILE と同様ですので、これらの項を参
照してください)。
FEATURE(`genericstable') の引数には、対応を定義する
データベースを与えます。
hash /etc/mail/genericstable
この表のキーには、
-
完全なアドレス、
-
ドメイン (@ から始めます。@ の左側(local part)は第一引数
(訳註: 右辺の値の %1) として右辺で参照できます) 、
-
(正当名でない)ユーザ名
のうちのいずれか (この順で検索が行なわれます)
を設定します。
値には、新しいユーザのアドレスを設定します。
新しいユーザのアドレスにドメインが含まれていない場合は、
通常の方法で(@host が付けられ)、正当化されます。
つまり、$j か マスカレードのドメイン名が付加されます。
検索結果のアドレスは必ず FQDN にします。ローカルなメールなら、
FEATURE(`always_add_domain')
を用いて FQDN にする必要があります。
アドレス中の "+detail" は、%1 で参照出来、例えば、
old+*@foo.org new+%1@example.com
gen+*@foo.org %1@example.com
のように記述することができます。
generics_entire_domain
gericstable 機能が有効になっていて、かつ
GENERICS_DOMAIN か GENERICS_DOMAIN_FILE を使用している
場合にこの機能を用いると、アドレスのドメイン部が、クラ
ス {G} にあるドメインのサブドメインである場合にも、マ
ップ検索の対象になります。
virtusertable ドメインを含んだ形式で転送先を設定します。
この機能を用いることで、
複数のバーチャルドメインを一つの機械で扱えるようになります。
(訳注: これが有効なのは(左側の)転送元の @ 以下が
local-host-names に書いてある機械に限ります。
relay をしているだけの domain には効きません)
たとえば、virtuser table に、
info@foo.com foo-info
info@bar.com bar-info
joe@bar.com error:nouser No such user here
jax@bar.com error:D.S.N:unavailable Address invalid
@baz.org jane@example.net
(訳注: 右側の転送先に複数の宛先は書けません。書くと Invalid route Address
になります。その必要がある時には /etc/mail/aliases 等に設定します)
このように設定すると、
info@foo.com 宛てのメール | foo-info へ配送する |
info@bar.com 宛てのメール | bar-info へ配送する |
joe@bar.com 宛てのメール | 指定のエラーメッセージと共に拒否する |
jax@bar.com 宛てのメール | RFC 1893 の D.S.N. のエラーコード付きでエラー |
baz.org のすべてのユーザ宛てのメール | jane@example.net へ配送する |
となります。
発信元のアドレスのユーザ名は %1 と置き換えて渡されます。
@foo.org %1@example.com
とすれば、someone@foo.org は someone@example.com
へ配送されます。
さらに、@ の左側(local part)が "user+detail" で、
user+* に一致すると、"detail" の部分は %2 に代入され、
old+*@foo.org new+%2@example.com
gen+*@foo.org %2@example.com
+*@foo.org %1+%2@example.com
などのように指定することができます。
注意: @domain に対して省略時に "+detail" を残しておくには、
上の例のように +*@domain という行を用います。
マップの左側に登場するホスト名 (foo.com, bar.com, baz.org)
は、
クラス {w} かクラス {VirtHost} に必ず含まれていなければなりません
(MASQUERADE_DOMAIN や MASQUERADE_DOMAIN_FILE と似た形式で、
マクロ VIRTUSER_DOMAIN や
VIRTUSER_DOMAIN_FILE で設定することができます)。
VIRTUSER_DOMAIN か VIRTUSER_DOMAIN_FILE
を使用する場合、クラス {VirtUser}
はクラス {R} に追加されます。
つまり、
これらのドメインへのあるいはこれらのドメインからの転送は許可されることになります。
省略時のマップ定義は、次のようになります。
hash /etc/mail/virtusertable
次のようにして、新しく定義し直すこともできます。
FEATURE(`virtusertable', `dbm /etc/mail/virtusers')
(訳注)
/etc/mail/virtusertable の内容を変更した時には、
makemap hash virtusertable < virtusertable
等のようにして db を更新します。この操作で更新されるものは、二番目の引数に .db
を付けたもの、つまり virtusertable.db です。
virtuser_entire_domain
virtusetable 機能が有効になっていて、かつ
VIRTUSER_DOMAIN か VIRTUSER_DOMAIN_FILE を使用している
場合にこの機能を用いると、アドレスのドメイン部が、クラ
ス {VirtHost} にあるドメインのサブドメインである場合に
も、マップ検索の対象になります。
ldap_routing Internet Draft
draft-lachman-laser-ldap-mail-routing-01 に基づいた、
LDAP ベースのメール受信のルーティングを実装します。
この機能により、
{LDAPRoute} クラスに設定されたドメインを持つアドレスを、
異なるメールホストや異なるアドレスへ振り分けることができます。
LDAPROUTE_DOMAIN と LDAPROUTE_DOMAIN_FILE を用いて、
このクラスにホストを追加することができます
(後述の MASQUERADE_DOMAIN と
MASQUERADE_DOMAIN_FILE と似ています)。
詳しくは、
LDAP ROUTING の章
を参照してください。
nodns UUCP 接続のみの場合のように、DNS を利用していないサイ
トで用います。これを機能と見なすのは厳しいですが、他に
呼びようがありません。実際のところ、8.7 では何も処理を
行なわず、代わりにサービススイッチ (訳註:
ServiceSwitchFile) のエントリから "dns" を削除していま
した。
nullclient これは特別なケースで、SMTP ベースのローカルなネットワ
ーク経由で、集中ハブホストへ転送する機能しか持たないと
いう定義ファイルを作成するのに使用します。引数には、そ
のハブホストの名前を指定します。
これと一緒に使うべき機能は、FEATURE(`nocanonify') だけ
です。メイラ定義すべきではありません。なお、エイリアス
や転送は行なわれません。
local_lmtp LMTP (訳注 Local Mail Transfer Protocol,
RFC2033)
機能を持つローカルメイラを使用します。
この機能の引数には、LMTP 機能を持つメイラのパス名を指定します。
デフォルトでは mail.local を使用します。この機能は、
8.9 から登場した、LMTP 機能を持つ mail.local を使用することを想定しています。
mail.local のパスは、m4 の
confEBINDIR 変数で設定された値によって決められます。
デフォルトの LOCAL_MAILER_PATH は
/usr/libexec/mail.local です。
注意: この機能は、OSTYPE の設定内容によらず、
LOCAL_MAILER_FLAGS を無条件に設定します。
local_procmail
procmail やその他の配送エージェントをローカルメイラとして使用します。
この機能の引数には、配送エージェントのパス名を指定します。
デフォルトは PROCMAIL_MAILER_PATH です。
このローカルメイラには、PROCMAIL_MAILER_FLAGS や PROCMAIL_MAILER_ARGS は *使われない*
ことに注意してください。代わりに LOCAL_MAILER_FLAGS と
LOCAL_MAILER_ARGS を調整するか、適当なパラメータを指定してください。
procmail を利用する場合、
"user+indicator@local.host" という形式が利用できるようになります。
通常、+indicator の部分は無視されるのですが、
procmail にはデフォルトで -a の引数として渡されます。
この機能は、三つの引数を取ります。
- メイラプログラムのパス
[デフォルト: /usr/local/bin/procmail]
- このプログラムの名前を含む引数リスト
[デフォルト: procmail -Y -a $h -d $u]
- メイラのフラグ [デフォルト: SPfhn9]
引数の指定がなければ、デフォルト値が適用されます。
たとえば、
FEATURE(`local_procmail', `/usr/local/bin/maildrop',`maildrop -d $u')
と指定することで、代わりに maildrop
(
http://www.flounder.net/~mrsam/maildrop/
) を使用する
ことができます。
scanmails を使用する場合は次のようにします。
FEATURE(`local_procmail', `/usr/local/bin/scanmails')
注意: この機能は、OSTYPE の設定内容によらず、
LOCAL_MAILER_FLAGS を無条件に設定します。
bestmx_is_local
どのホスト宛てであっても、自分のホストが MX
レコードのリストで優先順位が最高であった場合には、
自分のホストに宛てられたメールとしてメールを受け取ります。
この設定によって、DNS トラフィックが増加しますが、トラフィックの
多くないホストでは問題ないでしょう。引数にはドメインの
組を設定します。
これにより、ここで設定したドメインについてのみ、この機能が適用され、
不要な DNS トラフィックを減らすことになります。
この機能は、ワイルドカード MX レコードとは基本的に相容れないことに注意してください !!
自分のドメインに、ワイルドカード MX レコードがある場合には、この機能を使用することはできません。
smrsh プログラムにメールを渡すのに /bin/sh の代わりに、同梱
の SendMail Restricted Shell (smrsh) を使用します。こ
れにより、システム管理者が、メールから起動させるプログ
ラムの制限をしやすくなります。引数には smrsh のパスを
指定します。引数指定がなければ、smrsh の実行形式のパス
として、confEBINDIR で定義されたパスが適用されます。
既定では /usr/libexec/smrsh が仮定されます。
promiscuous_relay
既定の sendmail の設定ファイルでは、メールの転送
(すなわち、ローカル (クラス {w}) 以外の外部のホストから
ローカル以外のホストへのメールの配送) を許しません。
このオプションを設定すると、どのサイトからどのサイトへの
転送も許すようになります。
ほとんどの場合、access マッ
プやクラス {R} や認証を用いて、もっと注意深く転送制限
を行なう方がよいでしょう。クラス {R} にドメインを加え
るには、マクロ RELAY_DOMAIN や RELAY_DOMAIN_FILE を用
います (後述の MASQUERADE_DOMAIN や
MASQUERADE_DOMAIN_FILE と似ています)。
relay_entire_domain
既定では、access db に
RELAY として指定されたホストだけが転送許可されます。
このオプションを設定するこ
とで、クラス {m} で定義されたドメインのすべてのホスト
も転送許可されるようになります。
relay_hosts_only
既定では、access db の RELAY 指定やクラス {R} に
指定する名前は、ホスト名ではなくドメイン名です。たとえ
ば ``foo.com'' と指定すると、foo.com や abc.foo.com や
a.very.deep.domain.foo.com などのすべてのホストから/へ
のメールすべての転送が許可されます。
この機能を使用する
と、それが個々のホスト名だけに適用されるようになります。
relay_based_on_MX
受信者アドレスのホスト部の MX レコードに基づいた転送を
行なうようにします。つまり、ホスト foo.com の MX が自
分のサイトに向いていれば、foo.com 宛てのメールを受け取
り、転送するようになります。
この機能を使用する前に、以
下の説明を読んでおいてください。また、bestmx マップ検
索については、
KNOWNBUGS (訳註: Sendmail 配布物中の KNOWNBUGS ファイル) も参照してください。
FEATURE(`relay_based_on_MX') は、
中継経路を設定した形
式 (% ハック形式) を用いたとしても、必ずしも思ったよう
にメッセージ転送が許可されるとは限りません。もし、これ
が問題となるのであれば、access テーブルにエントリを追
加するか、
FEATURE(`loose_relay_check') を利用してくだ
さい。
relay_mail_from
メールの発信者のメールアドレスが access マップに RELAY
として載っていれば、転送を許可します。もし、引数に
`domain' が指定されていれば、発信者のドメイン部もチェ
ックするようになります。
発信者のアドレスを偽造する
のは容易なので、この機能は本当に必要な場合だけ利用する
ようにしてください。この機能を用いる場合は、access マ
ップのキーに "From:" タグを指定します。
SPAM 対策用設定
の章のタグの節と、FEATURE(`relay_mail_from') についての記述を参照してください。
relay_local_from
発信者のメールアドレスのドメイン部がローカルなホストの
場合に転送を許可します。
これは、
spammer に窓を開けることになってしまうので、
本当に必要な場合だけこの機能を利用するようにしてください。
具体的に言うと、彼らは、直接
あるいは経路指定したアドレスによって、あたかもあなたの
ドメインから送信されたかのようにして、あなたのメールサ
ーバにメールを送ることができてしまいます。そして、あな
たのメールサーバは、それをそのままインターネット上の任
意のホストへ転送してしまうことになるでしょう。
accept_unqualified_senders
ネットワークからの接続で、発信者のアドレスにドメイン名
が含まれていない場合、
SMTP セッションの MAIL FROM: コマンドは通常では拒否されます。
しかし、もし、ローカルな
メールを正当化せずに送ってしまう
(例: MAIL FROM:
<joe>) ような環境にあるなら、この機能を使用して、
正当化されていない発信者アドレスを許すようにする必要
があるでしょう。
DaemonPortOptions の 'u' 修飾子をセッ
トすると、既定の振る舞いが上書きされます。つまり、
この FEATURE を使わなくても、正当化されていない
名前を許すことになります。また、この FEATURE を使わな
い場合は、DaemonPortOptions に 'f' 修飾子が付いて、
FQDN なアドレスを強制するようになります。
accept_unresolvable_domains
SMTP セッションの MAIL FROM: コマンドの引数のホスト名
部分が、ホスト名サービス (DNS での A レコードや MX レ
コード) で解決できなかった場合には、MAIL FROM: コマン
ドは通常拒否されます。ファイアウォールの内側にいて、イ
ンターネット上のホスト名空間の一部しか参照できないよう
な場合には、これが問題になるかもしれません。
このような場合には、この機能によって、
名前解決ができないドメインでも許可するようにできます。
access_db
アクセスデータベース機能を有効にします。管理上の理由か
ら、あるドメインからのメール受信を許可したり拒否したり
したい場合に、このアクセスデータベースを利用できます。
既定のアクセスデータベースの指定は、
hash /etc/mail/access
です。データベースの形式については、このドキュメン
トの
SPAM 対策用設定
の章で述べます。
blacklist_recipients
受信者のメールアドレスにおける特定のユーザ名、ホスト名、
アドレスへ配送されてきたメールを受け取らないようにしま
す。たとえば、ユーザ nobody、foo.mydomain.com、
guest@bar.mydomain.com へのメールを受け取らないように
することができます。これらの指定は、access db に記述し
ます。記述の仕方については、この文書の
SPAM 対策用設定の章で述べています。
delay_checks
クライアントが接続するとき、あるいはクライアントが
MAIL コマンドを発行するときには、
check_mail ルールセットおよび
check_relay ルールセットはそれぞれ参照されなくなります。
その代わりに、check_rcpt
ルールセットか らこれらのルールセットが参照されます。特定の状況では、
これらのルールセットはスキップされます。「SPAM 対策用
設定」の章の
「すべてのチェックを延期する」を参照のこと。
rbl
この機能はお勧めできません! 代わりに dnsbl を使用して
ください。Realtime Blackhole List に載っているホストを
拒否します。拒否ホストのリストを提供するドメインを引数
に指定します。デフォルトは、メイン RBL ドメインである
rbl.maps.vix.com が利用されます (後述の注意書き参照の
こと)。詳しくは、
http://maps.vix.com/rbl/
を参照してく
ださい。
dnsbl
DNS ベースの拒否リストによってホスト拒否を行ないます。
拒否ホストのリストを提供するドメインを引数に指定します。
引数が指定されない場合のデフォルトは
blackholes.mail-abuse.org です。DNS ベースの拒否リスト
については、
http://mail-abuse.org/rbl/
に説明がありま
す。第二引数を指定することで、デフォルトのエラーメッセ
ージ、「Mail from $&{client_addr} refused by blackhole
site SERVER」("SERVER" は、第一引数に置き換えられます)
を変更することができます。この機能は、異なる DNS ベー
スの拒否リストを参照するために複数回指定することができ
ます。
注意: デフォルトの DNS ブラックリストである
blackholes.mail-abuse.org は Mail Abuse Prevention
System (MAPS) で提供されているサービスです。2001年7月
31日から、MAPS は登録性のサービスになります。したがっ
て、登録していないネットワークアドレスからは利用できな
くなります。登録するには MAPS (
http://mail-abuse.org/
)
にお問い合わせください。
loose_relay_check
通常、user%site@othersite のように、受信者のアドレスに
% があり、かつ othersite がクラス {R} に含まれている時
は、check_rcpt ルールセットで @othersite が取り除き、
user@site への転送に関するチェックを行ないます。この機
能は、この動作を変更します。大抵の場合、これが必要とな
ることはないでしょう。
no_default_msa
DAEMON_OPTIONS(`Port=587,Name=MSA,M=E') のように、デフ
ォルトの MSA デーモンを生成しないようにします。MSA デ
ーモンに、デフォルトと異なるパラメータを与えたい場合は、
この FEATURE を指定した上で、新しい設定を、
DAEMON_OPTIONS() に指定します。
|