参考になるページ等 
- Wikipedia / Simple Mail Transfer Protocol
- 美森勇気のページ / SMTPコマンドなど
Tips
まず、
だったとして、相手のメアドの @ より後の部分 example.com のドメインについて DNS の MX レコードを調べる。
以下のいずれかの方法が使えるはず。
これで、smtp.example.com が返ってきたとして、通常は port 25 に EHLO, MAIL FROM, RCPT TO, DATA の順でリクエストを送り付け、本文送った後 "\n.\nQUIT\n" を送り付ければればよい。
厳密には "\n" は CR LF じゃないといけないかもしれないし、本当はレスポンスを見る必要もあるが、エラー処理を無視すると bash からだと以下のようにすると送れた。
普通は
また、リクエストを手打ちした場合も、DATA 以降、本文の入力までは一見上手くネゴシエーションが通っているように見えるものの、"\n.\n" で QUIT 待ちに戻ってくれず上手く行かなかった。
何も表示されずに入力待ちになる場合は、多分 port が filtered になってるはず。
ただし、後述の SMTPS (通常は port 465 だけど) の場合、こっちから Client Hello 送らないとネゴシエーションが始まらないと思うので見分けがつかないと思う。
入力待ちにならず nc が終了する場合は、port が closed か rejected になってるはず。
今どきは spam 対策のため Outbound Port 25 Blocking (OP25B) がかかかってると思うので、ISP の通常契約だと smtp port (25) は繋がらないかもしれない。
その場合は、submission port (587) を使うらしいが、MUA からの送信用ではなく MX レコードの MTA が 587 を提供しているかと言うと、普通は提供してない気がする。
nmap が使えるなら、以下のように port scan をかけることで況が分かると思う。
うちの職場のメアドだと、上記の方法、および、自分に届いているメールの Received: ヘッダから、MX レコードに指定されてるはずのサーバーを特定して試しても、自宅からだと port 25 は何も表示されずに入力待ちの状態になる。
これは、25,465,587 が全て filtered になっていた。
職場からだと open, closed, closed になってて、ちゃんと送信出来るので、多分 ISP による OP25B の影響で間違いないとは思う。
ただし、gmail.com 相手だと、前述の通り port 25 でも "\n.\n" 直前までは上手く行っているので、本当に ISP による OP25B のせいなのかは確信が持てないところ。
相手が Gmail だけに特別扱いという可能性はあるかもしれないが、不思議なことに gmail の MX は nmap で 25,465,587 が全て filtered であるにも関わらず nc で手打ちでネゴシエーションすると、こっちが入力するまえにちゃんと 220 で応答返ってくるという謎な状況だったする。
初期応答にかなり大きな遅延を入れていると仮定すると、前述のようにパイプだと応答が表示されない事との整合性が取れる気もしなくはないが、nmap に --initial-rtt-timeout 5000ms --min-rtt-timeout 5000ms --max-rtt-timeout 5000ms のようにかなり大き目の timeout 値を設定しても依然として filtered のままだし、nc だとそこまで大きな遅延は見られないので原因が良く分からない。
あと、細かいことだけど、うちの職場は、対内・対外で DNS が異なっており、職場内の DNS はなぜかは MX レコードとして別のサーバーを返して来る。
こっちは職場内外共に filterd になってるので、MX レコード根拠にメール送ると上手くいかなかった。
言うまでもないが、MUA 用として職場で案内されている MTA を使えば、問題なくメールは送れる。
なんであえてそういう事を言うかと言うと、例えば postfix なんかだと、ちゃんと relayhost を設定しないと(MX レコード任せになるので)メールが送れないという状況が生じるということ。
なお port 465 は SMTPS (暗黙の SMTP over SSL, implicit mode) のはずなので openssl s_client 等を使う必要がある。
SMTP with STARTTLS (明示的な SMTP over SSL, explicit mode) が必要な場合は openssl s_client だと -starttls smtp オプションを付ければよい。
従って、要 SSL の場合は、上記の
以下のいずれかの方法が使えるはず。
nslookup -type=mx example.com dig example.com mx
これで、smtp.example.com が返ってきたとして、通常は port 25 に EHLO, MAIL FROM, RCPT TO, DATA の順でリクエストを送り付け、本文送った後 "\n.\nQUIT\n" を送り付ければればよい。
厳密には "\n" は CR LF じゃないといけないかもしれないし、本当はレスポンスを見る必要もあるが、エラー処理を無視すると bash からだと以下のようにすると送れた。
(
MAIL_FROM="<from@example.com>"
RCPT_TO="<to@example.com>"
SMTP_HOST=smtp.example.com
SMTP_PORT=25
cat<<-EOD | nc $SMTP_HOST $SMTP_PORT
EHLO localhost
MAIL FROM: ${MAIL_FROM}
RCPT TO: ${RCPT_TO}
DATA
Subject: test
From: ${MAIL_FROM}
To: ${RCPT_FROM}
test
.
QUIT
EOD
)
ネゴシエーションと本文の from, to は異なって構わないらしいが、spam 対策のため MTA の設定によってはネゴシエーションの from, to は、454 で Sender address rejected: Access denied になるかもしれない。普通は
nc smtp.example.com 25とかして "220 〜" って返ってきて入力待ちになれば大丈夫なはずだけど、@gmail.com の MX について試してみると、入力をパイプで流し込むと一切応答が表示されない。
また、リクエストを手打ちした場合も、DATA 以降、本文の入力までは一見上手くネゴシエーションが通っているように見えるものの、"\n.\n" で QUIT 待ちに戻ってくれず上手く行かなかった。
何も表示されずに入力待ちになる場合は、多分 port が filtered になってるはず。
ただし、後述の SMTPS (通常は port 465 だけど) の場合、こっちから Client Hello 送らないとネゴシエーションが始まらないと思うので見分けがつかないと思う。
入力待ちにならず nc が終了する場合は、port が closed か rejected になってるはず。
今どきは spam 対策のため Outbound Port 25 Blocking (OP25B) がかかかってると思うので、ISP の通常契約だと smtp port (25) は繋がらないかもしれない。
その場合は、submission port (587) を使うらしいが、MUA からの送信用ではなく MX レコードの MTA が 587 を提供しているかと言うと、普通は提供してない気がする。
nmap が使えるなら、以下のように port scan をかけることで況が分かると思う。
nmap -sS -PN smtp.example.com -p 25,465,587
うちの職場のメアドだと、上記の方法、および、自分に届いているメールの Received: ヘッダから、MX レコードに指定されてるはずのサーバーを特定して試しても、自宅からだと port 25 は何も表示されずに入力待ちの状態になる。
これは、25,465,587 が全て filtered になっていた。
職場からだと open, closed, closed になってて、ちゃんと送信出来るので、多分 ISP による OP25B の影響で間違いないとは思う。
ただし、gmail.com 相手だと、前述の通り port 25 でも "\n.\n" 直前までは上手く行っているので、本当に ISP による OP25B のせいなのかは確信が持てないところ。
相手が Gmail だけに特別扱いという可能性はあるかもしれないが、不思議なことに gmail の MX は nmap で 25,465,587 が全て filtered であるにも関わらず nc で手打ちでネゴシエーションすると、こっちが入力するまえにちゃんと 220 で応答返ってくるという謎な状況だったする。
初期応答にかなり大きな遅延を入れていると仮定すると、前述のようにパイプだと応答が表示されない事との整合性が取れる気もしなくはないが、nmap に --initial-rtt-timeout 5000ms --min-rtt-timeout 5000ms --max-rtt-timeout 5000ms のようにかなり大き目の timeout 値を設定しても依然として filtered のままだし、nc だとそこまで大きな遅延は見られないので原因が良く分からない。
あと、細かいことだけど、うちの職場は、対内・対外で DNS が異なっており、職場内の DNS はなぜかは MX レコードとして別のサーバーを返して来る。
こっちは職場内外共に filterd になってるので、MX レコード根拠にメール送ると上手くいかなかった。
言うまでもないが、MUA 用として職場で案内されている MTA を使えば、問題なくメールは送れる。
なんであえてそういう事を言うかと言うと、例えば postfix なんかだと、ちゃんと relayhost を設定しないと(MX レコード任せになるので)メールが送れないという状況が生じるということ。
なお port 465 は SMTPS (暗黙の SMTP over SSL, implicit mode) のはずなので openssl s_client 等を使う必要がある。
SMTP with STARTTLS (明示的な SMTP over SSL, explicit mode) が必要な場合は openssl s_client だと -starttls smtp オプションを付ければよい。
従って、要 SSL の場合は、上記の
nc $SMTP_HOST $SMTP_PORTの部分を、それぞれ以下のように書き換えると良い。
openssl s_client -connect ${SMTP_HOST}:${SMTP_PORT} # implict mode の場合
openssl s_client -connect ${SMTP_HOST}:${SMTP_PORT} -starttls smtp # explict mode の場合
タグ
コメントをかく