説明不能なメール::受信者::無効な投稿エラー

Mailing Lists - Tor Project Forum でメーリングリストをいくつかミラーリングしています。

最近、Mailman3 メーリングリストからフォーラムへのメッセージのミラーリングがいくつか行われていないことに気づきました。

メール拒否ログには、これらのメールが Email::Receiver::InvalidPost エラーに遭遇したことが示されています。

ログに記録されたエラーメッセージは、次のいずれかです。

申し訳ありませんが、[“tor-relays@lists.torproject.org”] へのメールメッセージ(件名:[tor-relays] authority bandwidth measurements and latency)は機能しませんでした。

理由:

アクセス拒否

問題を修正できる場合は、もう一度お試しください。

または:

申し訳ありませんが、[“tor-relays@lists.torproject.org”] へのメールメッセージ(件名:[tor-relays] Re: webtunnel bridges for the telegram distributor)は機能しませんでした。

理由:

何か問題が発生しました。おそらく、表示中にトピックが閉じられたか削除されたのでしょうか?

問題を修正できる場合は、もう一度お試しください。

ヘッダーを確認したところ、これらのメッセージに問題は見つかりませんでした。ただし、一部のインスタンスでは、ログに記録された抽出本文にはメーリングリストのフッターしか含まれていないか、別のインスタンスでは、デコードの不具合があったかのような、意味不明な文字の羅列になっています。

テストメーリングリストとテストカテゴリを使用してこの問題を再現しようとしましたが、成功しませんでした。このデバッグにご協力いただけると幸いです。

「他のアカウントからのメールを受け入れる」が各カテゴリ設定で有効になっているか、またDiscourseのメールログ(可能であれば一部編集したもの)を送っていただけますでしょうか。

「いいね!」 1

はい、この設定が有効になっていることを確認できます。

そして、Discourseのメールログ(可能であれば少し編集したもの)を送っていただけますか?

コンテナから抽出する必要がありますか、それともホストからですか?また、mail-receiverコンテナ経由でメールを処理しています。それとも、Web UIで公開されているログ(例:/admin/email-logs/rejected)をご希望ですか?

Exchangeから来ましたか?

Microsoft Exchangeは、設定が誤って…よくわかりませんが、別のExchangeサーバーと通信していると考えている場合、ゴミを送信することがあります。それ自身のインフラストラクチャ内の何か?

たとえば、Discourseコンソールで生のメールを確認できます。

mid = 'ログからのメッセージID'
puts IncomingEmail.find_by(message_id: mid).raw

これにより、Discourseが受信した生のメールが表示されます。たとえば、受信拒否リストから抽出したこのメッセージ本文は、実際にゴミです。

これはMIME形式のマルチパートメッセージです。
--=====003_Dragon855807841081_=====
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: base64

7bgir+m+vzzIDCLE0mDmZrfIXvvmXjY=

--=====003_Dragon855807841081_=====
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: base64

LP/0L4tqmfZizO0DCDDE10uOzMZqzSHDjq04SLPaBjibLVHz+V94m1M45NDN
55aM8SMIf9XY4EFjP9CCFz+ojfmJqmubaz+bjrzmubw+bjWTiGSuLg==

--=====003_Dragon855807841081_=====--

パートをデコードしても有効なテキストにならないためです。

「いいね!」 2

どちらでも結構です。PuTTy SSHを使用すると、コンテナログを抽出し、Discourse UIのスニペットを作成できます。ただし、写真を検索してそれらを削除するのは簡単ではありません😮‍💨

ヘッダー全体を含むメールを2通抽出できました。片方はApple Mail、もう片方はClaws Mailです。

デバッグのために、インターネット上に貼り付けるのを避けるため、誰かのプライベートメールに転送できれば幸いです。

どちらの場合も、Discourseがメールの内容を正しく解析していない可能性が高いと思います。

記録のために言っておくと、これはまだ問題です。Discourse は、原因を特定できない理由で、さまざまな送信者からのメーリングリストメッセージを Email::Receiver::InvalidPost エラーで定期的にドロップしています。

ログのエラーをクリックすると、バウンス理由にその理由が表示されますか?

例:

ログ内のエラーをクリックすると、バウンス理由が表示されますか?

これらのメッセージには2つの種類があります。

