PLESK サブミッションポート設定

20160129-higa-pict01

デジタルドリームワークスからHigaです。
PLESKなどのGUIコントロールパネルが用意されているサーバーは便利ですね。
PHPバージョンを簡単に上げられなかったりもしますが…

今回はそんなPLESKでハマった点をメモです。
PLESK10以降では仕様の変更によりサブミッションポートはTLS接続を行わないとメール送信が出来ない仕様になっています。
もちろん暗号化通信を行うことが一番ですが、どうしてもお客様の環境によりTLS接続が困難な場合などは、セキュリティーレベルを下げないといけない場面があります。
そんな場合には以下を参考に作業を行います。

設定ファイル
—————————————————–
/etc/postfix/master.cf
—————————————————–

▼変更箇所
—————————————————–
「submission」の設定で記述されている、「smtpd_tls_security_level」パラメータの値を「encrypt」から「may」に変更

○初期の記述
smtpd_tls_security_level=encrypt

○変更後の記述
smtpd_tls_security_level=may

—————————————————–
変更後例:
submission inet n – n – – smtpd -o smtpd_enforce_tls=yes -o smtpd_tls_security_level=may -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_sender_restrictions=
—————————————————–

という感じです。
これはPostfixとPleskの組み合わせで起こることでその他の組み合わせ、例えばQmailとPleskの環境では問題ありません。
弊社でもいくつかサーバーを管理しておりますが、環境により設定が異なるので時々 頭がパンクしそうになります。

またサーバーを疑う前にお客様のメール設定に問題がある場合も多いです。
まずはお客様のメール設定を確認することから始めるのが鉄則です。

それでは!

SPFレコードを公開しよう!

20160318-pict01

メールのやり取りで、正当なメールが迷惑メールに振り分けられる場合がよくあります。
特にGmailへ送信する場合は、必ずと言っていいほど問題になります。
そんなときにはSPFレコードを確認しましょう!

現在では迷惑メール対策の一つとして送信ドメイン認証SPFレコードの確認を行っているプロバイダーや携帯会社が多いです。
送信ドメイン認証SPFレコードの公開は、DNSレコードに1行レコードを追加するだけで手軽に設定出来ます。
もう設定済みですよ!という方も多いと思いますが…

 

SPFレコードの設定

SPFレコードは対応していないリゾルバやDNSサーバーが存在するためTXTレコードとSPFレコードの両方を記述します。
自分が調べた感じでは、多くの記事ではTXTレコードのみを紹介していたのでTXTレコードのみの記述で問題ないようです。
シンプルな書き方はこんな感じかな。環境や記述されているDNSレコードにより異なると思いますが…

 

20160318-pict02

 
記述方法も多くあり、また紹介している記事も多数ありますので「SPF設定方法」などで検索してみて下さい。

またSPFレコードは記述ミスがあると無視されてしまいますので、最後にチェックをお忘れなく!
SPFチェック出来るサイトもいくつかあるようです。
自分は以下で確認しています。

http://mxtoolbox.com/spf.aspx

というわけで迷惑メールに振り分けられたり、メール拒否対策としてSPFを取り上げました。
しかし様々な要素が判断材料となり迷惑メールや拒否の振り分けをしていますので、これですべて解決するわけではありません。
でも1つの判断材料をクリアする事で少しは問題回避の糸口とあるかもしれませんね。
それでは!

間違っているところや別の方法などがあるという方は、ぜひコメントいただければと思います。

サーバーの負荷を考える(メールサーバー)…

postfix

デジタルドリームワークスから比嘉です。
さてサーバーを持っていると必ずと言っていいほど打ち当たるのが負荷問題です。
一時的なものであればまだ良いのですが、頻繁に負荷がかかり処理が出来なくなる状況であれば対策をねらなければなりません。
そもそもスペック的な問題なのか、一部のシステムが高負荷になり全体に影響を与えているのか。
ログを確認しても難しい部分もあります。

今回はメールサーバ(Postfix)を見ていきます。
弊社の環境ではメールサーバーが負荷を与えている状況ではありませんでしたが、改善出来るポイントを確認してみました。

※以下のチェック項目はあくまでPostfixの他の部分(スパムメールの踏み台にされない)など 適切な設定を行っている場合の追加チェックポイントみたいなものです。

 

———-

 

/etc/postfix/main.cfを確認していきます。

 

1. unknown_local_recipient_reject_code 項目の確認

「unknown_local_recipient_reject_code」の項目は名前通り、宛先ユーザーが存在しない場合のresponse codeの設定です。
バージョンが古いpostfixでば、「450」となっている場合があるようです。

コード「450」の場合は一時的にメール配送ができない状態を表し、時間をおいて再送される仕組みになっています。
宛先ユーザーが存在しない場合でも設定されている期間内で繰り返しメールを配送しようと処理するので「450」の場合は「550」修正します。
※ コード「550」は宛先ユーザーが存在しないということで即座に拒否(送り返す)します。

unknown_local_recipient_reject_code = 550

色々と記事を見ていると配送設定の期間もデフォルトではいけませんよ 的な記事もありました。

【 参考 】

Postfixの再送設定はデフォルトだとちょっとお人よしですよ

minimal_backoff_time =
maximal_backoff_time =
maximal_queue_lifetime =
bounce_queue_lifetime =
queue_run_delay =

 

2. エラーメールの返信ポリシーを検討する

宛先ユーザーが存在しない場合はエラーメールとして送り主にエラーメールが返信されます。
しかしスパムメールは送り主を偽装して実在しないメールからメールを送信されたかのようになっている場合があり、エラーメールが送信出来ずにサーバー内に溜まっていく場合があります。
調べた結果、管理者によりエラーメールの設定ポリシーは異なるようです。

1. 従来通りエラーメールを送り主に送信(サーバー内に溜まるエラーメールを定期的に削除?)
2. エラーメールを送信せずそのままサーバー内で削除

1の場合は送信者がエラーでメールが届いていないことが分かるメリットがありますが、サーバーに溜まるエラーメールを削除する必要がありそうです。
2の場合は溜まったメールを処理する手間は省けますが、メールが届いてない場合も確認出来ないなどの問題が出てきそうです。

どちらもメリット、デメリットがあります。
そして一般的な設定はどうなっているのでしょうか。気になるところですがその部分を確認することは出来ませんでした…
ご存知の方がいらっしゃいましたらコメントいただけると幸いです m(_ _)m
弊社のサーバー環境も確認&検討してみようと思います。