Gmailユーザーがタグでフィルタリングできるように、メール通知用のヘッダーは？

貢献 特徴
,
1

投稿が重複としてクローズされました Email: mail headers should have tags in them、おそらく Customs email headers and/or subjects tags を参照していると思われますが、後者はやや一般的であり、特定の問題について議論したいと考えています。

タグを、さまざまなプロジェクトのサブトピックに関する多数のメーリングリストの最も論理的な代替として使用しています。カテゴリの使用を開始しましたが、それは扱いにくくなりました。カテゴリは重く、簡単なクロス投稿を許可せず、その他の多くの理由から、タグの方が適していると考えています。[1]

しかし、問題があります。メール通知のテンプレートに %{optional_tags} を配置することは可能ですが、Gmail の非常に限定的なフィルタリングではこれはスマートに機能しません。さらに、古いメールユーザーにとっても、件名を解析して解析する procmail ルールを作成するのは少し面倒です。

そのため、タグを別の場所に配置できると便利です。procmail ユーザーにとっては、カスタム X-Tags ヘッダーで十分ですが、Gmail は気にしないので、別のものが必要です。

1 つのアイデアは、タグを List-ID として実際に使用することですが、Gmail が複数の List-ID タグを正しく処理するかどうかはわかりません 複数の List-ID フィールドは許可されていません [2]。別のアイデアは、少し厄介ですが機能すると思います。tag@subdomain.example.org (およびおそらく tag2@subdomain.example.org、tag3@subdomain.example.org など) を CC リストに配置することです。Google はこれをフィルタリングできます。また、ほとんどの他のシステムも CC を複数値フィールドとして処理するための合理的に高度な機能を持っています。そして、これらのアドレスに実際に送信されたメールはすべて破棄します[3]。

ボーナスとして、CC アプローチは受信メールにタグを追加する方法としても使用できます (Add tags by email を参照)。これも少し厄介ですが、2022 年のメールはすべて厄介です。

  1. これについて議論したい場合は、別のスレッドトピックでできます！ ↩︎

  2. くそー、RFCE 2919! ↩︎

  3. つまり /dev/null ↩︎

「いいね！」 2
2

他に何か提案やアイデアがあれば、ぜひ教えてください。これがなければ、Discourseへの大規模な移行を合理的に提案することはできません。

3

また、ここには#タグがないのはなぜですか？ :slight_smile:

4

動作するかもしれませんが、カスタムプラグインが必要になります。

5

具体的には、どのようなユースケースなのですか？

なぜ、サイトからのメール通知をフィルタリングするのに役立つ必要があると感じているのか、知りたいです。Discourseの意図された使用法は、コミュニティメンバーが関心のあるアクティビティがあった場合に通知を受け取るためにメール通知を使用し、議論に参加したいときにリンクをクリックしてログインすることです。サイトによっては、メールでの返信を有効にすることもできます。しかし、メンバーは議論を続けるためにサイトにログインする習慣を身につける必要があります。

そうすれば、誰もがサイトでの議論の整理と管理という共同作業の恩恵を受け、貢献することができます。そして、時代遅れの議論の多くが、みんなのメールフォルダにサイロ化されることを避けることができます。Discourseが意図されたとおりに使用されれば、メールで受信した通知は削除するだけで済みます。

また、メールはDiscourseに限らず、正しく機能させることが非常に困難です。コミュニティメンバーがサイトにログインして積極的に参加するようになればなるほど、コミュニティはより成功し（管理しやすく）なります。

もしかしたら、Discourseはあなたのコミュニティに適していないのかもしれません。あるいは、Discourseサイトを構築する間、いくつかのメーリングリストを運用し続ける必要があるのかもしれません。長年のコミュニティの習慣を変えるのは難しいことだと分かっています。

幸運を祈ります！:sunflower:

「いいね！」 2
6

それが正しいかもしれません。

まだ procmail の方々、Gmail の方々、Discourse の方々がいらっしゃるのですか？これら3つのグループすべてを満足させるのは非常に困難でしょう。