申し訳ありませんが、[tor-relays@lists.torproject.org](件名:[tor-relays] Re: abuse report from relays in family 7EAAC49A7840D33B62FA276429F3B03C92AA9327)へのメールメッセージは正常に送信されませんでした。

理由:

問題が発生しました。表示中にトピックが閉じられたか削除された可能性がありますか?

問題を修正できる場合は、もう一度お試しください。

これらのインスタンスでは、そのようなこと(トピックが閉じられたり削除されたり)は発生していないことを確認できます。

他の times、Reason は単に Access Denied です。

lavamindさん、こんにちは。古いスレッドを掘り起こしてしまい申し訳ありませんが、デバッグをさらに深める前に確認したくご連絡しました。

現在(2025年後半/2026年初頭)でも、メーリングリストのミラーリングで Email::Receiver::InvalidPost のリジェクトが発生しているか確認させていただけますでしょうか?

もしそうであれば、以下の点を簡単に共有していただけますか?

  • おおよその発生頻度(例:毎日/毎週、メッセージの何パーセントか)
  • リジェクトされたメールの「理由」が、引き続き主に「アクセス拒否」なのか、それとも「トピックがクローズ/削除された」なのか
  • 影響を受けているのが1つのリスト/カテゴリなのか、複数なのか

引き続き発生していることが確認でき次第、最近の単一の失敗に関する最小限の診断情報(メッセージID + 該当する保存済み生メールなど)の収集に進むことができます。

お気になさらないでください。調査していただき大変嬉しく思います。

Hi lavamind - sorry to bump an old thread, but I wanted to check in first before we go any deeper on debugging.

Are you still seeing the Email::Receiver::InvalidPost rejects on the mailing list mirroring as of now (late 2025 / early 2026)?
(現時点(2025年後半/2026年初頭)でもメーリングリストのミラーリングで Email::Receiver::InvalidPost のリジェクトが発生していますか?)

はい、問題はまだ発生しています。

roughly how often it happens (e.g. daily / weekly, % of messages)
(おおよそどのくらいの頻度で発生しますか(例:毎日/毎週、メッセージの何パーセント))

正確な頻度を特定するのは難しいですが、問題は少なくとも週に数通のメッセージに影響しており、大まかに言ってメッセージの5〜10%程度でしょうか?エラーログを見ると、一部の送信者が過剰に記録されているように見えるため、完全にランダムではないようです。

whether the rejected-email “Reason” is still mainly “Access Denied” vs “topic closed/deleted”
(リジェクトされたメールの「理由」が、引き続き「アクセス拒否」が主で、「トピックが閉じられた/削除された」は少ないですか)

依然として両方の混在です。

whether it’s affecting one list/category or multiple
(1つのリスト/カテゴリに影響していますか、それとも複数ですか)

主に tor-relays カテゴリに影響していますが、このリストは他のミラーリングしているリストとは異なり、複数の送信者から定期的に入力があります。他のリストはトラフィックがはるかに少ないです。

Once we confirm it’s still occurring, we can move on to collecting the minimum set of diagnostics for a single recent failure (Message-ID + the corresponding stored raw email, etc.).
(発生が続いていることを確認できたら、最近の単一の失敗に関する最小限の診断情報(Message-ID + 対応する保存された生メールなど)の収集に進むことができます。)

こちらの最近のスレッドを確認できます。Mailmanのアーカイブによると5通のメッセージを受信していますが、フォーラムのミラーリングされたトピックには3件の投稿しかありません。リジェクトログには、このトピックに対して3件の InvalidPost エラー(奇妙なことに、同じ送信者から2件)が記録されており、それらすべてについて表示されるリジェクト理由は「何か問題が発生しました。このトピックを見ている間に閉じられたか削除された可能性がありますか?」となっています。

lavamindさん、ありがとうございます。これは非常に役立つデータポイントです。「Mailmanアーカイブに5件、フォーラムトピックに3件ある」という具体的なスレッドを基準にできるのは特に助かります。

これが週に数回(大まかに見てメッセージの5〜10%)発生しており、今回のインシデントではバウンス理由が首尾一貫して誤解を招く「トピックがクローズ/削除されました」のバリアントであることから、次のステップとして、Discourseが何をしようとしていたのかを確認するために、1件の失敗したメッセージをエンドツーエンドでキャプチャすることが最善です。


