2011年8月30日火曜日

EC2のIPアドレス

EC2のインスタンスを起動すると
Private IPおよびGlobal IPが割り当てられます。
また、それぞれに対応するPrivateDNS名およびPublicDNS名が付きます。
これらの値は、インスタンス起動時に割り当てられるのですが、

Global IPについては、インスタンスをTerminateしない限り変更さない。
Private IPについては、インスタンス起動中も定期的に変更される。


と、最近までは思っていました。
でも、最近一部のインスタンスでPrivateDNSの名前が、

ip-10-XXX-YYY-ZZZ.ec2.internal

みたいなPrivate IPを含む名前になっていることに気づきました。

以前までは、PrivateDNSはMACアドレスを含む

domU-11-22-33-AA-BB-CC.compute-1.internal

みたいな名前でした。

自分の解釈では、Private IPは定期的に変更されるから、
MACアドレスのように不変な値がPrivateDNSの一部になっているのかと理解していました。
少し記憶が曖昧なのですが、実際、以前はPrivate IPが、
DHCPで定期的に変更されていたような気がします。

逆に、Global IPについては、インスタンスをTerminateしない限り変更されないので、
PublicDNS名は、Global IPを含む形式になっていると理解していました。

ってことは、Private IPが変化しなくなったのかな?
と思って調べていたら、
以下のページにたどり着きました。

動作中にインスタンスのIPアドレスの変更がありえるか?

上記ページによると、インスタンス起動中は、
Private/Global IPは不変とのこと。
またRebootしても不変とのこと。

知らなかった。。。
一体いつからこうなったんでしょうか?
最初からだったのでしょうか?
私の気のせい?

2011年8月23日火曜日

メールを転送した時にSPAM扱いされないようにする方法

自分で運用しているメールサーバに届いたメールを、
サーバ側から特定のメールアドレスに転送した時にSPAM扱いされないようにする方法を紹介します。

■その前に、このエントリを読み進めるための前提知識


■そもそも私が直面した現象
自分が運用しているメールサーバに届いたメールを、サーバ側のエイリアスの設定で
Gmailまたは、Google Appsのgroupに転送すると、エラーメールが返ってくるようになりました。
エラーメールには、以下のURLを参照するようにと書いてありました。

http://www.google.com/support/a/bin/answer.py?hl=en&answer=168383

また、添付されていくるメールのヘッダ情報によると、SPFがFAILしていました。


■解決方法
2つの方法を確認したところSPFがPASSになることを確認しました。
(もちろん、SPFの設定が正しく行われていることが前提。)
どちらの方法でもSPFはPASSになりますが、
可能であれば、両方実施した方が確実にSPAM扱いされないように思います。

解決方法その1:
転送する時に、Senderヘッダを付加。
Senderヘッダの値には、転送メールを実際に送信するメールサーバのドメインのメールアドレスを指定します。
※意味的には、Resent-Sender ヘッダを指定するほうがいいかもしれない。(ただし、未検証)

解決方法その2:
エンベロープFromを指定して転送する
転送メールを送信するメールサーバのドメインのアドレスをエンベロープFromに指定。


■参考までに解決方法その2を実験した時の結果を紹介します
ここでは、以下の前提で話を進めます。

自分のメールサーバのドメイン:hoge.com
自分のメールサーバのIP:50.50.50.50

また、DNSのTXTレコードにはきちんとSPFの設定ができているものをします。
ここの例だと、

hoge.com. TXT "v=spf1 +mx +ip4:50.50.50.50 ~all"

といった感じでhoge.comドメインのメールを送信するメールサーバのIPが
SPFレコードに含まれているものとします。

ここで、

From: foo@docomo.ne.jp
To: aaa@hoge.com


というメールが携帯(DoCoMo)からhoge.comサーバに送られてきて、
それをbar@gmail.comというGmailアドレスに転送すると仮定します。

つまり、
/etc/aliases
に以下のエントリがあるものとします。

aaa: bar@gmail.com

その場合、docomo.ne.jp ドメインからのメールが、hoge.comというメールサーバからgmail.comに送信されることになります。
メールを受信するサーバは、送信ドメイン認証を行うわけですが、
当然、Fromヘッダのドメインがdocomo.ne.jpのメールがhoge.comから送信されるので、
gmail.comのメールサーバ側では偽装していると判断され、
SPFがFAILしたり、SPAMフォルダに振り分けられたりします。
また、最悪の場合、受信を拒否されます。

そこで、aliaseの設定を以下のようにして、
エンベロープFromをメールを実際に送信するサーバのドメインに変更します。

aaa: "|/usr/sbin/sendmail -oi -f aaa@hoge.com bar@gmail.com"

すると、めでたくSPFがPASSになります。


■未解決の問題
問題は、このことを知らずに転送メールを送り続けた結果、
自分のメールサーバがSPAMを送りつけるメールサーバとしてブラックリスト入りした場合です。

特にGoogleの場合、以下の内容のエラーメールが返ってきた場合です。

Delivery to the following recipient failed permanently:

これを回避する方法は今のところ見つけられませんでした。
Googleのアカウントマネージャに相談するしかないのでしょうか?


■参考までに送信ドメイン認証を行っているメールサーバ
ezweb.ne.jp(AU):
http://www.au.kddi.com/service/email/support/chui/spf_record.html

docomo.ne.jp(NTT DoCoMo):
http://www.nttdocomo.co.jp/service/communication/imode_mail/notice/sender_id/

yahoo.co.jp(Yahoo!)
http://pr.yahoo.co.jp/release/2006/1212a.html

gmail.com(Google):
http://www.fukatani.org/~hi-lo/blog/archives/2010/11/gmailspfdkim.html
http://www.google.co.jp/support/forum/p/apps/thread?tid=295af15255405e56&hl=ja


■参考にしたURL
http://kuro.crow2.net/problem/post_p3.htm
http://www.openspf.org/FAQ/Forwarding
http://www.itmedia.co.jp/enterprise/articles/0603/24/news007.html
http://www.atmarkit.co.jp/fsecurity/special/82senderid/sender101.html
http://www.google.com/support/a/bin/answer.py?hl=en&answer=168383
http://www.matsuaz.com/matsumotojs/2011/01/24/1295879296259.html
http://www.atmarkit.co.jp/fnetwork/rensai/netpro03/mail-header.html
http://gabacho.reto.jp/whims/whim0105.html