もし予算が2000〜5000ドルであれば、ご要望の機能を実現するカスタムプラグインを入手できるかもしれませんが、誰にとっても満足のいくものになるとは想像しにくいです。現在わかっている問題を解決しても、他にどのような問題が発生するかはわかりません。私が思い出すのは、多くの人が RFC-822 に準拠しないLANベースのメールゲートウェイを使用していた頃のメーリングリスト管理です（その頃は procmail と Emacs の rmail を使用していました）。問題は単に解決不可能です。

カテゴリを使用することをお勧めします。あるいは、本当に20年前の慣習に従ったメーリングリストが必要なのであれば、機能しているものに留まるのが良いでしょう。

「いいね！」 2
7

これらの機能が、従来のメーリングリストモデルを基盤とする他のプラットフォームに既に存在する場合、より未来志向の製品に後付けするように要求するよりも、そこで成功する可能性が高いでしょう。

言い換えれば、これが決定的な要因である場合、なぜそもそもDiscourseを検討するのですか？ HyperKittyを拡張して必要な機能を追加することはできませんか？

「いいね！」 1
8

目標

現在、Fedora には数百ものメーリングリストがあり、そのうち約 90 が何らかのアクティビティがあり、ごく少数が非常に活発です。私はそれらをすべて一元化したいと考えています。これには貢献者コミュニティを成功裏に引き込むことも含まれます。これより優れた Discourse の代替案があれば、まだ誰も作成していません。

短縮版

私はこれを 3 年間積極的に取り組んでおり、少なくとも 10 年間は考えてきました。コミュニティの人々に、彼らを妨げていることについて話す中で、この特定のことが繰り返し話題に上りました。

長文版：

Discourse が開始された[^1]のとほぼ同時期に、私たちは Hyperkitty という Mailman3 の GUI フロントエンドを作成しました。これは、人々が基盤となるメーリングリストにアクセスするために使用できる最新の Web UI を意図したものでした。これは、Fedora Devel List で実際に動作しているのを見ることができます。

Hyperkitty にはいくつかの優れたアイデアがありますが、成功に必要な規模の資金が提供されず、初期設計のままリリースされ、実際の使用での改善や修正の provision がありませんでした。また、電子メールを基盤としており、それが物事を非常に制限していました[^2]。リソースがあったとしても、それを最大公約数[^3]に保つことは、フラストレーションの限界となるでしょう。

ですから、あなたの状況は理解できます。Wayback Machine で discourse.org の履歴 をたどると、Discourse がフォーラムとメーリングリストの両方から学んだ教訓を活かし、それらを置き換えることに重点を置いていたことがわかります[^4]。

2013

…そしてそれは今日までほとんど生き残っていますが[^8]、さまざまなページでメーリングリストに関する他の話題は少なくなっています。もし Hyperkitty にリソースを投資していたら、私たちも経験したであろうのと同じことを、あなたは経験しました。つまり、電子メールを低すぎる最大公約数基盤とする問題であり、論理的な結論に至りました。ウェブサイトに人々を誘導することが正しい使い方であると今、明確に述べているあなたの考えは、完全に理解できます。

現在：

  • 数十のアクティブなメーリングリストがあります
    • 数百のアクティブな参加者
    • 数千のパッシブな購読者
  • これらのリストは文字通り 20 年以上続いています。
  • 多くの昔ながらのオープンソースの人は、この働き方に本当に愛着を持っています。
    • 慣れている
    • すでに設定されている
    • 「ウェブサイトをチェックする」という必要なく、日々のルーチンに届く
  • 多くの人がプロジェクトのさまざまな部分でアクティブですが、その「フットプリント」は非常に個別的です。

しかし：

I. これらのリストは、多くの人が考えているほど機能的ではありません：

  • モデレーションは不可能に近い（せいぜいすべてか無かの大きな棒）
    • 努力にもかかわらず、人々は常に期待される基準を守っているわけではありません
    • メガ スレッドは良い議論ではありません
    • リスト外のハラスメントは簡単に開始でき、制御できません
    • 購読が一致しないため、クロス投稿は混乱します
    • コミットしていない限り、追いつくのは不可能です
    • 参加すべき人が、上記のさまざまな理由で参加しません