そのミラーリングされたトピックに関連する拒否された3通のメールのうち、1通について、以下を取得していただけますか。

  1. /admin/email-logs/rejected から、そのインシデントに関する InvalidPost の行を1つ開き、以下をコピーしてください。

    • Message-ID
    • 日時
    • 行に表示されている (編集済みの) To / From / Subject
    • 表示されている完全なバウンス理由テキスト
  2. Railsコンソール(Discourseアプリコンテナ内)から、Discourseが保存した生のメールを抽出します。

@supermathie さん、IncomingEmail は生のデータを取得するための標準的な場所としてまだ正しいですか?また、InvalidPost のデバッグのために、他に何か一緒に欲しいものはありますか?

mid = "<ここに拒否されたメールログからMessage-IDを貼り付けます>"
ie  = IncomingEmail.find_by(message_id: mid)

puts ie&.raw
  1. 同じ Message-ID のペアになった EmailLog 属性も取得してください(これにより、Discourseがそれを返信として扱ったか、新しいトピックとして扱ったか、解決されたトピック/カテゴリIDが何であったかが判明することがよくあります)。
mid = "<上記と同じMessage-ID>"

log = EmailLog.where(message_id: mid).order(created_at: :desc).first
pp log&.attributes&.slice(
  "id",
  "email_type",
  "to_address",
  "from_address",
  "subject",
  "post_id",
  "topic_id",
  "user_id",
  "status",
  "bounce_error_code",
  "bounce_key",
  "created_at"
)

なぜこの3点セットなのか?

  • IncomingEmail.raw は、メールが不正な形式/奇妙なエンコーディング/フッターのみで到着したのか、それともDiscourseが「間違った」MIMEパートを選択したのかを教えてくれます。
  • EmailLog は、Discourseが何を試みたか(新しいトピックか返信か、解決されたトピック/カテゴリIDなど)を教えてくれます。
  • 拒否されたメールのUI行は、同じインシデントを見ていることを確認し、オペレーターが見るものを保持します。

プライバシーが懸念される場合は、アドレスや生のメッセージ本文テキストを編集していただいて構いませんが、以下は保持してください。

  • MIMEヘッダー (Content-Type, boundaries, charset, Content-Transfer-Encoding)
  • マルチパート構造(どのパートが存在するかを確認できるように)
  • Message-IDと基本的なルーティングヘッダー(必要であればドメインを編集しても構いません)

失敗したMessage-ID 1つ + IncomingEmail.raw + EmailLog のスライスが揃えば、これが次のいずれであるかを迅速に判断できるはずです。

  • 返信キー/トピックルーティングの不一致
  • 権限のエッジケース
  • または、メール解析/MIMEパート選択/デコーディングの失敗

非常に詳細なウォークスルーをありがとうございます!

メーリングリストのトピックに送信されたこのメッセージに焦点を当てましょう。

拒否された投稿ログのインシデントヘッダーには、次のように表示されています。

Message-ID: <20260103080033.5f6d8f90@dorfdsl.de>
Date: Sat, 03 Jan 2026 08:00:33 +0100
From: Marco Moock via tor-relays <tor-relays@lists.torproject.org>
To: tor-relays@lists.torproject.org
Subject: [tor-relays] Re: Questions about running an exit relay

完全な拒否理由テキストは次のとおりです。

We're sorry, but your email message to ["tor-relays@lists.torproject.org"] (titled [tor-relays] Re: Questions about running an exit relay) didn't work.

Reason:

Something has gone wrong. Perhaps this topic was closed or deleted while you were looking at it?

If you can correct the problem, please try again.

MailmanからDiscourseに送信されたメールのプレーンテキスト記録(IncomingEmail)はこちらで確認できます(公開されているデータ以外のものは含まれていないと思いますが、念のためそのリンクは最終的に期限切れになります)。

残念ながら、EmailLogを抽出する試みは結果を出すことができませんでした。Discourseにはそのメッセージに関するそのような記録がないようです。

@lavamind さん、ありがとうございます。これは素晴らしいです(Message-ID + リジェクトテキスト + Discourse が保存したもののコピー)。

