社内イントラネットに設置されたサーバからアラートメールを受け取る、というのは90年代から受け継がれるシステム管理の基本かつメジャーな手法です。
電子メールがいろいろと緩い時代はそれほど問題にもならなかったのです。（設定とかセキュリティとか不正中継とか）それはもうなんとなくでも動作するような時代もあったものです。最近ではきちんとメールサーバの構成を見極めないと、緩々の設定ではあっという間に不正利用の温床となってしまいます。
設定を厳格に適用することは正しいことですが、それによって動作が変わってしまうため、それを修正するのもシステム管理者の仕事、となります。
本日は、実際に発生したメールのエラーメッセージをご報告します。
メールアドレスは<～@hoge.co.jp>を使っている、という仮定です。
いずれも原因はメールサーバmx.hoge.co.jpは最近仕様が変更になり、セキュリティ設定がより厳しくなった、ということが発端です。（ざっくりですが、スパムメール対策が強化された、という風に受け取っておいてください。）
メールサーバがスパム対策を強化するだけで下記のようなエラーが発生することがある、という事例としてご覧ください。
エラー解決の参考になれば幸いです。
その１：バックアップPCのアラートメールでエラー
---------------------------
BunLogMail
---------------------------
<warning@hoge.co.jp>: Sender address rejected: not logged in
---------------------------
見たときの第一声は「なんじゃこら？」でした。（突然だったもので。）
「Sender address rejected」なので対象のアドレスに送信できなかった、その原因は「not logged in」ログインしていない≒ログイン設定（ここではSMTP認証のログイン）が有効ではなかった、という意味のエラーメッセージです。
このバックアップPCではBunBackupのメール送信機能<BunLogMail>を使ってバックアップ実行ログを送信する、ということやっています。
いままではSMTP認証設定で以下のようにしていました。
図1：設定画面（従来）
ただ、メールサーバmx.hoge.co.jpは最近仕様が変更になったため、Outlookなどのメーラ設定でユーザID入力欄を「ユーザ名」単体のログイン情報から「ユーザ名@ドメイン名」に変更しなければならないという仕様変更が発生したのでエラーになっている、という状況です。
そこで、メールサーバの仕様通りログイン情報から「ユーザ名@ドメイン名」に変更することにしました。
図2：設定画面（変更後）
そうすると、エラーとなって設定が完了しない、という状況に。
図3：エラーメッセージ
あれ？おかしいな？⇒結論から言うとこれは仕様です。
メールサーバのログイン情報が「ユーザ名@ドメイン名」の場合、BunLogMailの設定としてはユーザログイン情報として解釈できない、ということだと考えられます。
試しに、別にあるテスト用メールサーバで「ユーザ名@ドメイン名」ではなく「ユーザ名」単体のログイン情報でメールの認証を試みたところでは、しっかり成功しテストメールが送信されます。
図4：別のメールサーバで同一アドレスを作成してSMTP送信を試す設定画面。
結局コチラではうまくいきました。
こうなると、もうアラート送信専用のメールサーバを（フリーソフトなどで）こぢんまりと1台用意しなければアラートメールは送信出来ないことになります。
やむを得ず、アラートメール専用のメールサーバを簡単に用意しそのメールサーバを経由してアラートメールを自分のメールボックスに届けることにしました。
その2：影響は別システムのアラートメールでも
別のところでもういっちょ。
時を同じくして、Linux上のシステムのアラートメールがエラーになるようになりました。
このシステムのメールサーバも前述のバックアップPCと同じメールサーバを参照しています。
----------------------------------------------
/var/log/maillog
----------------------------------------------
Nov 15 19:38:33 webap02 sendmail[29664]: tAAJ24dr025756: to=warning@hoge.co.jp, ctladdr=<root@webap02.localdomain> (0/0), delay=4+15:36:29, xdelay=00:00:00, mailer=esmtp, pri=10110940, relay=mx.hoge.co.jp. [111.222.33.44], dsn=4.1.8, stat=Deferred: 450 4.1.8 <root@webap02.localdomain>: Sender address rejected: Domain not found
----------------------------------------------
toにある<warning@hoge.co.jp>は存在するメールアドレスです。
が、「Sender address rejected: Domain not found」と受け取り拒否されています。どうやら、自分の出自耳目である<root@webap02.localdomain>が実在しないドメインのメールアドレスが送信元なので、メールサーバmx.hoge.co.jpが<warning@hoge.co.jp>へのメールの受け取りを拒否している、という記録です。
相手が受取拒否をしているので「stat=Deferred」となっており、再送待ちになっています。この状態の時は、設定された再送間隔でメールプログラムが再送を試みます。
ちなみにメールログの対比として、以下のエントリがログに記録されていれば正常に送信できています。
※対処後正常送信が可能になったログ
----------------------------------------------
Nov 15 20:52:45 webap02 sendmail[29794]: tAFBqhAO029793: to=warning@mx2.hoge.co.jp, ctladdr=<user1@webap02.localdomain> (501/501), delay=00:00:02, xdelay=00:00:02, mailer=esmtp, pri=30539, relay=mx2.hoge.co.jp. [111.222.333.444], dsn=2.0.0, stat=Sent (tAFBqhSf023334 Message accepted for delivery)
----------------------------------------------
「stat=Sent」となっていれば続けて「Message accepted for delivery」と記録されているため、正常送信できたことが確認できます。
結局こちらでも、前述したアラートメール専用のメールサーバを経由してメールを送信することでアラートメールを受信するように設定変更しました。
設定で言えば
----------------------------------------------
/etc/aliases
----------------------------------------------
#root: warning@hoge.co.jp
root: warning@mx2.hoge.co.jp
----------------------------------------------
rootのalias設定を従来は<warning@hoge.co.jp>としていましたが、これをコメントアウトし、fromのアドレスを問わない<warning@mx2.hoge.co.jp>のメールサーバ上のアドレスにaliasを変更し、メールを送信できるようにしました。
メールサーバの仕様変更にはユーザのメール環境だけではなく、システムが自動送信しているアラートメールにも気を配らなくてはならない、という事例でした。
