メッセージ サイズの拒否は、受信サーバーがすべてのメッセージ認証を評価する前に発生する可能性があります。また、上流サーバーがメッセージを受け入れ、後のホップでより小さい制限が適用された後に表示されることもあります。すべての永続的な拒否を問題として扱うのではなく、拒否するホップでのサイズ状態を診断します。 SPF, DKIM または DMARC 欠陥。
サイズとポリシーおよびストレージを区別する
RFC 3463 、X.3.4 を受信システムにとって大きすぎるメッセージとして定義し、X.2.3 をメールボックスの管理制限を超えるメッセージ長として定義しています。これらは、X.2.2 メールボックスがいっぱいであるとは異なります。製品には独自の制限、単位、説明文が追加されている場合があるため、診断全体をお読みください。一般的な「552」ラベルだけでは、構成された制限を正確に確立することはできません。 RFC 3463セクション 3.3 および 3.4.
認証の失敗は、メッセージ オクテットの数ではなく、アイデンティティ、署名、またはポリシーに関係します。サイズの縮小はDKIM修復ではありません。署名されたコンテンツを変更すると、それ自体が署名を無効にする可能性があるため、承認された置換は通常の署名ワークフローを通過する必要があります。逆に、 SPFで別の IP を許可しても、受信者に許可されるメッセージ サイズは増加しません。独立した証拠が両方とも失敗していることを示していない限り、2 つの調査を別々にしてください。
アドバタイズされた SIZE 機能を正しく読み取る
SMTP SIZE 拡張機能を使用すると、サーバーはサポートをアドバタイズし、オプションで最大メッセージ サイズをそのサーバー内でアドバタイズできるようになります。 EHLO 応答。サポートしているクライアントは、次のように推定サイズを提供できます。 メール送信元、メッセージ全体を送信する前に拒否できるようになります。数字のない SIZE は、固定された最大値の情報を伝えません。 SIZE 0 は、固定最大値が適用されていないことを明示的に示します。どちらも受け入れを保証するものではありません。その後の処理や他のホップでも制約が課される可能性があります。 RFC 1870セクション 3 および 4.
RFC 1870 SIZE の場合、CRLF 行末、ヘッダー、 MIME構造、エンコードされたコンテンツを含むメッセージ オクテットをカウントしますが、DATA 終了ドットと余分なドット詰め込みバイトは除きます。添付ファイルのみをカウントしないでください。 Base64 エンコードではバイナリ データが拡張され、改行と周囲のメッセージ部分によりバイト数が追加されます。見る RFC 2045セクション 6.8。プロバイダーのインターフェイスでは、丸められた単位が異なる方法で表示される場合があります。 2 つの説明のない「MB」ラベルを比較するのではなく、測定されたオクテットと、公表または文書化された正確な制限を記録します。
制御されたバリアントを比較する
サイズ関連のコンテンツのみが異なる 2 つの承認済みバリアントを作成します。シリアル化された小さいサイズと大きいサイズ、および各結果のSMTPステージを保持します。例示的なペアには、同じ短い説明テキストが含まれ、大きな添付ファイルが承認されたアクセス制御されたファイル リンクに置き換えられる場合があります。ファイル リンクが機密資料に適している、または受信者がアクセスできるとは想定しないでください。
RFC 5321セクション4.5.3.1 .7 では、ヘッダーを含めて少なくとも 64K オクテットのメッセージ サイズのサポートが必要です。次の 100,000 オクテットの制限はプロトコルの最小値を超えており、推奨されるプロバイダー設定ではありません。
仮想の算術チェックでは、同じエンドポイントが SIZE 100000 をアドバタイズすると仮定します。想定される 115,900 オクテットのメッセージは、その制限を 15,900 オクテット超えます。想定される 20,100 オクテットの置換は、その 79,900 オクテット下にあります。最初のものは MAIL FROM で拒否できます。 2 番目はさらに処理することができますが、受け入れられるかどうかは保証されていません。これらの数値は作成されたものであり、測定値や実行されたSMTP結果ではありません。これらは、プロバイダーの接続上限については説明しません。
関連する最も狭い制約を修復します
拒否するシステムの所有者に、そのサイズが意図的なサービス制限なのか、組織が管理する設定なのかを尋ねてください。ビジネス ニーズをより小さいファイルで満たせる場合は、メール システム全体の制限を引き上げるのではなく、そのルートを使用してください。制限の変更が許可される場合は、適用する前に、リソースの消費、マルウェアのスキャン、およびダウンストリームの互換性を考慮してください。
永久に拒否された同じコンテンツを変更せずに再試行し続けないでください。オリジナルが別のホップまたは別の受信者で受け入れられなかったことを確認し、以前の試行との明確な関係を付けて、承認された代替案を送信します。独自のメッセージとキューの識別子を保持します。新しいメッセージは、ユーザーが同じ添付ファイルとみなした場合でも、新しい配信イベントです。
最後に、測定されたメッセージ サイズ、識別された拒否制限、および修正された試行の結果を表示します。受信箱の配置とリンクされたコンテンツへの受信者のアクセスは、別個のチェックとして残しておきます。
制限と回避策を分離する
- 対策: 添付ファイルだけでなく、SIZE 定義を使用してシリアル化されたメッセージ全体をカウントします。
- 特定: 拒否ホップ、コマンド ステージ、診断および適用可能な制限をキャプチャします。
- 修復: 承認された小さいメッセージまたはアクセス制御された配信方法を選択します。
- 再確認: 置換サイズと受信者ごとの結果を記録します。すべてのダウンストリーム制限が一致するとは限りません。
- 閉じる: SMTP受け入れとは別に受信者のアクセスを確認します。