Header für E-Mail-Benachrichtigungen, damit Gmail-Benutzer nach Tags filtern können?

Beitragen Merkmal
,
1

Der Beitrag wurde als Duplikat geschlossen E-Mail: E-Mail-Header sollten Tags enthalten, möglicherweise in Bezug auf Customs email headers and/or subjects tags, aber letzteres ist eher allgemein, und ich möchte ein spezifisches Problem besprechen, das wir haben:

Wir verwenden Tags als die logischste Ersetzung für Dutzende von Mailinglisten zu verschiedenen Unterthemen von Projekten. Wir haben angefangen, Kategorien zu verwenden, aber das wurde unübersichtlich – Kategorien sind schwerfällig, erlauben kein einfaches Cross-Posting und aus einer ganzen Reihe anderer Gründe denken wir, dass Tags besser passen.[1]

Allerdings… gibt es ein Problem. Obwohl es möglich ist, %{optional_tags} in die Vorlage für E-Mail-Benachrichtigungen einzufügen, macht Gmails sehr begrenzte Filterung damit nichts Schlaues – und selbst für den alten E-Mail-Benutzer ist es eine ziemliche Plage, eine procmail-Regel zu schreiben, die die Betreffzeile zerlegt und parst.

Daher wäre es schön, den Tag woanders zu haben. Für die procmail-Leute würde ein benutzerdefinierter X-Tags-Header ausreichen, aber Gmail kümmert sich nicht darum, also brauchen wir etwas anderes.

Eine Idee wäre, Tags tatsächlich als List-ID zu verwenden, aber ich bin mir nicht sicher, ob Gmail mit mehreren List-ID-Tags das Richtige tut mehrere List-ID-Felder sind nicht erlaubt [2]. Eine andere Idee, die etwas umständlich ist, aber meiner Meinung nach funktionieren würde: tag@subdomain.example.org (und möglicherweise auch tag2@subdomain.example.org, tag3@subdomain.example.org, …) in die CC-Liste aufnehmen. Google kann danach filtern, und die meisten anderen Systeme haben auch einigermaßen fortschrittliche Funktionen für den Umgang mit CC als Mehrwertfeld. Und wir würden alle E-Mails, die tatsächlich an diese Adressen gesendet werden, ins Nichts umleiten[3].

Als Bonus könnte der CC-Ansatz verwendet werden, um Tags bei eingehenden E-Mails hinzuzufügen (siehe Add tags by email). Wiederum etwas umständlich, aber dann ist alles E-Mail im Jahr 2022.

  1. Wenn Sie dies besprechen möchten, kann ich… in einem anderen Thread Thema tun! ↩︎

  2. verflucht seist du, RFCE 2919! ↩︎

  3. d. h. /dev/null ↩︎

2 „Gefällt mir“
2

Ich bin offen für alle anderen Vorschläge oder Ideen, die jemand hat. Wir können nicht vernünftigerweise eine groß angelegte Umstellung auf Discourse vorschlagen, ohne dies.

3

Außerdem, warum gibt es hier keine tags? :slight_smile:

4

Es klingt, als ob sie funktionieren könnten, aber Sie benötigen ein benutzerdefiniertes Plugin.

5

Was genau ist Ihr Anwendungsfall?

Ich würde gerne erfahren, warum Sie der Meinung sind, dass Sie den Leuten helfen müssen, E-Mail-Benachrichtigungen von Ihrer Website zu filtern. Die vorgesehene Nutzung von Discourse ist, dass Community-Mitglieder E-Mail-Benachrichtigungen einfach nutzen, um darüber informiert zu werden, wenn Aktivitäten stattfinden, die sie interessieren, und auf den Link klicken, um sich anzumelden, wenn sie an Diskussionen teilnehmen möchten. Für Websites, die dies wünschen, kann die Antwort per E-Mail aktiviert werden. Aber das Mitglied sollte immer noch die Gewohnheit haben, sich anzumelden, um die Diskussion auf der Website fortzusetzen.

Auf diese Weise profitieren alle von der gemeinschaftlichen Anstrengung, Diskussionen auf der Website zu organisieren und zu verwalten, und können dazu beitragen. Und Sie vermeiden, dass eine Menge veraltete Diskussionen in den E-Mail-Ordnern aller Mitglieder isoliert werden. Wenn Discourse wie vorgesehen verwendet wird, können die per E-Mail empfangenen Benachrichtigungen einfach gelöscht werden.

