早い対応ありがとうございました♪

----------------
EC-CUBE3っぽいテンプレート
GitHub で公開中
https://github.com/bluestylejp

お問い合わせ番号CSV登録&メール送信プラグイン
http://urx.red/qDT6

shutta様

＞メールアドレスのチェックをRFC準拠にするかどうかを選択できるように変更してみました。

ありがとうございます。
テスト環境で反映してみます。

また、ご報告しますね！！！

メールアドレスのチェックをRFC準拠にするかどうかを選択できるように変更してみました。

http://svn.ec-cube.net/open_trac/changeset/18579
http://svn.ec-cube.net/open_trac/changeset/18580

また、ramrunさんが発見されたメールアドレスのEMAIL_CHECKの漏れも修正しておきました。

http://svn.ec-cube.net/open_trac/changeset/18581

----------------

リゾート会員権(エクシブ等)の売買・仲介

ramrunさま

度重なり、RESありがとうございます！

＞しかしそのルートはEMAIL_CHECKが抜けてました。

＞data/class/pages/entry/LC_Page_Entry_EmailMobile.php

なるほど。
ということは、方向性としては、ここをチェックさせる形で、EC-CUBEが更新される、ということでしょうかね？

了解です。
やっと、なんだか、腑に落ちました。
私も、思うところは、個人の意見として記載させていただきましたので、後は、開発の方の方針にお任せし、必要に応じて、こちらの要件にあわせたカスタムを行うことにします〜。

自分だけでは、きっと、原因も絞り込めず、問題点の抽出もできませんでした。
本当にありがとうございました。

引用：
どおりで話がかみ合わないと思っていましたが、そういうルート（抜け道）があったんですね（汗）。

確認したところ、フォームから送られてくるメールのチェックは

・EMAIL_CHAR_CHECK　メアドに使える文字のチェック
・EMAIL_CHECK　メアドの書式チェック
・MOBILE_EMAIL_CHECK　携帯ドメイン（@以降）のチェック

があって、PCは上の二つ。携帯は三つともチェックするのが基本のようです。
しかしそのルートはEMAIL_CHECKが抜けてました。

data/class/pages/entry/LC_Page_Entry_EmailMobile.php

他のところは大丈夫なのかはチェックしていません（汗）。
多分、ずっと以前から抜けていたんでしょうけど...

引用：
このあたりは、私個人の意見としては先に書いたとおりになりますので、あとはお任せですかね（汗）。

>もしかして私が勘違いしているのかもしれませんが、18352適用後は新規登録できませんよね？

本来、そうなのですか？？？
私は、18499からの導入で、残りのアップデートを手動で行っています。
ですので、18352適用後でも、該当する携帯メールは、新規登録できているようですが･･･

確認できている登録ルートは、PCで会員登録した後、携帯サイトで買い物をする際のログイン時に、携帯のメール登録を促され、そこで携帯メールを登録、というルートです。このルートでは、携帯のメアド登録は、RFC違反の携帯メールでも可能のようです。

とりあえず、チェンジセット18352を適用前に戻すというので、対応しました。
ありがとうございます！

DOCOMOやAUで、方針を一本化したメールアドレスに一元化されるまでは、今後も結構こういう事例が出てきそうですね；；；
その都度、運用方針を聞いて、チェンジセット18352のカスタム、というのも、スマートでないような気もします。
何か対応策として良い案は無いでしょうか。。。

引用：
もしかして私が勘違いしているのかもしれませんが、18352適用後は新規登録できませんよね？
tontonさんは運営中のサイトにこのチェンジセットを適用しているので、適用以前にRFC違反のメアドで登録を済ませているユーザーの買い物で問題になっているのでは？

なので単純にチェンジセット18352を適用しなければよい、ということではダメでしょうか。

ramrun様

なるほど〜。
そうすると、なんですが、、、