また、EmailLog の件は私の勘違いでした。このような受信拒否の場合、EmailLog の行が存在しないのは非常にあり得ること(そしておそらく想定内)です。EmailLog は主に送信メール用であり、受信メールは IncomingEmail(すでに取得済み)に格納されます。@supermathie さん、これで皆を間違った方向に導いていないか確認してもらえますか?

IncomingEmail があるので、同じレコードからメタデータフィールドを貼り付けていただけますか?これにより、EmailLog から得たかった「Discourse が何をしようとしたか?」というコンテキストが得られるはずです。

Rails コンソールで:

# @supermathie さんへの確認:無効な投稿のデバッグのために、IncomingEmail のメタデータが収集すべき次の適切な情報ですか?
mid = "<20260103080033.5f6d8f90@dorfdsl.de>"
ie  = IncomingEmail.find_by(message_id: mid)

pp ie&.attributes&.slice(
  "id",
  "message_id",
  "from_address",
  "to_addresses",
  "cc_addresses",
  "subject",
  "created_at",
  "user_id",
  "post_id",
  "topic_id",
  "error"
)

# オプション:もしよろしければ、これもよく役立ちます
# (Discourse が本文として抽出したものと、生で保存したものを表示します)
# pp ie&.attributes&.slice("raw", "cooked")

rawcooked が非常に大きい場合は、省略していただいて構いません。すでに共有していただいています。)

これらのフィールドが重要な理由:

  • topic_id / post_id(存在する場合)は、Discourse がこれを返信として解決したか、新しい投稿として解決したか、そして何を対象としたかを示します。
  • user_id は、送信者をどのステージング済みユーザー/実ユーザーに Discourse がマッピングしたか(権限や「アクセス拒否」のケース)を示します。
  • error は、一般的な「トピックがクローズ/削除されました」というバウンステキストよりも具体的な情報であることがよくあります。

これらの属性で、トピック ID/投稿 ID の解決がミラーリングされているトピックを指している場合、次に取るべき手順は、受信側がそれを無効と判断した理由(本文が空、MIME デコード、権限の不一致、返信キーの不一致など)を突き止めることです。トピック/投稿の解決が全く示されていない場合は、ルーティングヘッダーや返信検出に焦点を当てます。

そして重ねてのお願いですが、ペーストリンクありがとうございます。このように具体的な失敗した Message-ID があることは、推測をやめるためにまさに必要としていたものです。

はい、その通りです。そして私も同意します。受信した内容、Discourse が関連付けられた内容、そして今後の手順が示されるはずです。

「いいね!」 1

IncomingObjectのメタデータフィールドは次のとおりです。

{"id"=>9785,
"message_id"=>"20260103080033.5f6d8f90@dorfdsl.de",
"from_address"=>"mm@dorfdsl.de",
"to_addresses"=>"tor-relays@lists.torproject.org",
"cc_addresses"=>"",
"subject"=>"[tor-relays] Re: Questions about running an exit relay",
"created_at"=>2026-01-03 07:03:04.639775000 UTC +00:00,
"user_id"=>10477,
"post_id"=>nil,
"topic_id"=>nil,
"error"=>"Email::Receiver::InvalidPost"}

生のコンテンツと調理済みのコンテンツについては、rawプロパティのみがヘッダーを含む完全なメールを含んでいます。cookedプロパティはこのオブジェクトには存在しません。

[quote=“lavamind, post:13, topic:377793”]MailmanからDiscourseに送信されたメールのプレーンテキストレコード(IncomingEmail)は、こちらで確認できます。
[/quote]

それをEmail::Receiver.new(rawmessage).select_bodyに通すと、以下が返されます。

=> ["", "", 2]

したがって、ここで起きているのは、Discourseが誤って空のプレーン/テキスト部分を選択してメッセージ本文にしていると確信しています。おそらくこの部分でしょう。

--Sig_/gizYC_1dGsAzUHvksdaMIe2
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit


これは無効な投稿になるはずです。

これについて少し調査し、おそらくテストケースとして使用する必要があります。

メールの構造は次のとおりです。

* #<Mail::Part:39500, Multipart: false, Headers: <MIME-Version: 1.0>, <Content-Type: text/plain; charset=us-ascii>, <Content-Transfer-Encoding: 7bit>, <Content-Disposition: inline>, <Content-ID: <6958bf289b75c_b28a46298091029@forum-01-app.mail>>>
  "___…tor-relays mailing list…"