E-Mail ist auch notorisch schwer richtig hinzubekommen, und das nicht nur für Discourse. Je mehr Sie Ihre Community dazu bringen, sich auf Ihrer Website anzumelden und zu engagieren, desto erfolgreicher (und einfacher zu verwalten) wird Ihre Community sein.

Vielleicht ist Discourse nicht die richtige Wahl für Ihre Community, oder Sie müssen ein paar Mailinglisten weiter betreiben, während Sie Ihre Discourse-Website aufbauen? Ich weiß, dass es schwierig sein kann, die Gewohnheiten langjähriger Communities zu ändern.

Viel Glück! :sunflower:

2 „Gefällt mir“
6

Ich denke, das könnte richtig sein.

Gibt es bei Ihnen noch procmail-Leute? Und Gmail-Leute und Discourse-Leute? Es wird sehr schwierig sein, all diese drei Gruppen zufriedenzustellen.

Wenn Sie ein Budget von 2000 bis 5000 US-Dollar haben, können Sie vielleicht ein benutzerdefiniertes Plugin erhalten, das das tut, was Sie verlangen, aber es ist schwer vorstellbar, dass es für irgendjemanden zufriedenstellend sein wird. Sie wissen nicht, welche anderen Probleme auftreten werden, sobald Sie die Probleme gelöst haben, die Sie jetzt kennen. Ich erinnere mich an die Verwaltung von Mailinglisten, als eine ganze Reihe von Leuten LAN-basierte E-Mail-Gateways benutzten, die RFC-822 nicht befolgten (das war, als ich procmail und Emacs rmail benutzte). Das Problem ist einfach untragbar.

Ich würde empfehlen, einfach bei Kategorien zu bleiben. Oder, wenn Sie wirklich Mailinglisten haben möchten, die den Konventionen von vor ein paar Jahrzehnten folgen, bleiben Sie einfach bei dem, was funktioniert.

2 „Gefällt mir“
7

Wenn diese Funktionen bereits auf anderen Plattformen vorhanden sind, die auf dem traditionellen Mailinglistenmodell basieren, werden Sie dort wahrscheinlich mehr Erfolg haben, anstatt zu verlangen, dass sie auf ein zukunftsorientierteres Produkt aufgesetzt werden.

Oder anders ausgedrückt: Wenn dies ein Dealbreaker ist, warum sollten Sie dann überhaupt Discourse in Betracht ziehen? Könnte HyperKitty erweitert werden, um die von Ihnen benötigte Funktionalität hinzuzufügen?

1 „Gefällt mir“
8

Ziel

Derzeit hat Fedora Hunderte von Mailinglisten, von denen etwa 90 einen gewissen Aktivitätsgrad aufweisen und eine Handvoll sehr aktiv sind. Ich möchte das alles an einem Ort konsolidieren, was die erfolgreiche Einbindung unserer Beitragsgemeinschaft einschließt. Wenn es eine bessere Option als Discourse dafür gibt, hat sie noch niemand geschaffen.

Kurzfassung

Ich arbeite seit drei Jahren aktiv daran und denke seit mindestens zehn Jahren darüber nach. Wenn ich mit Leuten in meiner Community darüber spreche, was sie blockiert, ist diese spezielle Sache immer wieder aufgetaucht.

Langfassung:

Ungefähr zur gleichen Zeit, als Discourse gestartet wurde[1], haben wir ein Mailman3 GUI-Frontend namens Hyperkitty erstellt, das als moderne Weboberfläche gedacht war, über die Leute auf die zugrunde liegenden Mailinglisten zugreifen konnten. Sie können dies für die Fedora Devel List in Aktion sehen.

Hyperkitty hat einige nette Ideen, wurde aber nicht im notwendigen Umfang finanziert, um erfolgreich zu sein, und wurde mit dem ursprünglichen Design gestartet, ohne Vorkehrungen für Verbesserungen und Korrekturen im realen Einsatz zu treffen. Und es nimmt E-Mail als zugrunde liegende Basis, was die Dinge wirklich eingeschränkt hat[2] – selbst wenn wir die Ressourcen gehabt hätten, wäre die Beibehaltung als größter gemeinsamer Nenner[3] eine frustrierende Grenze gewesen.

