RFC違反のメールアドレス の許容

[ghost]

フロント側の「お客様情報の入力」画面で、メールアドレスを入力する項目について、相談させてください。
運用中のサイトから出てきた問題なのですが、過去のISSUESを確認するとこの箇所のチェックについてRFC2822の規格を元にチェック処理を行っていると思います。

最終対応、EC-CUBE3.0.5
#692
#829

それで、 問題点についてですがキャリアメールについて問題があるのを見つけました。
・NTTドコモ　メールアドレス
https://www.nttdocomo.co.jp/info/spam_mail/measure/change_add/
このサイトを見ると、

＊また、2009年4月1日以降、「.」は「..」などのように連続で使用することや@マークの直前で使用することはできなくなりました。 注意アドレス内に「..」や「.@」が存在する場合、一部のメールサービスからのメールが正しく届かない可能性がございます。

とあり、2009年4月より前は@より前に「..」が使えていました。

今回運用中のサイトで該当のメールアドレスが入ってきたので、今後どうして行くか検討の余地があるかなと思います。

[Yangsin]

RFC違反のアドレス自体は徐々に使えなくなっていっていると思っていますが、今回のケースの場合にお客様は代替の手段がないものでしょうか。
代替手段のないお客様がまだまだいるのであれば、２系同様に許容することも検討する価値はありそうです。それが日本製であるEC-CUBEの良さでもあるので。
ちょっと皆様の状況をお伺いしてみたいポイントですね。

[ttsuru]

結構跳ねられるシステム増えましたよね・・・
validationの厳密さを優先するか、ガラケー対応を優先するかという問題になりますね。

[nanasess]

顧客の某サイトでは、まだ2000件以上ありました。
docomo の SP モードでスマートフォンをお使いのお客様が多いです。

[shhirose]

これローカル部をダブルクォーテーションで括って送信すれば送信されると思います。
RFCのチェック有無を判定して、#829 で追加された validator の strict の値を false にし、送信処理でダブルクォーテーションをつければよいかと思います。
前の案件でやっていましたので大丈夫だと思うのですが、検証できる環境があれば検証していただきたいと思います。

例）hoge.@example.com → "hoge."@example.com

対応しようと思っていたのですが、時間と検証環境がないためなかなかできませんでした・・・。

[ttsuru]

@shhirose
RFC違反の動作を行うのでしたら、MTAごとに検証をしないといけないと思います。

[seasoftjapan]

@ttsuru
ガラケーのみなんでしたっけ? だったら、スルーしても良い気はします。
スマホでも存在するなら深刻ですね。

[seasoftjapan]

「..」とか「.@」を検出して、「"」クォートでフォーム入力するように誘導できないですか?

けど、インターフェイス的に、スマートじゃないか・・・

[nanasess]

スマホでも存在するんです。 docomo の SP モードや ezweb で過去に作成したメールアドレスを使い続けることが可能なので。某顧客のところでは2000件以上ありました。

[ttsuru]

@seasoftjapan
スマホ時代になってからアドレス変更をした方はRFC違反にはなっていません。
かなり前から変更していない方ですね。

[ttsuru]

@nanasess
2000件という数字よりも、その中で実際のアクティブユーザーが何％とか、全体の何％という方が議論になると思います。

[ttsuru]

本件は切り替えられるようになっているようが良さそうな気がします。。。

[ttsuru]

いつからRFC違反のアドレスに変更できなくなったかをまとめました。

2003年 vodafone移行時
2009年4月 docomo
2009年9月 au

[ttsuru]

SwiftMailer でも話題に上がっています。
swiftmailer/swiftmailer#71

[seasoftjapan]

本件は切り替えられるようになっているようが良さそうな気がします。。。

賛成です。

[ttsuru]

6年前にもEC-CUBEで話題になっていますね。
http://xoops.ec-cube.net/modules/newbb/viewtopic.php?topic_id=5456&forum=9

[shhirose]

2系の標準ではどうなんでしょうか？

[nanasess]

2系(2.11以降)は切り替えられるようになっていて、デフォルトは RFC違反も許容してます。

[shhirose]

その時はどのような対応だったんでしょうか？
基本的にその対応をするって方針でいいんではないでしょうか。

[nobuhiko]

3系は swiftmailer がエラーで落ちるということなのでこういう対応になっているんですが、そこは大丈夫なのでしょうか？

[shhirose]

そこも含めて検証する必要はありますね

[ttsuru]

@nobuhiko @shhirose
swiftmailer/swiftmailer#71
こちらにあるようにロジックの差し替えが必要ですね。

[Yangsin]

ざっとご意見拝見したかぎり。

ガラケーのサポートとRFC違反のメールアドレスの許容は別問題で、RFC違反のアドレスは未だ利用されており切替可能な事が望ましいですね。

[nanasess]

修正箇所が多く、切り替えできるまでは至ってないのですが、こんな感じの対応で送信できるようになると思います。
nanasess@5a646b1

[Yangsin]

切替まで実装することが困難なことから、カスタマイズTipsとしての扱いでドキュメントとしてまとめていくこととします。

[ttsuru]

こちら、他のSymfonyの案件で対応しました。
swiftmailer 6ではValidationの実装が分離されており、カスタマイズ可能となっています。

[ttsuru]

            "require": {
                "egulias/email-validator": "~2.0",
                "php": ">=7.0.0"
            },

なので採用は少しむずかしいかもしれません。

[chihiro-adachi]

#3667

[Yangsin]

#3667 が採用され、4系で実装済み