Postfixサーバーをごく短時間実行してみましたが、動作しましたが、今日サーバーを再起動する必要があり、外部ソースから電子メールを受信しなくなりました。
Jan 23 01:34:44 myservername postfix/smtpd[1055]: connect from db3ehsobe006.messaging.Microsoft.com[213.199.154.144]
Jan 23 01:34:45 myservername postfix/smtpd[1055]: warning: connect to 127.0.0.1:10023: Connection refused
Jan 23 01:34:45 myservername postfix/smtpd[1055]: warning: problem talking to server 127.0.0.1:10023: Connection refused
Jan 23 01:34:46 myservername postfix/smtpd[1055]: warning: connect to 127.0.0.1:10023: Connection refused
Jan 23 01:34:46 myservername postfix/smtpd[1055]: warning: problem talking to server 127.0.0.1:10023: Connection refused
Jan 23 01:34:46 myservername postfix/smtpd[1055]: NOQUEUE: reject: RCPT from db3ehsobe006.messaging.Microsoft.com[213.199.154.144]: 451 4.3.5 Server configuration problem; from=<MyKnownWorking@EmailAccountOutside> to=<[email protected]> proto=ESMTP helo=<db3outboundpool.messaging.Microsoft.com>
サーバーはport 10023
でリッスンしていますが、IPv6経由でのみリッスンしていることがわかりました。
> Sudo netstat -a | grep 10023
tcp6 0 0 ip6-localhost:10023 [::]:* LISTEN
特定のポートを拒否するファイアウォールルールがないので、確認のためにルールセットをフラッシュしました。これが私のpostconf -nの出力です(「mydomain.com」の代わりにドメイン名を編集しました:
> Sudo postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
content_filter = amavis:[127.0.0.1]:10024
disable_vrfy_command = yes
inet_interfaces = all
inet_protocols = ipv4
mailbox_size_limit = 0
message_size_limit = 0
mydestination = localhost.$mydomain, localhost, mail.mydomain.com, servername.mydomain.com
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mynetworks_style = Host
myorigin = /etc/mailname
readme_directory = no
receive_override_options = no_address_mappings
recipient_delimiter = +
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_banner = mail.mydomain.com ESMTP $mail_name
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_recipient_restrictions = reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks, warn_if_reject reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unauth_pipelining, permit
smtpd_tls_cert_file = /etc/ssl/private/mail.mydomain.com.crt
smtpd_tls_key_file = /etc/ssl/private/mail.mydomain.com.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
virtual_alias_maps = mysql:/etc/postfix/maps/alias.cf
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/spool/mail/virtual
virtual_mailbox_domains = mysql:/etc/postfix/maps/domain.cf
virtual_mailbox_limit = 0
virtual_mailbox_maps = mysql:/etc/postfix/maps/user.cf
virtual_uid_maps = static:5000
ご覧のとおり、ipv4接続でリッスンすることをinet_protocolsで指定しようとしています。私はそのコマンドの有無にかかわらずそれを試しました。
トラブルシューティングの手助けをいただければ幸いです。そしてもちろん、私の設定に何かが明らかに愚かであるとわかった場合、私はアドバイスや批判よりも上ではありません。
最後のsmtpd_recipient_restrictionsのチェックでは、ポリシーサービスを使用して受信者を確認します。通常、これはpostgreyサービスであり、Postfixの接続に問題があるようです。
smtpd_recipient_restrictions = ...,check_policy_service inet:127.0.0.1:10023, permit
check_policy_service inet:127.0.0.1:1002をsmtpd_recipient_restrictionsから削除する場合、エラーを排除する必要がありますが、postgreyまたはここで実行される他のサービスに何が起こるかを判断する必要があります。
nbuntuシステムでのPostgreyの確認
通常、postgreyのデフォルト設定は、ポート10023で接続をリッスンし、それらを許可するか拒否するかを決定します。これがインストールされているかどうかを確認することができるUnbutuサーバー上の一部は...
/etc/default/postgrey
ファイルはありますか?これは基本的な設定ファイルです。/etc/postgrey
フォルダはありますか?ここで要素をホワイトリストに登録できます。> which postgrey
を実行すると、バイナリが見つかりますか?鉱山は/usr/sbin/postgrey
にあります。/etc/init.d/postgrey
スクリプトはありますか?これは、Ubuntuデーモンの一般的な場所です。これらは、このサーバーが一度にpostgrey
を構成した可能性があるかどうかについての手がかりを与えるだけです。サーバーでプロセスが適切に実行されていない場合は、トラブルシューティングをさらに行う必要があります。
同じ問題に直面し、bsheaによって提案されたような多くの方法を試し、グーグルして試してみました。
ベース: Ubuntu 14.04.2 LTS、postgrey
サービスは開始しますが、プロセスリストに表示されません。つまり、サービスは開始しますが、静かに停止します。
/etc/default/postgrey
の行を変更するソリューションが見つかりました:
この行を変更します。
POSTGREY_OPTS="--inet=10023"
これに
POSTGREY_OPTS="--inet=127.0.0.1:10023"
ポートやプロトコルを操作する必要はなく、何かのバージョンのダウングレードも必要ありません。理由は説明できませんが、サービスはps -aux
にあり、すべて機能します。
実際には、ipv6を使用する必要はありません。PostgreyとPostfixをipv4に設定できます。問題は、Postgrey(おそらくバージョン1.33以降)がipv4 localhost ip 127.0.0.1での起動を拒否するため、ethX IPアドレスを使用できることです。
/ etc/postfix/main.cfでこれを変更します:
check_policy_service inet:127.0.0.1:10023
に:
check_policy_service inet:<your_ipv4_address>:10023
次にPostfixを再起動します。
Sudo service postfix restart
/ etc/default/postgreyでこれを変更します:
POSTGREY_OPTS="--inet=10023 --delay=60"
に:
POSTGREY_OPTS="--inet=<your_ipv4_address>:10023 --delay=60"
次にPostgreyを再起動します。
Sudo service postgrey restart
このDebianメーリングリストのメッセージは非常に役に立ちました。
Davis-そうです、postgreyは12.04LTSでIPv6で動作するように変更されました。アップグレードではpostfixの変更は行われず、変更を行うように警告することもありません。
だから自分でやらなければならない。これを変える:
check_policy_service inet:127.0.0.1:10023
に:
check_policy_service inet:::1:10023
/ etc/postfix/master.cfファイルで、postfixを再起動します。
Sudo service postfix restart
それはpostfixがIPv6をpostgreyと話すことを可能にします。
IP:PORTの問題は、私にとっては問題ではありませんでした(Ubuntu 14.04.2 LTS)。ローカルポートの接続/実行の失敗でpostgreyが中断/終了すると想定すると、誤解を招く可能性があります。
まず、デーモンが実行中として認識されているかどうかを確認します。
Sudo service postgrey status
実行/認識されていない場合、引き続き表示されます:
warning: problem talking to server [::1]:10023: Connection refused
メールログ。 Postgreyは単に接続/実行されていません。実行中(2回以上の可能性があります)でサービスの停止やステータス設定ができない場合は、pid/truncateに問題があると考えられます。その場合は、次のようにします。
ps a | grep postgrey
(各)プロセスを手動で強制終了します。/var/run(/ run)からpostgrey.pidファイルを削除します。
すべてのpostgreyファイルがデフォルトであり、起動しようとしているが、( 'Sudo service postgrey status'を確認した後)再起動/再起動/停止に失敗した場合、stop-start-daemonのロックファイルと名前付きプロセスに問題がある可能性があります。
POSTGREYには非常に基本的なinit.dスクリプトがあり、実行前/実行後にあまりチェックを行いません。メンテナは本当にこれに取り組む必要があります。
主な問題は、切り捨てられた名前付きファイルを検索するstart-stop-daemonです:
( https://bugs.launchpad.net/ubuntu/+source/postgrey/+bug/1289424 )
インストールされたスクリプトは、$ NAME = "postgrey"をチェックします。
( "--name $ NAME")
残念ながら、使用する必要があるのは(Ubuntu/Debian): '/ usr/sbin/postg'です。
(15文字のみでパスの一部です-これは明らかに存在しません。)
修正(パスを含む切り捨てられたバージョンの変数PROCNAMEを追加):
PROCNAME=`echo $DAEMON | cut -c -15`
(代わりに '/ usr/sbin/postg'を確認します)
「--name」の下に移動します:
stop)
log_daemon_msg "Stopping $DESC" "$NAME"
if start-stop-daemon --stop --oknodo --quiet \
--pidfile $PIDFILE --name $PROCNAME
..
reload|force-reload)
log_action_begin_msg "Reloading $DESC configuration..."
if start-stop-daemon --stop --signal 1 --quiet \
--pidfile $PIDFILE --name $PROCNAME
(オプション)
私がそれにいる間、ロックファイルをそれ自身のディレクトリ '/run/postgrey/postgrey.pid'内に置きました。
独自のディレクトリに配置したい場合は、このビットを追加して毎回フォルダを再作成する必要があります。
PIDFOLDER=/var/run/$NAME
PIDFILE=$PIDFOLDER/$NAME.pid
既存のディレクトリ/フォルダーを確認します。
check_pid_dir() {
if [ ! -d $PIDFOLDER ]; then
mkdir $PIDFOLDER
chmod 0755 $PIDFOLDER
fi
}
「開始」に機能を追加します。
case "$1" in
start)
check_pid_dir
log_daemon_msg "Starting $DESC" "$NAME"
私の完全なinit.dスクリプトはここにあります: https://Gist.github.com/bmatthewshea/50e2038563b103e466ea
あまりテストしていませんが、これまでのところ、デフォルトよりも確かにうまく機能しています。 :)
これはまた PostfixがIPv4のみを話すように設定している場合に壊れます(私のISP それでもを行わないために必要であり、私のIPv6 HEトンネルがタグ付けされているため) Netflixのようなサービス、つまりNetflixを壊す...)
ローカルホストをpostgreyのINETコマンドフラグに追加does IPv4にバインドしないように修正。
IPv4とIPv6の両方にバインドできない理由はわかりませんが...