* #<Mail::Part:39520, Multipart: true, Headers: <Content-Type: multipart/signed; boundary="Sig_/gizYC_1dGsAzUHvksdaMIe2"; micalg=pgp-sha256; protocol="application/pgp-signature">, <Content-Transfer-Encoding: 7bit>>>
  * #<Mail::Part:39540, Multipart: false, Headers: <Content-Type: text/plain; charset=US-ASCII>, <Content-Transfer-Encoding: quoted-printable>>>,
    "On 02.01.2026…"
  * #<Mail::Part:39560, Multipart: false, Headers: <Content-Type: text/plain; charset=UTF-8>, <Content-Transfer-Encoding: 7bit>>>,
    ""
  * #<Mail::Part:39580, Multipart: false, Headers: <Content-Type: text/plain; charset=US-ASCII>, <Content-Transfer-Encoding: quoted-printable>>>,
    "On 02.01.2026…"
  * #<Mail::Part:39600, Multipart: false, Headers: <Content-Type: text/plain; charset=UTF-8>, <Content-Transfer-Encoding: 7bit>>>,
    ""
  * #<Mail::Part:39620, Multipart: false, Headers: <Content-Type: text/plain; charset=US-ASCII>, <Content-Transfer-Encoding: quoted-printable>>>,
    "On 02.01.2026…"
  * #<Mail::Part:39640, Multipart: false, Headers: <Content-Type: text/plain; charset=UTF-8>, <Content-Transfer-Encoding: 7bit>>>,
    ""
  * #<Mail::Part:39660, Multipart: false, Headers: <Content-Type: text/plain; charset=US-ASCII>, <Content-Transfer-Encoding: quoted-printable>>>,
    "On 02.01.2026…"
  * #<Mail::Part:39680, Multipart: false, Headers: <Content-Type: application/pgp-signature>, <Content-Description: Digitale Signatur von OpenPGP>>>,
    PGP signature
  * #<Mail::Part:39700, Multipart: false, Headers: <Content-Type: application/pgp-signature>, <Content-Transfer-Encoding: 7bit>, <Content-Description: Digitale Signatur von OpenPGP>>>,
    PGP signature
  * #<Mail::Part:39720, Multipart: false, Headers: <Content-Type: application/pgp-signature>, <Content-Transfer-Encoding: 7bit>, <Content-Description: Digitale Signatur von OpenPGP>>>
    PGP signature

(はい、実際のコンテンツ、空のコンテンツ、PGP署名のコピーが3つあります)

最初の text/plain パーツはメーリングリスト ソフトウェアによって追加され、次のようになります。

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

そして、Discourse(実際には、.text_part を介した mail gem)がメッセージのコンテンツとして選択しているのは次のとおりです。

> puts mail.text_part.to_s
MIME-Version: 1.0
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-ID: <6958bf289b75c_b28a46298091029@forum-01-app.mail>

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

そして、署名が省略された空白の本文として扱われます。

このメーリングリストによって追加された、ほとんど空白のパーツがなければ、Discourse は投稿のために次のコンテンツを抽出したでしょう。

> We received a court order to preserve the data on the system and were
> forbidden from informing the system owner, which was awkward since
> they had informed the system owner...

どのデータを要求したのですか?

> Since then I've always run my exit on a separate system on it's own
> IP so if there were a legal demand to turn over "the system" it would
> really only be that system. I'm not a lawyer but I don't think docker
> provides enough isolation for that.

リレーを停止するように要求されることはありますか?
もしそうなら、別のIPで新しい「システム」を運用できます。

(以下の部分は省略されています)

On 02.01.2026 18:46 Jon via tor-relays <tor-relays@lists.torproject.org> wrote:

-- 
kind regards
Marco

Send spam to abfall1767375998@stinkedores.dorfdsl.de

この件に関して、Discourse のメール処理に欠点を見つけることはできません。もし私が責任を問うとすれば、おそらく最初に空白のコンテンツを追加したメーリングリスト ソフトウェアに責任があるでしょう。それは、実際のメッセージの、末尾に追加された方が適切でしょう。

