問題タブ [rfc5322]

rfc5322 Line Length Limits を理解しようとしています。行制限は 78 文字ですか、それとも 998 文字ですか? 1 つは本文用で、もう 1 つはヘッダー用ですか? それを特定するものは何も見つかりません。

Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.

RFC、要約、ウィキペディアなどを読んでいます。ローカル部分とラベルについて非常に混乱しています。local-part が @ の前にあるように私には思えます。それは簡単に思えます。ラベルは、ドットで区切られたドメインの一部です。しかし、一部の場所では、ローカル部分をラベルと呼んでいるようにも思えます。そして、ハイフンが許可されている場所のコンテキスト内では、これは非常に紛らわしいです. では、ラベルとは具体的にどのようなものでしょうか。

では、有効なメール アドレスはどれですか (ある場合)。

私の理解では、ラベルはハイフンで終了または開始することはできず、2 つの連続したハイフンを含めることはできません。私はそれで何か不足していますか？

ボーナスポイント - ローカル部分には多くの特殊文字が許可されていますが、ローカル部分は英数字で終わる必要があると私が見たいくつかの情報源がありますが、実際にはどの標準でもそれを見ていません..私はそれを見逃していますか、それとも許可された文字の1つで終わることができますか?

RFC5322 電子メール アドレスを解析しようとしています。私のパーサーは、結果のうちの 1 つが正しいという意味で機能します。ただし、「正しい」結果を選択するにはどうすればよいでしょうか。

文字列Foo Bar <foo@bar.com>を指定すると、パーサーは の値を生成するはずですAddress (Just "Foo Bar") "foo@bar.com"。

または、文字列 が与えられたfoo@bar.com場合、パーサーは の値を生成する必要がありますAddress Nothing "foo@bar.com"。

名前が含まれている値が優先されます。

私のパーサーは次のようになります。

でパーサーを実行するとreadP_to_S rfc5322 "Foo Bar <foo@bar.com>"、次の結果が生成されます。

この場合、実際に必要な結果はリストの最後から 3 番目に表示されます。その好みをどのように表現しますか？

RFC5322および以下に従って電子メール ID を検証する

https://en.wikipedia.org/wiki/Email_address

以下は、Java と正規表現を使用して電子メール ID を検証するサンプル コードです。

実際の出力:

期待される出力:

以下のパターンの電子メール ID を無効にするように正規表現を変更するにはどうすればよいですか。

正規表現の基準は次のとおりです。

ローカル部

電子メール アドレスのローカル部分には、次の ASCII 文字を使用できます。

1. 大文字と小文字のラテン文字A to Zとa to z;
2. 数字0 to 9;
3. 特殊文字 !#$%&'*+-/=?^_`{|}~
4. ドット.は、引用されない限り最初または最後の文字ではなく、引用されない限り連続して現れないことを条件とします (たとえば、許可されていませんJohn..Doe@example.comが、許可されてい "John..Doe"@example.comます)。
5. space"(),:;<>@[\]文字は制限付きで許可されます (以下の段落で説明するように、引用符で囲まれた文字列内でのみ許可されます。さらに、バックスラッシュまたは二重引用符の前にバックスラッシュを付ける必要があります) 。local-part のどちらかの端に括弧を付けてコメントを入れることができます。たとえば john.smith(comment)@example.com、 と (comment)john.smith@example.comはどちらも と同等 john.smith@example.comです。

ドメイン

1. 大文字と小文字のラテン文字A to Zとa to z;
2. 0 to 9トップレベルのドメイン名がすべて数字ではない場合、数字。
3. ハイフン-(最初または最後の文字でない場合)。コメントは、ローカル部分だけでなくドメインでも許可されます。たとえば、john.smith@(comment)example.comと john.smith@example.com(comment)は と同等 john.smith@example.comです。

MBox ファイルのコレクションを解析しているときに、次の形式の Date ヘッダー フィールドが驚くほど多くあることに気付きました。

"Date:" date-time "<" addr-spec ">"

利用可能な RFC を読んでも、一致する構文が見つかりません。有効な形式は次のようです。

"Date:" date-time [CFWS]

CFWS は、RFC5322のセクション 3.3 (日付と時刻の仕様) で説明されているように、コメントと折り畳み空白を表します。

著者が132kの日付ヘッダーを分析する適切なメール日付ヘッダー形式の読み取り、それでも上記のフォームはリンクされたデータセットに表示されません。

これは、MBox アーティファクト、IMF 属性、またはメール エージェントやメール リレーによる破損ですか?

インターネット メッセージ フォーマットは 1980 年代から進化してきました。これはやや混乱しており、HTTP のようにさまざまな方法で解釈されてきました。これはベンダー固有の変更であり、不正な形式の Date ヘッダー フィールドになる傾向がありますか? IDK。

例 MBox

仕様

• RFC5322
• RFC2822
• RFC822
• RFC4021
• MBox 形式
• MBOXO フォーマット
• MBOXRD形式
• MBOXCL フォーマット
• MBOXCL2 形式
• RFC5321
• RFC2821