 |
|
 |
| |
 |
「導入後の製品FAQ」セレクション
ここではふだん「サポート２」に収録されている「導入後の製品FAQ」の記事の中から、毎週火曜日に週替わりで３つの記事をランダムにセレクトしてご紹介いたします。E-Postシリーズ製品の機能に対する定番的な質問やより習熟するための使い方だけでなく、製品を取り巻く解決ノウハウの豊富さなどを感じ取っていただければ幸いです。
|
2025年8月第3火曜日分
|
 |
|
 |
|
E-Postシリーズは UTF-8 / 8bit Encoding のメールを文字化けせず正しく送受信できますか？
E-Postシリーズでは、メールデータの文字コードを変換したり置き換えたりすることは原則として行っていないのですが、受信したメールが文字化けしているものを調査しているうちに、あるユーザー様から標題のような質問を受けたことがあります。
それはユーザー様の環境で受けたメールの文字コードが UTF-8 で指定されているメールを調査しているうち、文字化けするものと、文字化けしていないものの両者のヘッダに下記の違いがあったため、E-Postシリーズで UTF-8 / 8bit Encoding のメールを文字化けせず受信できるかという質問内容でした。
・ユーザー様の環境で文字化けしていないメール
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
・ユーザー様の環境で文字化けしていたメール
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
この質問は、E-Postシリーズがメールサーバシステムとして8ビットを通さないのではないかという質問内容と同義だと考えます。結論から言うと、E-Postシリーズはメールサーバシステムとして8ビットも問題なく通します。具体的には以下のヘッダ構成の UTF-8 / 8bit Encoding のメールであっても文字コードを変換したり置き換えたりせず、そのまま通します。
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
しかしながら、大部分のメールクライアントは文字化けせず何の問題もなく表示できる一方で、メールクライアント種類によってはこの構成のメールを表示させる能力差が依然として存在する可能性は少なからずあります。世の中には、いまだ8ビットを通さないメールシステムやSMTPゲートウェイも存在する可能性があることを考えた方が無難です。そのため、送信元が努力する余地がもしあるとすれば、大事を取って "Content-Transfer-Encoding: base64" で Base64 符号化するのが最善ではないかと考えます。そのように提案している技術者やシステム開発者も多いです。
ちなみに、E-Postシリーズでは、メールデータの文字コードを変換したり置き換えたりすることは、一部の例外を除いては実施しません。一部例外のケースについては下記の記事をご参照ください。
（関連FAQ）
●E-Postシリーズでの文字コードの取り扱いについて
| |
 |
|
 |