Daher verstehe ich, wo Sie stehen. Wenn Sie mit der Wayback Machine eine Reise durch die Geschichte von discourse.org unternehmen, können Sie sehen[4], dass Discourse ziemlich stark darauf setzte, aus Foren und Mailinglisten zu lernen und beides zu ersetzen…

2013

… und das hat sich bis heute größtenteils gehaltendurch heute, obwohl auf den verschiedenen Seiten weniger anderer über Mailinglisten gesprochen wird. Sie haben das Gleiche durchgemacht, was wir durchgemacht hätten, wenn wir die Ressourcen gehabt hätten, um in Hyperkitty zu investieren – das Problem mit E-Mail als zu niedriger Basis – und sind zu der logischen Schlussfolgerung gekommen. Ich verstehe vollkommen, woher Sie kommen, wenn Sie jetzt ausdrücklich sagen, dass es die richtige Nutzung ist, die Leute auf die Website zu bringen.

Aktuell:

  • Wir haben Dutzende von aktiven Mailinglisten
  • mit Hunderten von aktiven Teilnehmern
  • und Tausenden von passiven Abonnenten.
  • Diese Listen reichen buchstäblich über 20 Jahre zurück.
  • Viele Open-Source-Leute der alten Schule sind wirklich an diese Arbeitsweise gebunden.
  • sie ist vertraut,
  • bereits eingerichtet und
  • kommt täglich in den Arbeitsablauf, ohne dass man "eine Website überprüfen" muss.
  • Viele Leute sind in verschiedenen Teilen des Projekts aktiv, aber dieser “Fußabdruck” ist sehr individuell

Aber:

I. Diese Listen sind weniger funktional, als viele Leute denken:

  • Moderation ist fast unmöglich (bestenfalls ein Alles-oder-Nichts-Ansatz)
  • trotz Bemühungen halten sich die Leute nicht immer an die Standards, die wir erwarten
  • Mega-Threads sind keine gute Diskussion
  • Belästigung außerhalb der Liste ist leicht zu starten und liegt außerhalb unserer Kontrolle
  • Cross-Posting ist ein Chaos, da die Abonnements nicht konsistent sind
  • Unmöglich, auf dem Laufenden zu bleiben, es sei denn, man ist engagiert
  • Leute, die teilnehmen sollten, nehmen aus verschiedenen Gründen nicht teil

II. E-Mail ist nicht die Zukunft

  • Mailinglisten sind für Suchmaschinen weitgehend undurchsichtig und erscheinen der Welt nicht als “echte Aktivität”.
  • Neue Leute wollen sich nicht für Mailinglisten anmelden.[5]
  • Die “Kultur” der Mailinglisten ist nicht mehr wirklich vorhanden.[6]
  • Und die Weboberfläche von Gmail ist traditionellen Konventionen wie Inline-Antworten aktiv abgeneigt.

III. E-Mail im Allgemeinen ist zum Scheitern verurteilt

  • Große Anbieter haben die Skalierbarkeit, Spam für sich selbst zu “lösen”, und haben jetzt keinen Anreiz mehr, ihn global zu lösen.
  • Kleine Anbieter haben eine abnehmende Chance, zuverlässig zu liefern.
  • Mailinglisten veröffentlichen inhärent erneut, und die gesamte Anmelde- und Verifizierungsinfrastruktur kümmert sich nicht wirklich darum.
  • Unternehmen steigen auf Slack und ähnliches für funktionale Kommunikation um und überlassen E-Mail für Ankündigungen und Sendungen.
  • und Jira und Github und so weiter für workflow-orientierte Interaktionen.
  • Wiederum: “normale” Leute nutzen es für nichts anderes, als Benachrichtigungen von verschiedenen Unternehmen zu erhalten, von denen sie Kunden sind. Es ist nicht mehr wirklich für die persönliche Kommunikation gedacht.

Aber es gibt immer noch einen Bedarf

Wir haben Echtzeitgespräche abgedeckt[7], aber wir brauchen immer noch die langen, asynchronen Gespräche, die Mailinglisten geboten haben. Chat deckt nicht alles ab, funktioniert global nicht gut und mit Freiwilligen mit unterschiedlichen Zeitverpflichtungen. Und Workflow-Tools sind zu eng gefasst.