II. 電子メールは未来ではありません

  • メーリングリストは検索エンジンからはほとんど見えず、世界のほとんどの人には「実際の活動」のように見えません。
  • 新しい人はメーリングリストにサインアップしたくありません[^5]。
  • メーリングリストの「文化」は、もはや本当に存在しません[^6]。
    • そして Gmail のウェブインターフェースは、インライン返信のような従来の慣習に対して積極的に敵対的です。

III. 電子メール全体が破滅に向かっています

  • 大手プロバイダーは、スパムを自分で「解決」するための規模を持っており、グローバルに解決するためのインセンティブがなくなりました。
  • 小規模プロバイダーが確実に配信できる可能性は低下しています。
  • メーリングリストは本質的に再公開され、サインアップと検証のインフラストラクチャは実際には気にかけていません。
  • 企業は、機能的なコミュニケーションのために Slack などに移行しており、電子メールは発表とブロードキャスト用になっています。
    • そして、ワークフロー中心のやり取りには Jira や github などを使用しています。
  • 繰り返しになりますが、「普通の」人々は、顧客である企業からの通知を受け取る以外の目的では使用していません。もはや個人的なコミュニケーションのためのものではありません。

しかし、まだニーズはあります

リアルタイムの会話はカバーされていますが[^7]、メーリングリストが提供してきた長文の非同期会話はまだ必要です。チャットはすべてをカバーするわけではなく、グローバルなボランティアやさまざまなコミットメントを持つ人々とはうまく機能しません。ワークフローツールは狭すぎます。

Discourse は本当に最良の選択肢です

  • メーリングリストは実行可能な未来ではありません。

  • Hyperkitty は 2014 年に立ち往生しています。

  • Github / Gitlab を使用するには、あまりにも多くのものがあります。

  • その他の可能性はうまくいきません：

    • Ponymail は、電子メールを GCF とする同じ問題に苦しんでいます。
    • Vanilla はあまり良くありません。そこに置いておきます。 :slight_smile:
    • Google Groups は最悪です。

  • Discourse のプラス面：他の多くのオープンソースコミュニティが Discoruse を中心に統合されています。特に：Python、GNOME…

カサンドラが登場

データベースではありません。つまり、終末を告げても誰も信じないということです。私は「メールはうまく機能する」、「メーリングリストに問題はない」、「そもそもフォーラムは嫌いだ」、あるいは具体的に「Discourse は好きではない」という意見をたくさん聞きます。

しかし、私たちは本当に変化が必要です。

だから…

私は、大規模で活発で重要なオープンソースコミュニティに、プライマリプロジェクトのコミュニケーションプラットフォームを Discourse に移行させる必要があります。多くの人々が懐疑的です。これは大きな変化です。それを可能な限り容易にしたいと考えています。懐疑的だが試す意思のある人々にとって、それをより簡単でより快適にするため、そして電子メールでのやり取り（フィルタリングを含む）を個人的なブロックとしている人々にとって、試すことを可能にするためです。

私は、一度そこにたどり着けば、多くの人々が行動を変えるだろうと考えています。直接サイトとやり取りすることがそれほど悪くないと発見する人が増えるでしょう[^8]。そして、私たちは独自の プロジェクト全体の通知システム を統合する計画があり、最終的には人々が本当に必要としているものをより多く提供できるようになることを願っています。

しかし、それまでの間、私は人々に彼らが求めているものを与える必要があります。

[^1] 当時、独自のものをロールアウトするのではなく、代替アプローチとして Discourse を提案しようとしました。タイムマシンがあれば、戻ってさらに強く推進したかもしれません。しかし、その時点では私は現在の役割に就いておらず、サイコロはすでに振られていました…
[^2] LUGNET からの同様の教訓だと思います。90 年代の最も驚くべき、そして最も賢明なフォーラムソフトウェアだと思いますが、バックエンドとして NNTP に結び付けられていました。
[^3] 慣用句は「最小公約数」であることを知っていますが、それは意味がありません。「もっと気にする」のようなものですが、今では数学も含まれています。
[^4] つまり、すでに覚えていないのであれば、もちろん！
[^5] 韓国では、メールは年配者のためのもの です。私たち全員にやってきました！
[^6] 「ネットエチケット」という言葉を最後に聞いたのはいつだったか思い出せません。
[^7] Matrix を使用しており、https://chat.fedoraproject.org/ で…
[^8] ただし、間違いなく この人 がいるので、全員ではありません。