それは Mail gem でも機能し、メールクライアントでも見栄えが良くなるでしょう。これが、受信したとおりの Thunderbird で表示されたものです。

そして、これが私の「修正済み」バージョンです(test-fixed.eml.txt (14.3 KB))。メーリングリストの署名が先頭ではなく末尾にあります。

(human)購読者に連絡したところ、フィルタリングされたいくつかのヘッダーを持つMUAでの生のメッセージ本文は次のとおりです。

Subject: [tor-relays] Re: Questions about running an exit relay
List-Id: "support and questions about running Tor relays (exit, non-exit,
 bridge)" <tor-relays@lists.torproject.org>
Archived-At: 
 <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/message/OAX7EO72GLXS4KPKUG7QSG7EOAR2WYVA/>
List-Archive: 
 <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/>
List-Help: <mailto:tor-relays-request@lists.torproject.org?subject=help>
List-Owner: <mailto:tor-relays-owner@lists.torproject.org>
List-Post: <mailto:tor-relays@lists.torproject.org>
List-Subscribe: <mailto:tor-relays-join@lists.torproject.org>
List-Unsubscribe: <mailto:tor-relays-leave@lists.torproject.org>
From: Marco Moock via tor-relays <tor-relays@lists.torproject.org>
Reply-To: Marco Moock <mm@dorfdsl.de>
Content-Type: multipart/mixed; boundary="===============8958541500975114832=="

--===============8958541500975114832==
Content-Type: multipart/signed; boundary="Sig_/gizYC_1dGsAzUHvksdaMIe2";
 protocol="application/pgp-signature"; micalg=pgp-sha256

--Sig_/gizYC_1dGsAzUHvksdaMIe2
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On 02.01.2026 18:46 Jon via tor-relays
 <tor-relays@lists.torproject.org> wrote:

 > We received a court order to preserve the data on the system and were
 > forbidden from informing the system owner, which was awkward since
 > they had informed the system owner...

Which data did they request?

 > Since then I've always run my exit on a separate system on it's own
 > IP so if there were a legal demand to turn over "the system" it would
 > really only be that system. I'm not a lawyer but I don't think docker
 > provides enough isolation for that.

Can they deny you to turn the relay off?
If so, you could then operate a new "system" on another IP.

--=20
kind regards
Marco

Send spam to abfall1767375998@stinkedores.dorfdsl.de

--Sig_/gizYC_1dGsAzUHvksdaMIe2
Content-Type: application/pgp-signature
Content-Description: Digitale Signatur von OpenPGP

-----BEGIN PGP SIGNATURE-----
iQJPBAEBCAA5FiEEpXefSZn9R6zNZtTQE76RLz2tRfAFAmlYvpEbFIAAAAAABAAO
bWFudTIsMi41KzEuMTEsMiwyAAoJEBO+kS89rUXw8kgP/2jkrwfSWHY6EY4WJjn6
EDEqT00pgpwEn9ZpUqLTreS3/ocfHC4g29HIsxpJcj/bH+hNAx96HEz9YmC4JfEt
LDjYc6D+5NBBFQGy0vaJ/LXLQc63CRE/yySSOYxFBZK+uMytNHoZDTjhfRroICbQ
guoO7A4/VuYrGAzCWQkBUmnBjj2LJhuLDW84ObMXhA/EuNy5FIAqyLZxoGmFEfvu
We5d0Hr3+wihzyrgGiG4u8UGFOyL+/PC11CFQyQ0j03cBzhZ5PVdtkqPNHauAcjQ
Gt/HQmaOSGKq0VODRjiHAe5TuRtV6jOfUNgS1Q2vB4FKYmeDQb82ooNfOiJWy3ey
Jpwgg700ppqgZUclpMPlzxKwi2dT/PSO6yYuy+G5sfa0Hxmn5DsQaiSPMTiEP2WC
NwAENYIuHeQOHWiS8B3oVSRW/naLzkmpfChFnTKGsrhLqKQc/iuvv639aHwg9BP7
YEbWbdpFpIU36czfxoTcDYDR1e4JLWryEFKIgo4TIaz4t17NmkxjXB6dHZKLLAdU
AT6LmL6mOTaXe9ewD9pf9Vf2nG0RGVJyZRUDmFzfU0Rx2qi7KdcmmRpZg/2QtJeA
Pmrv8NFuFEL0BrhTvo7C60m+gjLaXPNClgKEN0vkEzjLp/ZKjI9FslP61xUMg8lQ
3xT/HTkNt9uNH2ziBMXLK+5c
=0Euf
-----END PGP SIGNATURE-----

