問題タブ [rfc5322]

電子メールのメッセージIDヘッダーはどの程度一意ですか？2人にメールを送信した場合、両方のメッセージIDは同じになりますか？それとも違うのでしょうか？

（これは、誰も面白いビジネスをしていないことを前提としています。スパムを使用すると、すべてのルールがウィンドウから外れることを知っています...）

メールから日付を取得しようとしています。最初は簡単です：

そして私は受け取ります：

しかし、素敵な日時オブジェクトが必要なので、次を使用します。

を発生させValueError, since %Z isn't format for +0100ます。しかし、ドキュメントでタイムゾーンの適切な形式が見つかりません。ゾーンにはこれしかありません%Z。誰かがそれについて私を助けることができますか?

RFC 5322 のセクション 3.6.2では、返信先ヘッダーを次のように定義しています。

address -listはセクション 3.4で定義されています。ABNF 文法を展開すると、アドレスリストphrase ":" ";"は(セクション 3.2.5で定義されている句)だけで構成できることがわかります。つまり、実際の電子メール アドレスを含まない返信先ヘッダーを追加できるということです。

RFC には次のように記載されています。

「Reply-To:」フィールドが存在する場合、メッセージの作成者が返信の送信先として提案するアドレスを示します。

たとえそれが単なる提案であっても、私が名前を付けたが特定しないアドレスに返信するよう誰かに提案できるのは、かなり奇妙に思えます。

ここで何か不足していますか？このような構造をどのように解釈すればよいでしょうか。

メールヘッダーは大文字と小文字を区別しますか?

たとえば、?とはContent-Type異なります。Content-type

RFC 5322によると、大文字と小文字の区別については何も表示されません。しかし、PEAR Mail_mime モジュールを使用して MIME メッセージを作成する際に問題が発生しており、SMTP サーバーがContent-typeandMIME-versionの代わりにContent-Typeandを使用しているという事実がすべて指摘されていますMIME-Version。別の SMTP サーバー (GMail など) を使用してみましたが、残念ながら私たちの Web サーバーはかなりしっかりとファイアウォールで保護されています。

PHP マニュアル (http://php.net/manual/en/function.mail.php) は次のように述べています。

各行は LF (\n) で区切る必要があります。行は 70 文字を超えてはなりません。

しかし、実際の RFC 5322 では、まったく異なる情報が提供されます。

2.3. 本文 メッセージの本文は、単なる US-ASCII 文字の行です。本体の制限は次の 2 つだけです。
o CR と LF は、CRLF として一緒にのみ発生する必要があります。それらは体内で独立して出現してはなりません。o 本文の文字行は 998 文字に制限する必要があり、CRLF を除いて 78 文字に制限する必要があります。

そのため、RFC では、\r\n のみを使用する必要があると述べています。わかりません - php mail() はバックグラウンドでどのように動作しますか?

これはおそらく奇妙な質問ですが、先に進んで質問したいと思いました。たとえば、 IMAP SMTPを使用して、特別なクライアントを介して電子メールを送信します。このクライアントは、途中で送信する前に、電子メールメッセージにいくつかのカスタムヘッダーを追加します。受信者はこの電子メールを受信し、私に直接返信します（おそらく、CCも数人です）。

私の質問はこれです：上記の例を考えると、これらのXヘッダーはスレッド内のすべての新しいメッセージを通して持続しますか？

私が考えることができることの1つは、クライアントが送信した元の電子メールメッセージを認識しているということです。この電子メールへの後続のすべての応答には、前の電子メールの「Message-Id」と同じ値を持つ「Reply-To」ヘッダーが含まれます。クライアントから送信された元のメッセージに到達するまで、これらの応答スレッドをクロールできなかった理由がわかりません。これにより、元のカスタムヘッダーが取得されます。

多分私はこれを考えすぎています。助言がありますか？:)

特定の長さを超える外国語の文字を含む件名で爆破する、mime 解析ライブラリのバグに遭遇しました。件名を Quoted-Printable MIME " Encoded-Word " に変換し、全体を 78 文字にワードラップしようとすることが判明しました。MIME-Word エンコーディングにはスペースがない (アンダースコアに置き換えられる) ため、ラップに失敗しました。

折り返される行の例:

行を正しく折り返すためにライブラリにパッチを提供するかもしれないと思ったのですが、ワード ラッピング アルゴリズムの一部として MIME-Word を分割する方法に関する参照が見つかりませんでした。

RFC 5322では、スペースでワードラップするように指示されていますが、ターゲット幅を超える空白のない文字列がある場合に何をすべきかについてのガイダンスは提供されていません。

ここで取るべき正しい行動を知っている人はいますか？

のようなメッセージが後付けされた自動メールをよく見かけます。

アマゾン：

※ご注意：このメールは、受信メールを受け付けないアドレスから送信されています。この同じ問題について再度お問い合わせいただく必要がある場合は、上記のリンクを使用してください。

ツイッター：

このメッセージには返信しないでください。監視されていないメールアドレスから送信されました。このメッセージは、Twitter の使用に関するサービス メールです。

Google チェックアウト:

助けが必要？Google Checkout ヘルプセンターにアクセスしてください。このメッセージには返信しないでください。

この警告のすぐ下に、Gmail の返信入力フィールドが表示されます。受信者の電子メールクライアントに返信を許可しないように指示する、そのような自動化された電子メールに添付できるヘッダーのようなものがあるべきだと私には思えます。

そのようなヘッダーはありますか？そうでない場合、電子メール形式を管理するグループによって議論されたことはありますか?

RFC 5321、5322、および6531には、電子メール アドレスを検証するための複雑な規則があります。彼ら：

• メールアドレス内にコメントを作成できるようにする
• シンボルに対して複雑な制限規則を提供します。"() ,:;<>@[\]
• localpartpostmasterは大文字と小文字を区別しないが、その他はすべて大文字と小文字を区別するものとして扱う
• メールアドレスのグループを許可する

これらの複雑なルールのおかげで、特定の文字列が構文的に有効な電子メール アドレスであるかどうかを RFC に従ってテストすることは、正規表現だけでは実行できません。

どうやら、これらのルールの多くは、主要な電子メール プロバイダーによってサポートされていません。

歴史的に言えば、電子メール アドレスに関する非常に複雑なルールを作成する動機は何でしたか? 電子メールの起源に関するウィキペディアの記事は、 1980 年代初頭の最新の標準が、特定の標準と構文を使用してすべての従来の電子メールっぽいシステムをカバーすることを意図していたことを暗示しているように思われます。

ただし、標準の実装者、電子メール プロバイダー、および電子メールのエンドユーザーはすべて、機能するシステムに既得権を持っています。これは、ルールが難解すぎず、有限数のテストに合格するソフトウェアに簡単にキャストできる場合に達成しやすくなります。では、なぜ今日、誰もそれを十分に活用していない複雑な標準を持っているのでしょうか?

繰り返しますが、歴史的に言えば、XML は大部分が JSON に取って代わられました。その成功は、その文法の単純さに部分的に起因する可能性があります。