「いいね！」 5
10

素晴らしい記事ですね！:ok_hand:

メールで利用しているという、お話しされているフィルタリングについて、もう少し詳しく説明していただけますか？私も長年メーリングリストに関わってきましたが、ヘッダーを使った自動フィルタリングには遭遇したことがありません。リストに購読者がいて、それをメールのフォルダにフィルタリングしたい場合、購読者自身がリストごとに設定するものだと思います。Discourseでもそれは可能ですよね？

メーリングリストの代わりとしてカテゴリがうまく機能すると思います。ユーザーがメーリングリストモードを有効にするか、特定のカテゴリをウォッチすることで、すべての投稿のメールを受け取ることができます。また、カテゴリで既に機能しているものと同等の機能を持たせるために、ディスカッションをタグに整理する方がなぜ良いのか、そしてその労力に見合うのかについて、もう少し学ぶ必要があると思います。

編集：この件について、2014年の古い投稿を思い出しました！:scream:

「いいね！」 1
11

はい。現在Discourseが設定しているヘッダーは、実際のこのスレッドからの通知では以下のようになります。

List-Unsubscribe: <https://meta.discourse.org/email/unsubscribe/efed8ca1777379c660afc031464b98eb4e6fa2323a71fa12fa2269eeca5b0905>
X-Discourse-Post-Id: 1216779
X-Discourse-Topic-Id: 249982
X-Auto-Response-Suppress: All
Auto-Submitted: auto-generated
Precedence: list
List-ID: Discourse Meta | feature <feature.meta.discourse.org>
List-Archive: https://meta.discourse.org/t/headers-for-email-notifications-so-that-gmail-users-can-filter-on-tags/249982
Feedback-ID: meta:user_replied:discoursemail

Gmailがなければ、以下のようなものを追加できます。

X-Discourse-Tags: some-tag, another-tag

Customs email headers and/or subjects tags - #6 by mattdm を参照してください。もし email custom headers 設定がテンプレート展開で渡され、 X-Discourse-Tags: %{optional_tags} が機能すれば、この部分はすでに機能します。

そして、procmailやその他の旧式のメールクライアントユーザーにとっては、これで十分でしょう。残念ながら、Googleの不可解な理由により、Gmailは任意のタグでフィルタリングできず、私の知る限り To: 、 From: 、 Cc: 、そして幸いなことに List-ID に限定されています。それが800ポンドゴリラなので、それらのユーザーに対応するために、カテゴリではなくタグで List-ID を設定する（または、組み合わせる？）のが、私が考えられる最善の方法です。

しかし、RFC 2919 によると、1つのメッセージにつき List-ID は1つしか許可されていません。そのため、残るのは以下の選択肢です。

  1. 任意のタグを1つ選択[1]
  2. すべてのタグを含むもの（例：List-ID: firsttag_secondtag.discourse.example.org）を生成し、ユーザーに解釈させる。[2]
  3. 通知ごとに、タグごとに複数のメールを生成し、このヘッダーのみを変更する[3]
  4. カテゴリを参照するように List-ID を残し、代わりにCCのアイデアを使用する…[4]

どれもあまり気に入っていません。そのため、最初の試みとして、X-Discourse-Tags: は少なくともGmail以外のユーザーをカバーできます。（これはおそらく、Webに依存しないユーザーとかなり良い重複があるので、どこまで進むかを見る価値があると思います。）

  1. 紛らわしい！ ↩︎

  2. あまり良くない ↩︎

  3. これもあまり良くない ↩︎

  4. かなり不格好。単に Cc: %{optional_tags} を追加するだけでは（その設定のテンプレート展開が実装されていると仮定しても）、各タグが実際の（ブラックホールの）メールアドレスに対応するように展開されないため、機能しません。 ↩︎

「いいね！」 3
12

はい、その通りです！最後の段落がすべてをうまくまとめています！

「いいね！」 2
13

X-Discourse-Tags と X-Discourse-Category（同等の機能として）の追加を強く支持します。

長期的には、Gmail向けにユーザーオプションを追加できると思います。

  • このトピックが属するすべてのタグをメールのトピックタイトルに追加してください。

