(1) alias又はforwardによるアドレス変換の注意事項
Sendmailでalias又はforwardによってアドレス変換をしているメールをGroupmax Mailで参照する場合は,宛先として変換前のアドレスと変換後のアドレスの両方が表示されます。これは,aliasまたはforwradによって,メールヘッダにある受信者(To,Cc)とは異なる受信者にメールを転送した場合に発生します。このような実際の受信者とは異なるメールをMail - SMTPが受信した場合には,メールヘッダにある受信者のアドレスマッピングが行えません。
対処方法としては,Sendmailで転送する際にメールヘッダ中の受信者情報(To,Cc)を,Mail - SMTPで受信する時の受信者アドレスに変換してから,転送するようにしてください。
(2) 外字を含むメールの注意事項
メールの主題,本文,添付ファイル名に外字が含まれていた場合,主題,本文,添付ファイル名の内容は正常に変換されません。この場合,JISコードでは0x8000以降の文字が,SJISコードでは0xF000以降の文字が正しく変換されません。詳細の範囲については下記を参照ください。
(3) Bccユーザを含むメールの注意事項
インターネットから受信したメールにBccユーザがいる場合,Groupmax MailではToとして表示される場合があります。
Bccユーザの情報がToとして表示されるのを回避するには,smtpmngコマンドメニューから,以下の手順でコンフィグレーション情報を変更してください。
「BCC受信者の設定(bcc_recipients)」を「on」にしたときの例を示します。
次に示す3人のユーザがGroupmax Address Serverに登録されていたとします。
インターネットから次のようなメールを受信した場合の同報者の表示例を,Bcc指定されたユーザ1とTo指定されたユーザ2,ユーザ3ごとに示します。
Bcc:taro@soft.hitachi.co.jp
To:hanako@soft.hitachi.co.jp
To:jiro@soft.hitachi.co.jp
(4) メールの同報者が256人を超えた場合の注意事項
SMTPから受信したメールの同報者(Resent-To,Resent-Bcc,Resent-Cc,To,Bcc,Ccの合計)に256人以上のGroupmax Mailの宛先が指定されていた場合,Mail - SMTPは257人目以降の受信者情報は破棄して,以下のエラーメッセージを出力します。
Smtpgw170: 受信者の最大数を超えたため256人以降の情報を破棄しました。
(5) 組織メールの処理についての注意事項
Groupmax Mailから受信したメールの送信者が組織メールアドレス(姓フィールドの先頭が「#」)だった場合,Mail - SMTPはこのメールを破棄します。また,送信者にエラーレポートを返信し,以下のエラーメッセージを出力します。
Smtpgw174: 組織メールユーザ情報を破棄しました。
Groupmax Mailから受信したメールの受信者に組織メールアドレスが含まれていた場合,組織メールアドレスだけを破棄して配信処理を続行します。なお,SMTPから受信したメールの本来受信者に組織メールアドレスが指定されていた場合,Mail - SMTPはこのメールを破棄して,以下のエラーメッセージを出力します。
Smtpgw174: 組織メールユーザ情報を破棄しました。
(6) 代行受信する場合の注意事項1
Groupmax Mailから送信したメールの受信者が代行受信者を設定している場合,その代行受信者があて先ユーザ(E-mailアドレス)である場合,E-mailアドレスの受信者では,あて先のヘッダが以下のようになります。
代行先の受信者(E-mail):BCC
代行を設定した受信者:メールの送信者が指定したメール種別(TO/CC/BCC)
例)
Groupmax MailのユーザAさんがGroupmax MailのユーザBさんにTOを指定してメールを送信し,Bさんが代行受信者としてあて先ユーザCさん(E-mailアドレス)を設定している場合,Cさんが受け取るメールは,BさんがTOとして,CさんはBCCとしてメールが受信されます。
(7) 代行受信する場合の注意事項2
Groupmax Mail内で2回以上代行受信されてからMail - SMTPを経由してインターネットに代行受信された場合には,送信者に配信報告が返信されません。配信報告が返信されない場合,送信一覧でメールの送信状態が「送信中」のままになります。
例1)
GropumaxユーザのAさんがBさんにメールを送信し,Bさんがあて先ユーザXさん(インターネットユーザ)に代行受信していた場合には,配信報告がAさんに返ります。
例2)
GropumaxユーザのAさんがBさんにメールを送信し,BさんがCさんに代行受信し,Cさんがあて先ユーザXさん(インターネットユーザ)に代行受信していた場合には,配信報告がAさんに返りません。
(8) リッチテキスト本文の連携を行う場合の注意事項
リッチテキスト本文を含むメールを送信する場合,添付ファイルのヘッダにリッチテキスト本文であることを示す付加情報を生成しています。この為,転送元のメールをメールヘッダも含めすべて再利用し,部分的なデータの差し替えをして転送が可能なクライアントで転送されたメールを受信した場合に,転送時に編集された本文を読めない場合があります。これは,リッチテキスト本文を示す付加情報を含むメールが転送されるため,Mail - SMTPがメールを受信した場合に,転送された添付ファイルをリッチテキスト本文として処理するためです。
この現象を回避するには,メールを転送する際にメールヘッダを再利用しない「返信」機能を利用していただくようお願いします。
(9) Unicodeで送信されたメールの受信について
Mail - SMTPでは,Unicodeで送信されたメール(charsetに"utf-7","utf-8"または"utf-16"が指定されている場合)を受信した場合,JISの第一水準および第二水準に対応する文字コードだけ変換を行います。変換できない文字は"?"に変換します。
charsetに"utf-7","utf-8","utf-16"以外が指定されている場合(charsetが指定されていない場合を含む),本文や,テキスト形式の添付ファイルのcharsetを「iso-2022-jp」と仮定して受信します。このため,Groupmax Mailクライアントを使用してメールを受信しても正しく表示することができません。また,MIME構造情報を添付ファイルとして受信した場合(MIME_STRUCTURE=on)も,文字コード変換を行っていますので,インターネットクライアントを使用しPOP3/IMAP4でメールを取得した場合も同様に文字化けします。テキスト形式の添付ファイルを文字コード変換しないで受信する方法については,「7.5.18 テキスト添付ファイルを文字コード変換しないで受信したい」を参照してください。
また,MIME構造情報を添付ファイルとして受信する設定(MIME_STRUCTURE=on)の時,Unicodeで送信されたメールを受信し,Groupmax Mail Server 06-51より古いバージョンのサーバからPOP3/IMAP4クライアントでメール受信すると,本文がないメールが受信されます。POP3/IMAP4サーバとして使用するGroupmax Mail Serverが06-51以降でない場合,MIME構造情報を添付ファイルとして受信しないよう(MIME_STRUCTURE=off)に設定してください。設定方法については,「2.3.4 edit_format (4) edit_recvformatで設定する値」を参照してください。
(10) Mail - SMTP環境のworkディレクトリについて
smtpdir下のworkディレクトリにはファイルを置かないでください。ファイルを置いた場合,Mail - SMTPを次回起動したときに削除されます。
(11) Sendmailの経路による文字化けについて
メールが転送される経路によっては,経由するSendmailのバージョンにより主題,本文が文字化けする場合があります。
(12) Groupmax Server - Scanが分割メール中に含まれるウィルスを検出できない問題について
インターネットクライアントは1通のメールを分割送信する場合,RFC2046で規定している方式で分割して送信します。インターネットクライアント(POP3/IMAP4)を使用してGroupmax Mail Serverから分割メールを取り出しますと,分割メールは復元され一つのメールになります。この分割メール中にウィルスが含まれていた場合,復元されてはじめてウィルスが顕在化します。この復元されたウィルスが顕在化したメールを参照することにより,ウィルスに感染する恐れがあります。
なお,Groupmaxのクライアントでは分割されたメールを結合する機能はないため,本件には該当しません。
(a) 発生条件
下記すべての条件に該当した場合にウィルスに感染する恐れがあります。
(b) 対応策
以下のいずれかの対応策があります。
(13) Mail - SMTPのINTERNETDOMAIN名と同じドメイン名である受信者(E-mailアドレス)が同報者にいる場合,そのアドレスは生成されません。