--Sig_/gizYC_1dGsAzUHvksdaMIe2--

--===============8958541500975114832==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

--===============8958541500975114832==--

重複はなく、パーツの順序も正しいです。これは、Mailmanが実際にメーリングリストの購読者に送信するものに最も近いと思われます。そうでなければ、ほとんどの人がフッターが上部にあるメッセージを受け取っているなら、私たちはそれを聞くはずではないでしょうか?

次に、処理パイプラインの他の何かがメッセージ本文をいじっているのではないかと疑問に思います。私たちのDiscourseサーバーは、Postfixを使用して受信メールを最初に処理し、それをmail-receiverコンテナに引き渡し、その後Discourseコンテナに引き渡します。

ああ!これを踏まえて、再度調査したところ…結局、私たちの問題であることがわかりました。

上記で投稿した生のメールから、IncomingEmail.rawが実際には生のメールを保存していないことを発見しました…私たちはそれをEmail::Cleanerで加工しています。

これはRubyのmail gemのせいだと思われます…メールメッセージを書き出す際にパーツを並べ替えるようです。

[1] pry(main)> m = File.open('test.eml').read;
[2] pry(main)> Mail.new(m).parts
=> [
  #<Mail::Part:39680, Multipart: true, Headers: <Content-Type: multipart/signed; boundary="Sig_/gizYC_1dGsAzUHvksdaMIe2"; protocol="application/pgp-signature"; micalg=pgp-sha256>>,
  #<Mail::Part:39700, Multipart: false, Headers: <MIME-Version: 1.0>, <Content-Type: text/plain; charset="us-ascii">, <Content-Transfer-Encoding: 7bit>, <Content-Disposition: inline>>
]
[3] pry(main)> Mail.new(Mail.new(m).to_s).parts
=> [
  #<Mail::Part:39720, Multipart: false, Headers: <MIME-Version: 1.0>, <Content-Type: text/plain; charset=us-ascii>, <Content-Transfer-Encoding: 7bit>, <Content-Disposition: inline>, <Content-ID: <6966b4914df79_31d5b1d38126@mars.mail>>>,
  #<Mail::Part:39740, Multipart: true, Headers: <Content-Type: multipart/signed; boundary="Sig_/gizYC_1dGsAzUHvksdaMIe2"; micalg=pgp-sha256; protocol="application/pgp-signature">, <Content-Transfer-Encoding: 7bit>>
]

これにより、次の問題が発生します。

[38] pry(main)> puts Email::Receiver.new(m).select_body[0];
=> We received a court order to preserve the data on the system and were
=> forbidden from informing the system owner, which was awkward since
=> they had informed the system owner...

Which data did they request?

=> Since then I've always run my exit on a separate system on it's own
=> IP so if there were a legal demand to turn over "the system" it would
=> really only be that system. I'm not a lawyer but I don't think docker
=> provides enough isolation for that.

Can they deny you to turn the relay off?
If so, you could then operate a new "system" on another IP.

[39] pry(main)> puts Email::Receiver.new(Mail.new(m).to_s).select_body[0];
«no output»
差分の詳細

test.eml: 提供された生のメッセージ
test-rubyparsed.eml: Rubyで解析されてから文字列に戻されたメッセージ
test-pythonparsed.eml: Pythonで解析されてから文字列に戻されたメッセージ

--- test.eml	2026-01-13 15:58:18.769489410 -0500
+++ test-rubyparsed.eml	2026-01-13 16:11:17.767312268 -0500
@@ -1,25 +1,46 @@
+Date: Tue, 13 Jan 2026 16:07:21 -0500
+From: Marco Moock via tor-relays <tor-relays@lists.torproject.org>
+Reply-To: Marco Moock <mm@dorfdsl.de>
+Message-ID: <6966b40914df7_31d5b1d38719@mars.mail>
 Subject: [tor-relays] Re: Questions about running an exit relay