Discourse ist wirklich die beste Option

  • Mailinglisten sind keine praktikable Zukunft.

  • Hyperkitty steckt in 2014 fest.

  • Wir haben zu viel, um nur Github / Gitlab zu nutzen.

  • Andere Möglichkeiten reichen nicht aus:

  • Ponymail leidet unter dem gleichen Problem “E-Mail als GCF”

  • Vanilla ist nicht gut. Ich lasse das einfach mal so stehen. :slight_smile:

  • Google Groups ist das Schlimmste von allem.

  • Auf der Habenseite für Discourse: Viele andere Open-Source-Communities konsolidieren sich darum. Insbesondere: Python, GNOME…

Treten Sie Cassandra entgegen

Nicht die Datenbank – ich meine, Leuten vom Untergang erzählen, aber niemand glaubt es. Ich höre viel “E-Mail funktioniert gut”, und “Ich sehe kein Problem mit Mailinglisten”, und natürlich “Ich hasse Foren”, oder sogar speziell “Ich mag Discourse nicht”.

Aber wir brauchen wirklich eine Veränderung.

Also…

Ich muss eine große, aktive, wichtige Open-Source-Community dazu bringen, ihre primäre Kommunikationsplattform für das Projekt auf Discourse zu verlagern, und viele Leute sind skeptisch. Es ist eine große Veränderung. Ich möchte das so einfach wie möglich machen, sowohl um es für die Leute, die skeptisch, aber bereit sind, es zu versuchen, einfacher und angenehmer zu machen, als auch um es für Leute, die E-Mail-Interaktion – einschließlich Filterung – als persönliche Blockade haben, möglich zu machen.
Ich denke, wenn sie erst einmal dort sind, werden viele Leute ihr Verhalten anpassen – wir werden mehr Leute entdecken, dass die direkte Interaktion mit der Website gar nicht so schlecht ist.[8] Und wir haben unser eigenes projektweites Benachrichtigungssystem, das ich zu integrieren plane, und hoffentlich kann das den Leuten irgendwann mehr von dem geben, was sie wirklich brauchen.

Aber in der Zwischenzeit muss ich den Leuten geben, wonach sie fragen.

  1. Ich habe tatsächlich versucht, Discourse zu dieser Zeit als alternativen Ansatz vorzuschlagen, anstatt unsere eigene Lösung zu entwickeln. Wenn ich eine Zeitmaschine hätte, würde ich vielleicht zurückgehen und das noch stärker vorantreiben. Aber ich war damals nicht in meiner jetzigen Position und das Schicksal war besiegelt… ↩︎

  2. Ähnliche Lektion von LUGNET, ich denke, die erstaunlichste und sinnvollste Forensoftware der 90er Jahre – aber an NNTP als Backend gebunden. ↩︎

  3. Ich kenne die Redewendung “kleinster gemeinsamer Nenner”, aber das ergibt keinen Sinn. Wie “Ich könnte mich weniger darum kümmern”, aber jetzt auch mit Mathematik. ↩︎

  4. Ich meine, wenn Sie sich nicht schon erinnern, natürlich! ↩︎

  5. In Korea ist E-Mail für alte Leute ist für uns alle gekommen! ↩︎

  6. Ich kann mich nicht erinnern, wann ich das letzte Mal jemanden “Netiquette” sagen hörte. ↩︎

  7. mit Matrix, unter https://chat.fedoraproject.org/… ↩︎

  8. Obwohl wir definitiv diese Person haben, wird es also nicht jeder sein. ↩︎

5 „Gefällt mir“
10

Schöne Zusammenfassung! :ok_hand:

Können Sie die Filterung, über die Sie sprechen, etwas detaillierter beschreiben, die die Leute in ihren E-Mails verwenden? Ich bin auch schon eine Weile dabei und habe selbst Mailman-Listen betrieben und an vielen Mailinglisten teilgenommen (und tue dies immer noch), aber ich bin noch nie auf automatische Filterung über Header gestoßen. Mir scheint, wenn sich jemand für eine Liste anmeldet und sie in einen Ordner in seiner E-Mail filtern möchte, würde er das selbst auf Listenbasis einrichten. Das kann man doch auch mit Discourse machen, oder?