現状は、RFC違反の携帯メールもEC-CUBEで登録は、できているのに、会員情報や受注情報の編集を行ったときに、上書きできない、ということで、方針が一本化されていないのが、困った点です。
それをバグだと思う管理者さん（私か？？？）もいると思いますので、弾くならユーザーからの登録時にきちんとアテンションして弾くべきなのでは？と思います。

そして、その次に議論すべきなところが、
では、

実際DOCOMOやAUなどで、認められて、利用されているアドレスであるのに、EC-CUBEで弾いてしまったら、顧客サービスの面で面倒なことがちらほら出てくる
→だから撥ねない方針でいく

なのか、

いやいや、MICROSOFTもRFC違反の携帯メールは撥ねていることだし、EC-CUBEでもRFC準拠という姿勢は守るべき
→だから撥ねる方針でいく

なのか、というところですよね。。。

私は、MICROSOFTなどのフリーサービスではなく、EC-CUBEでは、メールの受発信は、顧客の利便性を重視すべき＆やっぱり国内通販はドメスティックなユーザーが多いことだし、そもそも迷惑メールはヤダそしてECサイトで買い物するためにメアド変えてくれるお客さんなんかいないよ〜〜〜（泣）ってことで、前者に一票なのですが･･･

いかんせん、えらそうに言っても自分で実装できるわけではないので、後は開発の方にお任せします；

でも、ちょっと、自分でカスタムが必要なときのために、このメールチェックをスルーさせる変更方法など教えていただけると激うれしいです！

よく考えたら途中のMTAで弾かれることもありそうなので、自分の環境を調べても意味ないのかもしれませんね（汗）。

tontonさんは実際に運用なさっている中での話しですので、問題としているところはよくわかります。

山河に在りて - RFC違反なメールアドレスの許可は天に唾するのと同じ
http://d.hatena.ne.jp/m_yanagisawa/20080722/p1

マイクロソフトでは
引用：
というスタンスで、基本的に弾くみたいですね。

マイクロソフト サポート オンライン - RFC　メールアドレス
http://support.microsoft.com/search/default.aspx?mode=r&query=RFC%E3%80%80%E3%83%A1%E3%83%BC%E3%83%AB%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9&spid=global&catalog=LCID%3D1041&1041comm=1&res=20

個人的には、これから新規にショップを立ち上げる場合は、RFC違反メアドを登録させない（締め出す）というスタンスで、すでに運用していて問題ない場合はチェンジセット18352を適用しない、ということでもよい気がします。
いつまでも容認していては、いつまでも無くならないという意味で...

ec-cubeでメールが送れるかどうかの手前に、各携帯キャリアでどのようなメールアドレスが登録できて、送受信できるか、ということではないかと思ったので、ちょっと調べてみました。


DOCOMOでは、下記のようになっており、AU、SOFTBANKでも同様のようです。
----------------------------------
＜アドレスに使用できる文字など＞

半角英数字および「_」（アンダーバー）、「.」（ピリオド）、「-」（ハイフン）の記号にて、3字以上30字まで設定することができます。
ただし、「.」は「..」などのように連続で使用することや@マークの直前で使用することはできません。
「スペース（空白）」は使用できません。
英字を入力する場合、大文字小文字の区別はありません。すべて小文字で表示されます。
先頭文字は英文字にして下さい。
----------------------------------
つまり、ルール上は、PCと変わらないのですね。（当然か；）
でも、DOCOMOでは、＠マークの前に「.」があっても認識されているようで、そういったアドレスで登録しているユーザーも結構います。（他のキャリアで実質登録できているのかは未確認）
メールの送受信は、そういったアドレスでも、実質PCからも携帯からもできています。もちろんEC-CUBEからも注文確認メールなど、届いています。

問題は、管理画面で受注ステータスの管理を行うときに、変更して更新しようとすると、ハネられてしまう、というところです。
（そうなってくると、その都度、ＤＢを開いて、メアドだけ上書き登録しないといけない、といった作業になってしまうので･･･）