そもそも、メールアドレスに使用できる文字列は基本的にRFC2822で規定されている。
http://srgia.com/docs/rfc2822j.html
具体的には、
・大文字小文字のアルファベット
・数字
・! (エクスクラメーション)
・# (シャープ)
・$ (ダラー)
・% (パーセント)
・& (アンパサンド)
・' (シングルクォーテーション)
・* (アステリスク)
・+ (プラス)
・- (ハイフン、マイナス)
・/ (スラッシュ)
・= (イコール)
・? (クエスチョン)
・^ (キャロット、ハットマーク)
・` (バッククオート)
・{ } (中括弧開く閉じる)
・| (パイプライン)
・~ (チルダ)
・. (ドット、ピリオド)
・_ (アンダースコア、アンダーバー)
上記以外の文字の使用は不可。
"."(ドット)の使用は可能だが、連続しての使用は不可。
また、ローカル部(＠の左側)の始めや終わりにも使用不可。
という決まりがある。
最近は、各携帯電話会社も準拠するようになっているが、
少し前まで、一部のプロバイダや、携帯電話会社ではこの仕様に準拠していなかった。
で、困るのが準拠してない時代に、登録されたメールアドレスの取り扱いだ。
困る箇所が２つある。
まずはメールアドレスの登録時。良くあるメールアドレスの形式チェックで、
jakarta commons のvaridatorコンポーネントを使っている場合は、標準ではエラー扱いになる。
仕方ないから、EmailValidatorをオーバーライドして、USER_PATTERNを変更する必要がある。
自分の場合は、以下のように修正した。
private static final String USER_PATTERN = "/^\\s*" + WORD + "(\\.+" + WORD
+ ")*\\.*$/";
次に困るのは、ＭＴＡ側で送信時にエラーとなること。
他のＭＴＡでは試してないけど、今使ってるJamesは送信エラーになってしまう。
これも仕方ないから改造するしかない。
実際にチェックしている箇所は、apache-mailet-2.X.jar内の
org.apache.mailet.MailAddress#parseUnquotedLocalPart(String address)だ。
このメソッドの最後の部分の
if (lastCharDot) {
throw new AddressException(・・・)
}
をコメントアウトして、jarを固め直してJamesに反映させる。
これで一応は配信されるようにはなったが、どっかの中継先のＭＴＡでＮＧとなることは往々にしてあるだろう。
各携帯電話会社も結局準拠するなら、最初からしてりゃいいのに。
# ちなみにauだけはドットの連続はまだＯＫみたい。
近い将来は、そういう不正アドレスも消えていくんだろう。
やっぱり、標準基準というのは大事だな。
社内の小さなこともやはり標準化を進めて行かねば。
美紀といいます。
この度ブログを始めたので挨拶で
コメントさせて頂きました。
私のブログは競艇やギャンブルが主になっちゃうと
思いますが日常の事もいろいろ書いていくので
よかったらコメントください☆
http://ameblo.jp/boat-gals/
携帯会社のRFC2822「非」準拠は、インターネットメールを使った迷惑メールへの対策として推奨しているところがあるみたいですね。
少し前の話題でしたので、今はまた状況が変わっているかもしれませんが。
そういう（独りよがりの）「対策」は、他との連携に問題が出ることが多いので、なるべく止めて欲しいものですね（＾＾；
でも、最近は準拠してるしているようなので、
別の対応策が確立できたのでしょうかね～？
それか「非」準拠のバッシングがすごかったとか？？