問題タブ [rfc2822]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
parsing - RFC 2822 電子メール アドレスの解析 - テスト ケースの適切なリストはありますか?
私は RFC 2822 アドレス パーサー (バリデーターではない) を開発しています。アドレス形式の仕様は非常に複雑であり、発生する可能性のある奇妙なケースをすべて特定できるほど完全に理解しているとは思えません。
わかりやすくするために、ヘッダー行に表示される可能性のあるアドレスについて話しているので、奇妙な場所のコメントのようなものは、私が考えている種類の問題です.
email - これらの電子メール ヘッダー フィールドを理解するにはどうすればよいですか? (「差出人」フィールドには「より大きい」記号が前に付きます)
次のようなヘッダーを持つ未加工の電子メールがあります。
最初の 2 行を解釈する方法がわかりません。RFC2822を最初に読んだだけでは、手がかりがありません。これらは通常のヘッダーのようには見えず、Python 2.7 電子メール パーサーを混乱させることがあります ( >2 行目の先頭の記号を削除すれば問題ありません)。Apple メールのキャッシュに同じメール本文があり、問題ないように見えるので、入力は明らかに正しいです。
- そのヘッダー形式は何ですか？(
From <email> <date>\r\n) - 2 番目のものの前に
>(より大きな記号) が付いているのはなぜですか?
c# - .NET で MailMessage オブジェクトをシリアル化するエレガントな方法
私は現在、C# で MailMessage オブジェクトをシリアル化することを検討しています。ネット上にはいくつかの例のバリエーションがありますが、それらはバイナリにシリアル化され、IMO のポイントを逃しています。
私のアプローチは、MailMessage を RFC2822 eml 文字列にシリアル化したいというもので、以下のコードは私が思いついたものです。
それはかなり厄介ですが、うまくいきます。ただし、理想的には、新しい SMTPClient を作成し、ファイル システムにヒットすることなく rfc822 文字列を自動的に返す Serialize 関数を追加します。
Visual Studio で SMTPClient.Send 関数を追跡できないように見えるので、この「理想的な」方法は少しトリッキーです。
Peter Huber の POP3MimeClient および POP3MailClient クラスにいくつかの小さな変更を加えて、RFC メッセージの逆シリアル化を既に整理して、HDD 上のファイルまたは文字列を逆シリアル化し、MailMessage に戻すことができるようにしました。
私を悩ませているのは、上記のコードのように GUID ベースのフォルダーを作成するために家を回る代わりに、ストリームを使用して MailMessaage をシリアル化し、そのストリームを自分の選択した文字列またはファイルに書き込むことができるはずだということです。ファイルの内容を文字列に読み込んでいます...
これをよりエレガントにする方法についての指針は大歓迎です。
ありがとう。
python - Pythonで電子メールのメッセージIDを作成するにはどうすればよいですか?
Python の組み込みライブラリを使用して作成されたメッセージに、一意のRFC2822準拠Message-IDのヘッダーを追加したいと考えています。どうすればこれを行うことができますか？図書館自体の中に道はありますか？email
email-headers - 宛先アドレス要件が RFC 822 から RFC 2822 に変更された理由
RFC 822 では、セクション C.3.4 で宛先アドレスがヘッダーに表示される必要がありました。「メッセージには、少なくとも 1 つの宛先アドレス フィールドが含まれている必要があります。'To' と 'CC' には、少なくとも 1 つのアドレスが含まれている必要があります。」RFC 2822 および 5322 のセクション 3.6。どちらも、「必要なヘッダー フィールドは、発信日フィールドと発信者アドレス フィールドだけです」と書かれています。
この変更の背後にある理由が何であるかに興味があります。IETF がメーリング リストのアーカイブと議事録を持っていることは知っていますが、それがメーリング リストに記載されている場合、アーカイブを検索しても見つけるのに苦労します。
email - メール クライアントからのメールの書式設定
私は、標準化された電子メール形式についていくつかの調査/テストを行ってきました。最終的には、アプリケーション用の電子メール パーサーを開発したいと考えています。主にメール クライアント (gmail、mac メールなど) とメール マーケティング サービス (Constant Contact、Mail Chimp など) の間で、メールの形式にいくつかの違いがあることに気付きました。
形式 ( RFC2822 ) についての私の理解は、 a\n\nがヘッダーを本文から分離することです。これらは、電子メール マーケティング サービスから受信した電子メールと一致しているようです。ただし、電子メール クライアントには、追加のヘッダー セットまたはメッセージの指示があるようです。以下の電子メール文字列の例を参照してください。これらの文字列を電子メール パイプ経由で取得したことに注意してください。また、これらはヘッダーと本文の分割のスニペットにすぎないことに注意してください。
メールマーケティングサービス:
ここでは、ヘッダーと本文を区切る改行が表示されます。フォーマットによると、すべて良い。次に、電子メール クライアントを見てください。
メール クライアント:
この場合、追加の「ヘッダー」のセットがあることがわかります。これは、この場合、Mac Mail が電子メールをどのようにフォーマットしたかについての指示のように見えます。
私の質問は、これは有効な形式ですか? それについての仕様はありますか？どのタイプのフォーマットが受信されているかを知らなくても、このタイプのフォーマットをチェックして解析するよく知られた/文書化された方法はありますか?