+MIME-Version: 1.0
+Content-Type: multipart/mixed;
+ boundary="===============8958541500975114832=="
+Content-Transfer-Encoding: 7bit
 List-Id: "support and questions about running Tor relays (exit, non-exit,
   bridge)" <tor-relays.lists.torproject.org>
-Archived-At: 
- <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/message/OAX7EO72GLXS4KPKUG7QSG7EOAR2WYVA/>
-List-Archive: 
- <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/>
+Archived-At: <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/message/OAX7EO72GLXS4KPKUG7QSG7EOAR2WYVA/>
+List-Archive: <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/>
 List-Help: <mailto:tor-relays-request@lists.torproject.org?subject=help>
 List-Owner: <mailto:tor-relays-owner@lists.torproject.org>
 List-Post: <mailto:tor-relays@lists.torproject.org>
 List-Subscribe: <mailto:tor-relays-join@lists.torproject.org>
 List-Unsubscribe: <mailto:tor-relays-leave@lists.torproject.org>
-From: Marco Moock via tor-relays <tor-relays@lists.torproject.org>
-Reply-To: Marco Moock <mm@dorfdsl.de>
-Content-Type: multipart/mixed; boundary="===============8958541500975114832=="
+
+
+--===============8958541500975114832==
+MIME-Version: 1.0
+Content-Type: text/plain;
+ charset=us-ascii
+Content-Transfer-Encoding: 7bit
+Content-Disposition: inline
+Content-ID: <6966b40914ae9_31d5b1d38641@mars.mail>
+
+_______________________________________________
+tor-relays mailing list -- tor-relays@lists.torproject.org
+To unsubscribe send an email to tor-relays-leave@lists.torproject.org
  
 --===============8958541500975114832==
-Content-Type: multipart/signed; boundary="Sig_/gizYC_1dGsAzUHvksdaMIe2";
- protocol="application/pgp-signature"; micalg=pgp-sha256
+Content-Type: multipart/signed;
+ boundary="Sig_/gizYC_1dGsAzUHvksdaMIe2";
+ micalg=pgp-sha256;
+ protocol="application/pgp-signature"
+Content-Transfer-Encoding: 7bit
  
 --Sig_/gizYC_1dGsAzUHvksdaMIe2
-Content-Type: text/plain; charset=US-ASCII
+Content-Type: text/plain;
+ charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
  
 On 02.01.2026 18:46 Jon via tor-relays
@@ -39,7 +60,8 @@
 Can they deny you to turn the relay off?
 If so, you could then operate a new "system" on another IP.
 
---=20
+-- =
+
 kind regards
 Marco
  
@@ -47,14 +69,16 @@
  
 --Sig_/gizYC_1dGsAzUHvksdaMIe2
 Content-Type: application/pgp-signature
+Content-Transfer-Encoding: 7bit
 Content-Description: Digitale Signatur von OpenPGP
  
 -----BEGIN PGP SIGNATURE-----
@@ -69,14 +93,5 @@
 
 --Sig_/gizYC_1dGsAzUHvksdaMIe2--
 
---===============8958541500975114832==
-Content-Type: text/plain; charset="us-ascii"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Content-Disposition: inline
-
-_______________________________________________
-tor-relays mailing list -- tor-relays@lists.torproject.org
-To unsubscribe send an email to tor-relays-leave@lists.torproject.org
-
+--===============8958541500975114832==
+
--- test.eml	2026-01-13 15:58:18.769489410 -0500
+++ test-pythonparsed.eml	2026-01-13 16:19:30.385608544 -0500
@@ -1,10 +1,8 @@
 Subject: [tor-relays] Re: Questions about running an exit relay
 List-Id: "support and questions about running Tor relays (exit, non-exit,
  bridge)" <tor-relays.lists.torproject.org>
-Archived-At: 
- <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/message/OAX7EO72GLXS4KPKUG7QSG7EOAR2WYVA/>
-List-Archive: 
- <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/>
+Archived-At: <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/message/OAX7EO72GLXS4KPKUG7QSG7EOAR2WYVA/>
+List-Archive: <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/>
 List-Help: <mailto:tor-relays-request@lists.torproject.org?subject=help>
 List-Owner: <mailto:tor-relays-owner@lists.torproject.org>
 List-Post: <mailto:tor-relays@lists.torproject.org>
「いいね!」 3