Ich denke, Kategorien funktionieren als Ersatz für Mailinglisten recht gut, mit dem Mailinglistenmodus, der vom Benutzer aktiviert wird, oder dem Benutzer, der bestimmte Kategorien beobachtet, damit er für jeden Beitrag eine E-Mail erhält. Vielleicht müssen wir auch noch mehr darüber lernen, warum Sie denken, dass die Organisation von Diskussionen in Tags besser ist und die Mühe wert ist, um mit der Funktionsweise von Kategorien bereits übereinzustimmen.

Bearbeitung: Ich erinnere mich an meinen alten Beitrag dazu aus dem Jahr 2014! :scream:

1 „Gefällt mir“
11

Sicher. Die Header, die Discourse derzeit setzt, sehen so aus (von einer tatsächlichen Benachrichtigung aus diesem Thread):

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

Wenn es nicht Gmail wäre, würde das Hinzufügen von etwas wie:

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

Siehe Customs email headers and/or subjects tags - #6 by mattdm — wenn die Einstellung email custom headers durch Template-Expansion übergeben würde, sodass X-Discourse-Tags: %{optional_tags} funktionieren würde, wäre dieser Teil bereits erledigt.

Und für Benutzer von Procmail und anderen Old-School-E-Mail-Clients wäre dies ausreichend. Leider kann Gmail aus unerfindlichen Google-Gründen nicht nach beliebigen Tags filtern und ist (soweit ich weiß) auf To:, From:, Cc: und … glücklicherweise zumindest List-ID beschränkt. Da dies der Elefant im Raum ist, ist es am besten, um diese Benutzer zu berücksichtigen, List-ID nach Tag anstelle von Kategorie (oder in Kombination?) festzulegen.

Jedoch besagt RFC 2919, dass pro Nachricht nur eine List-ID zulässig ist. Das lässt also:

  1. Willkürlich einen Tag auswählen[1]
  2. Etwas generieren, das alle Tags enthält, wie List-ID: firsttag_secondtag.discourse.example.org und die Benutzer das herausfinden lassen. [2]
  3. Mehrere E-Mails pro Benachrichtigung generieren, eine für jeden Tag, die sich nur in diesem Header unterscheiden[3]
  4. List-ID auf die Kategorie verweisen lassen und stattdessen die CC-Idee verwenden… [4]

Ich mag keine dieser Optionen wirklich. Daher würde X-Discourse-Tags: als erster Schritt zumindest die Nicht-Gmail-Benutzer abdecken. (Was wahrscheinlich eine ziemlich gute Überschneidung mit webresistenten Benutzern darstellt, daher denke ich, dass es sich lohnt, zu sehen, wie weit uns das bringt.)

  1. verwirrend! ↩︎

  2. nicht gut ↩︎

  3. auch nicht gut ↩︎

  4. ziemlich umständlich. Das bloße Hinzufügen von Cc: %{optional_tags}[4] würde nicht ausreichen, da es erweitert werden müsste, sodass jeder Tag einer echten (Black-Hole-) E-Mail-Adresse entspricht. ↩︎

3 „Gefällt mir“
12

Ja, sehr sogar! Dein letzter Absatz fasst die Dinge gut zusammen!

2 „Gefällt mir“
13

Sehr unterstützend bei der Hinzufügung von X-Discourse-Tags und X-Discourse-Category (zur Parität).

Ich schätze, langfristig könnten wir für Gmail eine Benutzeroption hinzufügen:

  • Bitte fügen Sie alle Tags, zu denen dieses Thema gehört, in die E-Mail-Betreffzeilen ein.

Z.B. etwas in der Art von.:

[Discourse Meta] [feature] [email] [notifications] Header für E-Mail-Benachrichtigungen

Oder vielleicht, wenn aktiviert:

[Discourse Meta] Header für E-Mail-Benachrichtigungen … [feature] [email] [notifications]

5 „Gefällt mir“
14

Ja, das wäre als Benutzeroption interessant. Wir haben derzeit diese sitewide:

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

Wir haben starkes Feedback erhalten, dass es nervig ist, die Tags irgendwo anders als am Ende zu platzieren. Und einige Rückmeldungen, dass Google nicht sehr gut darin ist, nützlich nach teilweisen Betreffzeilen zu filtern.

