問題タブ [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.

0 投票する
1 に答える
564 参照

zend-mail - DKIM ヘッダーの正規化では、To: ヘッダーの各コンマの後にスペースが挿入されますか?

Zend Framework 1.12、PHP 5.3.1 を使用。Zend_Mail に複数のメール受信者を指定し、Smtp トランスポートを使用すると、"To:" ヘッダーにはコンマで区切られた受信者のリストが含まれます。例えば

To: a@example.com,b@example.com

これは、 RFC 2822によると正しい構文のようです。DKIM 署名 ( https://github.com/louisameline/php-mail-signatureを使用) を追加しました。これは正常に機能し、gmail やその他の検証者が単一の To: 受信者で受け入れた署名を渡します。ただし、受信者が複数の場合、署名は失敗します。

署名付きメールを に送信check-auth@verifier.port25.comすると、さまざまなチェックの結果の中で、計算されたヘッダーと本文の正規化されたバージョンを含む電子メールが Return-path に返されます。To: ヘッダーを正規化するときに、各コンマの後にスペースが追加されていることがわかります (ヘッダーと本文の両方に緩和された正規化を指定しています)。実際、署名生成をハックして、To: ヘッダーを正規化するときにそのスペースを追加しました。これで問題が解決しました。port25.com ベリファイア、gmail などは署名を渡すようになりました。

しかし、 RFC 6376のセクション 3.4 をかなり注意深く読んだことや、上記で参照した github からダウンロードした署名クラスのコードなど、DKIM の緩和された正規化について私が見た説明では、何も追加されていない場所に空白を追加するものは何もありません。オリジナルに存在します。指定された正規化はすべて、既存の空白の変更に関するものです。

したがって、ポート 25 ベリファイアによって行われている正規化は、RFC 6376 と矛盾しているように思えます。ただし、gmail、autorespond+dkim-relaxed@dk.elandsys.com、およびhttp://www.appmaildevなどの他の DKIM ベリファイアは例外です。 com/en/dkim/はすべて最終結果に同意します (port25 のように実行した正規化は表示されませんが、カンマの後のスペースで正規化しないと、署名が拒否されます)。

ここに誰かがこれについて何か洞察を持っていますか? この分野での実践は、2011 年付けの RFC と一貫して異なるように見えるため、RFC を更新するべきではありませんか? もちろん、WSP を単一のスペースに置き換える前に、To: ヘッダー値のすべてのカンマをカンマ スペースに正規化する必要があるかどうか、および他のヘッダーが影響を受けるかどうかという問題もあります。

最終決議の概要

Evan の答えは OP に関して正確でした。私の MTA は、バリデーターの正規化ではなく、スペースを追加していました。実際に受信した To: ヘッダーを十分に注意深く見ていませんでした。

しかし、それを知っていても、正しい署名を生成するという問題を完全に簡単に解決できるわけではありません。「根本的な」問題は、Zend_Mail がヘッダー内のアドレスリストの値を生成する際に、カンマを区切り文字として使用して後続のスペースを使用しないことです。これは完全に有効な構文ですが、MTA がそれぞれの後にスペースを導入することも完全に有効です。また、RFC 6376 で指定され、広く実装されている緩和された正規化は、このような MTA の書き換えに対応していません。Zend_Mail のコードを変更してカンマ スペースを区切り記号として使用するのは簡単なことですが、それはかなり長くて複雑なメソッドの途中で行われるため、オーバーライドするためにコピー アンド ペーストを大量に行う必要があり、間違っていると感じられます。それで、私がやったことは、ヘッダーに署名する前にヘッダーにスペースを入れるプレフィルターを書くことでした。

0 投票する
1 に答える
4206 参照

smtp - from ヘッダーの表示名の検証/形式

name-addr電子メールの from( ) フィールドの検証/フォーマットのルールを知る必要があります。RFC では の形式を説明しましname-addrたが、 について詳しく説明しdisplay-nameます。

このような:

許可されている文字と長さを知りたいです。John Q. Public有効な文字があることをどのように確認できますか? 印刷可能な US-ASCII 文字のみを許可する必要がありますか?

RFC 2822を参照しましたが、表示名の特定の形式が見つかりませんでした

0 投票する
3 に答える
3443 参照

python - 複数の受信者にメッセージを送信するには?

Gmail API を使用して複数のアドレスにメッセージを送信するのに問題があります。1 つのアドレスにのみメッセージを送信できましたが、'To'フィールドにカンマ区切りの複数のアドレスを含めると、次のエラーが発生します。

エラーが発生しました: <HttpError 400 when requesting
https://www.googleapis.com/gmail/v1/users/me/messages/send?alt=json returned "Invalid to header">

この Gmail API ガイド のメソッドCreateMessageとメソッドを使用しています: https://developers.google.com/gmail/api/guides/sendingSendMessage

そのガイドには、Gmail API には RFC-2822 準拠のメッセージが必要であると記載されています。RFC-2822 ガイドのこれらのアドレス指定の例のいくつかを使用しても、あまり運がありませんでした: https://www.rfc-editor.org/rfc/rfc2822#appendix-A

「mary@x.test、jdoe@example.org、one@y.test」は、の「to」パラメーターに渡す有効な文字列である必要があるという印象をCreateMessage受けていますが、から受け取ったエラーが私をSendMessage導きますそうでなければ信じること。

この問題を再現できるかどうか、またはどこで間違いを犯しているのかアドバイスがあればお知らせください。ありがとうございました!

編集:エラーを生成する実際のコードは次のとおりです...

0 投票する
2 に答える
2142 参照

python - 文字列を日時オブジェクトに変換する

文字列を日時オブジェクトに変換しようとしていました。ニュース フィードから取得した文字列は次の形式です: "Thu, 16 Oct 2014 01:16:17 EDT"

datetime.strptime() を使用して変換してみました。つまり、

そして、次のエラーが発生しました:

トレースバック (最新の呼び出しが最後):
  ファイル ""、1 行目、datetime.strptime('Thu, 16 Oct 2014 01:16:17 EDT','%a, %d %b %Y %H:%M: %S %Z')
  ファイル "C:\Anaconda\lib_strptime.py"、325 行目、_strptime (data_string, format))
ValueError: 時間データ 'Thu, 16 Oct 2014 01:16:17 EDT' が形式と一致しません'%a, %d %b %Y %H:%M:%S %Z'

ただし、「EDT」なしで文字列を試してみると、うまくいきました。つまり、

その「EDT」部分を解析する方法を知っている人はいますか?

0 投票する
3 に答える
1614 参照

python - Pythonで日付と現在の日付を比較する

この形式の日時オブジェクトを比較するにはどうすればよいですか

「Thu, 15 Jan 2015 06:35:37 GMT」を現在の時刻で ?

0 投票する
1 に答える
551 参照

node.js - 短いがグローバルに一意の Message-Id を生成する

非常にユニークなMessage-Id.

Pythonが約 41 文字の長さのファイルを生成するのを確認しましたが、これは少し短すぎます。

助言がありますか?

0 投票する
2 に答える
2581 参照

email - Gmail が RFC 2822 に準拠していないとしてメールを拒否するのはなぜですか?

Mailgunを使用してメールを送信していますが、最近、毎日かなりの数のメールが Gmail によって拒否されていることに気付きました。

受け取るメッセージの種類は次のとおりです。

RFC 2822仕様は大規模なドキュメントであるため、最初から最後まで読んだことはありませんが、Web 上のリソースを見ると、私たちの電子メールは、Gmail からのこの種の応答を引き起こす一般的な落とし穴には該当しません。

メールヘッダーの例を次に示します。

私たちは何を間違っていますか?

0 投票する
1 に答える
580 参照

email - E メール実装の BCC フィールド

最近、電子メールの内容を解釈するためのアプリケーションを作成しています。このアプリケーションは、TO アドレス、CC アドレス、および BCC アドレスを提供します。

BCC フィールドを処理しているときに、BCC アドレスを直接取得できないようです。RFC2822を参照すると、さらに多くの疑問が生じます。

以下のアドレスのメールが送信されたとします。

私の質問は、受信者 bcc1@address.com が電子メールを受信したときに、電子メール ソース ファイルに「bcc1@address.com」が含まれているかどうかです。はいの場合、どのフィールドに配置されますか? そうでない場合、「bcc1@address.com」に関する情報がない場合に、このメールを受信者に送信するにはどうすればよいですか??

[更新]
電子メール メッセージにヘッダー部分を含む BCC 受信者の電子メール アドレスに関する情報が含まれていない場合、電子メール サーバーはこの電子メールを配信するメールボックスをどのように知ることができますか? サーバーがそのような電子メールを正しく転送する方法は?