例：

[Discourse Meta] [feature] [email] [notifications] メール通知のヘッダー

または、有効にした場合：

[Discourse Meta] メール通知のヘッダー … [feature] [email] [notifications]

「いいね！」 5
14

はい、それはユーザーオプションとして興味深いでしょう。現在、サイト全体でこれを使用しています。

%{optional_re}%{topic_title} [Fedora] %{optional_pm}%{optional_tags}

タグを最後以外に配置するのは迷惑だという「強い」フィードバックがありました。また、Googleは件名の部分一致で効果的にフィルタリングするほど賢くないというフィードバックもありました。

Googleをどれだけ「修正」できるかわかりません（むしろ、ほとんどできないと確信しています）。そのため、「まあ、仕方ない」という程度のことは、人々を受け入れるように説得する必要があるかもしれません。

「いいね！」 4
15

状況を改善するために、いくつか簡単なことができます。

現時点では、

  1. 3つに制限している（任意の順序）
  2. タグを [ ] で囲んでいない

私は迷っていますが、任意の3つの制限はあまり良くないと思います。単に削除すべきです。

さらに、tags.map{|t| "[#{t}]"}.join(" ") の方が良いでしょう。なぜなら、フィルターは [tagname] に対して行うことができ、tagname よりも PM のタイトルに表示される可能性がはるかに高いためです。

@martin さん、どう思いますか？

「いいね！」 5
16

歴史を知ると、より理にかなっています。それを実現するための予算と、開始に向けて良い一歩を踏み出すためのいくつかの良いアイデアがあるようですね。難しいと思いますが、すべてのデータをインポートするのは大変でしょう。すべての人を満足させるのは依然として難しいでしょうし、サムはあなたのアイデアの少なくともいくつかには賛成しているので、それらはプラグインの場合に起こりそうなこととは異なり、将来壊れないようにコアに組み込まれるでしょう。

「いいね！」 3
17

ここには同意しますが、制限を完全に削除するのではなく、max_tags_per_topic 設定を活用できるのではないでしょうか？ それの方が安全だと思います。

残念ながら、タグの周りに [] を追加しても、Gmail の検索にはあまり役立ちません。見た目だけです。私が見る限り（例：https://webapps.stackexchange.com/questions/52828/create-gmail-filter-that-contains-a-special-character を参照してください。リンクされているドキュメントはもはや存在しませんが、有効です）、Gmail は件名などで検索する際に特殊文字を削除します。Gmail で subject:(\"[support]\") を検索してみてください。角括弧が付いているものだけでなく、件名に support が含まれるすべてのものが表示されます。これは Google が行うには少し無意味なことですが、検索会社（まあ、検索と広告ですが）である彼らには、私たちにできることは何もありません。

また、MessageBuilder で X-Discourse-Tags と X-Discourse-Category を同時に簡単に追加できるはずです。すでに現時点ではそれらのオプションがありますし、@mattdm が言うように、これはウェブに抵抗のあるユーザーをうまくカバーします。

もしよろしければ、私がこれを担当しましょうか？

「いいね！」 5
21

これをマージしました @mattdm :

Gmail の問題が大幅に解決するわけではありませんが、少なくともターミナルベースのメールユーザーがこれらのメールをより簡単にフィルタリングできるようになるはずです。

「いいね！」 6
22

Note @mattdm、本当に頑張りましたが、Gmailは非常に扱いにくいです。トークン化する際にテキストから多くのものを削除してしまうため、あなたの手は非常に縛られます。

唯一考えられる回避策は、メールのタグ名を非常に醜くすることです：

「これはデモ件名です。[Temail, Tnotifications]」（Gmailが「好む」Tまたはその他のアルファベットシーケンスを接頭辞として付ける）

しかし、これはかなり醜く、直感的でない解決策です。

「いいね！」 3
23

サムさん（そして皆さん！）ありがとうございます。

皆さんの尽力に感謝します。結局、Googleの不可解な選択に対して私たちができることには限りがあります。

ええ、本当に。さらにできると思うのは、ユーザーごとのオプションを追加することくらいです。

メール通知の件名に、Gmailがフィルタリングできるような非常に醜い形式でタグ名を含める。

：-/

「いいね！」 5