|
|
|
|
|
SMTPゲートウェイの設定方法により user unknown の結果がエラー応答かエラーメール生成かが異なる
SMTPゲートウェイが構築されている環境では、内側のメールサーバにユーザーアカウントが存在しなかったり、無効なアドレスになっている場合は、user unknown という結果になるわけですが、SMTPゲートウェイをどのように設定しているかによって、user unknown のエラー応答を返すだけなのか、エラーメール生成して送信するかの違いが生じます。具体的には、下記関連ドキュメントや関連FAQ記事中にあるSMTPゲートウェイの設定方法について、次のどちらにしているかによります。
(A) エイリアスと実メールアドレスとをワイルドカードで指定する方法により、既存メールサーバーが管理しているドメイン名のついたすべてのメールアドレスを無条件に通す設定にしている
(B) エイリアスを実メールアドレスと１対１で指定する方法により、セキュリティ面を考慮し、既存メールサーバーが管理しているドメイン名のうち、存在する有効なアカウントのみ通す設定にしている
(A) 設定では、SMTPゲートウェイ位置の E-Post SMTP Server ではエイリアスと実アドレスをワイルドカード指定していますから、受信するアカウントがどのようなものであっても、いったん全部受けてメールサーバである E-Post Mail Server にすべて流します。その後、メールサーバである E-Post Mail Server でアカウントが実在するか、無効でないかなどを判定することになります。
すると、アカウントが無効であるという user unknown の応答は、SMTPゲートウェイ位置の E-Post SMTP Server に返され、応答を受けたSMTPゲートウェイ位置の E-Post SMTP Server が、送信元のMTAに user unknown の応答内容を含んだエラーメールを生成して送り出すということになります。
(B) 設定では、SMTPゲートウェイ位置の E-Post SMTP Server ではエイリアスと実アドレスを１対１で指定していますから、無効なアカウントはここで user unknown の応答を送信元のMTAに返すだけになります。こちらはエラーメールを生成することはありません。
エラー応答 "550 5.1.1 xxxx ... User unknown." のような「エラーコードとエラー応答」を送信元のSMTPに返すだけです。
結論として、万全な対策はよりセキュアな (B) 設定を取っていただくことに尽きます。SMTPゲートウェイ位置の E-Post SMTP Server で無効なアカウントかどうかをチェックすることが可能になり、エラーメール生成して送ることはせず、エラー応答だけを送信元に返すことになります。
ちなみに、(A) 設定時にエラーメールを生成して送り返す先は、実際のエンベロープFROMの内容に基づいて送られます。スパムメール発信者によって詐称されることが常態化しているのはヘッダーFrom情報の方です。ヘッダーFromの情報はE-Postを含め、すべてのMTAはふつうエラーメールを送り返すときには一切使いません。エラーメールはエンベロープFROMを元に返信されます。
（関連ドキュメント）
■技術資料『SMTPゲートウェイ基本設定と応用 Rev2.2』
（関連FAQ）
●SMTPゲートウェイとして利用したい
●SMTPゲートウェイとメールサーバの設定ポイント（E-Post Mail Server・E-Post SMTP Server）
●SMTPゲートウェイとして構築したとき踏み台にならないようにする
|
|
|
|
|
|
|
|
|
|
メール送信時のメールサイズ制限を設定しているが設定サイズより小さいサイズで制限されてしまう
メール送信時のメールサイズ制限を設定しているが設定サイズより小さいサイズで制限されてしまうという報告を受けたことがあります。
たとえば、社内パソコンからメール送信時のメールサイズ制限は10MB程度にするつもりで、E-Post Mail Control画面の「中継の制限」タブにある「メール受信時のサイズ制限」を「10000000byte」に設定したところ、7MBほどのサイズを越えるメール送信した時にエラー応答である「552 5.3.1 Requested mail action aborted: exceeded storage allocation.」が返されてくるというものです。
実はこれはE-Postに限らず、他のメール製品でもほとんど同様です。添付ファイルは仕組み的にMIMEエンコードされてメール本文に含まれていますが、MIMEエンコードされると一般的に約3割、厳密には133%程度、膨れることがその要因です。「MIMEエンコード サイズ」などで検索してみると、他のメール製品での対応策として同様の内容の情報が出てくると思います。
したがって、E-Postの設定を考える場合、E-Post Mail Control画面の「中継の制限」タブにある「メール受信時のサイズ制限」に入れる数値も、想定している送信サイズ制限として考えている数値の約3割増し（133%程度）にしてみてください。
ただし、たとえばぴったり10MBというように、厳密なサイズで制限させようとしてもどうしても難しいことがあります。上記の設定値はあくまでMIMEエンコード部分を含むメール本文を対象にしているため、実際にはヘッダも含まれます。ヘッダが少し大きくてもテキストですので、加味すべきサイズはしれているでしょうが、ヘッダサイズが大きいメールも存在することを考えて、ほんの少し余裕をもたせてみるのもよいかもしれません。
ちなみに、設定値はあくまでbyte単位ですので、KBやMBを計算していく方法として簡易的な×1000で計算するか、より厳密に×1024で計算していくかも数値は変わってきますので、その点も合わせて考慮に入れてください。
なお、「メール受信時のサイズ制限」の設定値を変えた後は、［適用］ボタンをクリックしてから、EPSTRSサービスの再起動が必要になります。
（関連FAQ）
●メールクライアントからの送信時にサイズ制限をかけるには
|
|
|
|
|
|
|
| |
|
|
|
|
|