Ich bin mir nicht sicher, wie viel wir Google “reparieren” können (oder besser gesagt, ich bin mir ziemlich sicher, und es ist “nicht sehr viel”). Es könnte also ein gewisses Maß an “ach was soll’s” geben, von dem ich Leute überzeugen muss, es zu akzeptieren.

4 „Gefällt mir“
15

Es gibt ein paar Kleinigkeiten, die wir tun können, um die Situation zu verbessern.

Im Moment:

  1. Beschränken wir auf 3 (willkürliche Reihenfolge)
  2. Umschließen wir Tags nicht mit [ und ]

Ich bin unentschlossen, aber ich denke, die willkürliche Grenze von 3 ist nicht gut, wir sollten sie einfach entfernen.

Zusätzlich wäre tags.map{|t| "[#{t}]"}.join(" ") besser, da der Filter dann auf [tagname] statt tagname angewendet werden kann, was viel wahrscheinlicher im PM-Titel vorkommt.

@martin, was denkst du?

5 „Gefällt mir“
16

Das ergibt mehr Sinn, wenn man die Geschichte kennt. Es klingt, als hättest du ein Budget, um die Dinge zu realisieren, und einige gute Ideen, um einen guten Anfang zu machen. Ich denke, es wird schwierig sein, und der Import all dieser Daten wird eine Herausforderung sein. Es wird immer noch schwierig sein, all diese Leute glücklich zu machen, und Sam unterstützt zumindest einige deiner Ideen, sodass sie in den Kern integriert werden und in Zukunft nicht kaputt gehen, wie es bei einem Plugin wahrscheinlich der Fall wäre.

3 „Gefällt mir“
17

Ich stimme Ihnen hier zu, obwohl ich denke, dass wir anstatt das Limit ganz zu entfernen, uns auf die Einstellung max_tags_per_topic verlassen können? Ich denke, das wäre sicherer.

Leider hilft das Hinzufügen von [] um die Tags beim Gmail-Suchen nicht viel, nur visuell, da Gmail, soweit ich sehen kann (z. B. siehe https://webapps.stackexchange.com/questions/52828/create-gmail-filter-that-contains-a-special-character, die verlinkte Dokumentation ist nicht mehr vorhanden, aber sie ist immer noch gültig), Sonderzeichen beim Suchen im Betreff und an anderen Stellen entfernt. Versuchen Sie, in Gmail nach subject:(\"[support]\") zu suchen. Sie erhalten alles mit “support” im Betreff, nicht nur die mit eckigen Klammern. Das ist irgendwie unsinnig von Google, sie sind schließlich ein Suchunternehmen (naja, Suche und Werbung), aber wir können nichts dagegen tun.

Wir sollten auch in der Lage sein, X-Discourse-Tags und X-Discourse-Category gleichzeitig in MessageBuilder hinzuzufügen, da wir diese Optionen bereits haben, und wie Sie sagen, @mattdm, deckt dies die webresistenten Benutzer gut ab:

Ich kann das übernehmen, wenn Sie möchten?

5 „Gefällt mir“
21

Ich habe das gerade zusammengeführt, @mattdm:

Das hilft bei Gmail nicht wirklich viel, aber dies sollte zumindest Benutzern von terminalbasierten E-Mails helfen, damit sie diese leichter filtern können.

6 „Gefällt mir“
22

Hinweis @mattdm, wir haben uns wirklich bemüht, aber Gmail ist einfach so schwierig. Es entfernt so viel vom Text beim Tokenisieren, dass einem die Hände ziemlich gebunden sind.

Die einzige Umgehungslösung, die mir einfällt, ist, die Tag-Namen in E-Mails super hässlich zu machen:

„Dies ist ein Demo-Betreff. [Temail, Tnotifications]“ (Präfix T oder eine andere Alpha-Sequenz, die Gmail „mag“)

Aber es ist eine ziemlich hässliche und unintuitive Lösung.

3 „Gefällt mir“
23

Danke Sam (und allen!).

Ich schätze die Bemühungen, die hier investiert wurden. Letztendlich können wir nicht viel gegen Googles undurchsichtige Entscheidungen tun.

Ja, im Ernst. Das Einzige, was mir noch einfällt, wäre eine Option pro Benutzer hinzuzufügen:

Betreffzeilen von E-Mail-Benachrichtigungen im extrem hässlichen Format mit Tag-Namen anzeigen, nach denen Gmail filtern kann.

:-/

5 „Gefällt mir“