Genauer Sinn und Zweck von IDs, die manchmal im BODY von E-Mails stehen

Was genau bezwecken die folgenden IDs in Mails, die ich erhalte(n) habe?

a) Mails an mich von meinem ISP:

Die E-Mails meines ISPs mit Standort in Deutschland enthalten am Ende des E-Mail-Bodys oft, aber nicht immer, eine jeweils eindeutige ID, bestehend aus Ziffern und Buchstaben, die ID dabei > 20 Zeichen lang. Die IDs werden dabei immer eingeleitet mit einem vorangestellten „ref:“ oder „thread:“.

In den E-Mails meines ISPs sind diese IDs, wenn sie denn eingesetzt werden, immer in denjenigen E-Mails sichtbar, die im reinen Textformat verschickt werden.

In den E-Mails meines ISPs sind diese IDs nicht immer enthalten, wenn es sich dabei um E-Mails handelt, die mit Hilfe von HTML formatiert worden sind.

Warum genau setzt mein ISP diese IDs gegenüber seinen Kunden ein?

b) Mail an mich von einer mir unbekannten Person:

Von einer mir unbekannten Person, die vorgibt, mir im Auftrag eines deutschen Lebensmitteldiscounters zu antworten, an den ich mich vor einiger Zeit per Online-Kontakformular gewandt hatte, habe ich vor Kurzem eine Mail erhalten. Die Absender-Domain dieser Mail ist gmail.com. Der Absender dieser Mail bittet mich, ihm per Rückantwort meine Wohnanschrift mitzuteilen, was ich natürlich nicht zu tun gedenke.

In meinem E-Mailprogramm KMail, das nur unter Linux eingesetzt werden kann, wird diese E-Mail als nicht mit HTML formatiert angezeigt. Sie erweckt also den Eindruck, als ob sie nicht mit Hilfe von HTML formatiert worden ist. Sie enthält allerdings doch HTM-Quellcode, dieser ist in KMail ersichtlich über den Menüpunkt „Nachrichtencode ansehen“ > Reiter „HMTL-Quelltext“.

Diese E-Mail enthält allerdings auch eine ID am Ende der Mail, sie wird über den Menüpunkt „Nachrichtencode ansehen“ > Reiter „Quelltext“ in KMail unterhalb des letzten, abschließenden DIV-Tags´ angezeigt und hat folgendes Format:

– – <29 Zeichen, bestehend aus Ziffern und Buchstaben> – –

Generiert Gmail bei jeder einzelnen E-Mail, die über seine Mailserver verschickt werden, derartige, offensichtlich einzigartige IDS und bettet sie in alle ausgehenden E-Mails ein?

Oder hat hier der Absender der o. g. Mail, die er von gmail.com aus an mich verschickt hat, eigenständig die genannte ID in seine Mail integriert?

Ich würde behaupten das ist die Signatur Deines Mailproviders bevor die gespeichert wird.

wie kommst Du darauf? Und warum bei gmail.com und nicht bei anderen?
Die MessageId steht im Header.

Weil jeder sein eigenes Süppchen kocht?

Hier was ich denke was es ist, aber wozu es dient und warum, kein Plan…
https://borisreitman.medium.com/marking-and-tracking-emails-c3b48c02638e

völlig ok. Ich habe auch oft nur Halbwissen…
Der Artikel beschreibt Header, die Originalfrage bezog sich auf Ids im Inhalt. Dass das auch dem Tracking dient ist nicht ausgeschlossen, aber da in Mails nur begrenzt HTML erlaubt und Javascript verboten ist, dient es vielleicht eher als Ersatz für eine MessageId. Viele CRM-Systeme machen das gleich im Betreff.

Es geht eher um die Nutzung des boundary, also die Teilung von Header und Body, um hier eine eindeutige ID für sich als Provider (imap Server) zu setzen man packt die Mail nochmal extra ein, ich vermute zum Zweck der Qualitätskontrolle, kann intern in der Datenbank wunderbar verarbeitetet weil die id Informationen enthalten kann, verändert die ursprüngliche messageID nicht (was google wohl macht) und Clients lieben das wohl auch. Das trifft wohl nur auf plain text Nachrichten zu.Weshalb das wohl hier manchmal vorkommt und manchmal nicht.

Hi @anon83163390 und @Joachim,

vielen Dank schon mal für Euren Input. Mir ist natürlich klar, dass diese IDs irgendwas mit Tracking zu tun haben. Würde ich auf die o.g. Mails per Antworten-Button antworten und die Original-Mail des Absenders in meiner Antwort belassen, dann würde der Absender die von ihm gesetzte ID wieder zurückbekommen, und er würde dann wissen, dass tatsächlich ich auf seine Mail geantwortet habe. Zusätzlich auch zu einer gewissen Ticket-ID im Falle von dem o. g. Szenario a)

Im Fall von a) mache ich so was ja, je nachdem, worum es in der Mail, die ich von meinem ISP erhalte, geht.

Im Fall von b) werde ich aber nicht auf die erhaltene Mail antworten, weil ich nicht weiß, wer mir da eigentlich geschrieben hat. Jedenfalls nicht jemand von einem offiziellen Mailkonto des besagten Discounters.

So ganz hab ich’s nicht verstanden, aber man kann natürlich nicht nur im Mailheader, sondern irgendwo im Mailbody Marker oder IDs einfügen, damit z.B. bei einer Antwort auf eine Mail eine Automatisierung der Zuordnung stattfinden kann. Stichwort „Ticketsystem“. Damit wäre z.B. gewährleistet, dass wenn Du so eine Mail 2-3x weiterleitest oder kopierst ohne die Header mitzunehmen, ein Ticketsystem trotzdem noch was damit anfangen kann.

Oder ich hab’ zu wenige Kaffee intus und das nicht kapiert… :wink:

@NichtDieMama

ja genau, an ein Ticketsystem dachte ich auch im oben genannten Fall a). Die Rückantwort des Kunden auf die Mail vom Kundensupport mit der ID im Body wird anhand dieser ID automatisch in das entsprechende Ticket eingetütet.

Den von mir oben beschriebenen Fall a) finde ich ja deswegen nicht schlimm. Ich wollte aber trotzdem mal darauf aufmerksam gemacht haben

Den von mir oben erläuterten Fall b) jedoch finde ich merkwürdig. Siehe meine diesbezüglichen Fragen dazu in meinem Erst-Post in diesem Thread.

Es gibt verschiedene Möglichkeiten für IDs in einer Mail.
Wie schon beschrieben im Rahmen von Ticketsystemen, um evtl. Antworten dem richtigen Sachverhalt zuordnen zu können. Allerdings kenne ich das so, dass solche Ticket-IDs dann meist im Betreff auftreten.
Ansonsten sind interne (und in HTML-Ansichten „unsichtbare“) IDs üblich im Rahmen von Marketing-Aktionen („Kampagnen“), z.B. Newslettersystemen, wo jede Mail eine eigene ID erhält, die für gewisse Dinge eine Rolle spielen kann.

Es geht auch einfacher. „ref:“ in englischer Korrespondenz bedeutet das gleiche wie „betrifft:“ oder „unser Zeichen:“ in deutschen Briefen.

https://www.collinsdictionary.com/us/dictionary/english/ref

Bei mir ist jede Mail von meinen Anbieter mit dieser boundary ID versehen und zwar immer am Anfang und am Ende des PGP codes…

Beispiel Source code einer mit PGP Verschlüsselten Nachricht

Content-Type: multipart/encrypted;
protocol=„application/pgp-encrypted“;
boundary=„1712745414/517092/35821/dobby31b.heinlein-hosting.de“

This is a MIME-encapsulated message.

–1712745414/517092/35821/dobby31b.heinlein-hosting.de
Content-Type: application/pgp-encrypted
Content-Disposition: attachment

Version: 1

–1712745414/517092/35821/dobby31b.heinlein-hosting.de
Content-Type: application/octet-stream
Content-Disposition: inline; filename=„msg.asc“

-----BEGIN PGP MESSAGE-----

hQIMA2lDNgfB1TWOARAAw3ZOjEqTvpIORwPeW9NixBefEi49vyXYiJfYUkf4+55a
/+LxXr0Z7OHq2Z34nIo1b9eTFwogfJnUEgS+SrveEcI1rCeVxUYqLR+xwxLXBToB
qqsvRuheQGwDszYRygRKUS0MvUtyXCko1+pjNYj3UT1ylDG6qN2Ah6yK8vk7Sl13
QricLM7ABMbe5OWtBG/4uYO9mbec8CEhi6vx0HdxyKKL5d/RLBEc6dTQO4loERdY
l8exqze4UpgXvKux8C4zj2Pibw+taEBgwZEuGt8Oku9IPGy16MChx2abydMhe8Zb
47K8eSnUC1HKaUcEOHrWGQy9u7vb5s7saa8+1W6FdLwhTcL6ivBry6AqQJ4BP0ys
MXaFioRWmrLsB8q3vf5vYhzgjfiTQnkXxXUmjeWdO8GIAKQrWi/T4Fy9az+KU8Qk
KVfH/KW5TDzLBcNlJmSvD7/1vxN2QhsGPcFgtRkKw1hbhUGjGQv9GbQubzh6Nldb
JEYPxNC35mnPEvTlyB/93rwqkkmZVl7X3pPK9AmCJ+F12NZGoh2i35DOM1zp4UUs
fE/MqpNU9IM0ArnljOR1UQPtB9twoyzhfJKXWU7wWCW81SNsSXzgCSApmNQhOzPb
yPH9tX9GMKZLuRvqptGDY0wzDuubOwu2LVkwf+WrbaVR+OjX9PJLi5EYFVkHEzvS
6wEVMsReQh9BiVA69esxJSewfA/RCBEr2nLmJY275Kb7zQLRhrHj5U8dIj7484JP
Z1VG0E4QY14bbb93SB1pK422/BuWg+BdDjvZaNGSC6wk37ELiJOsRLUEEHMMZfof
p+45e1DpH7ZY4hV+98rDSVCImzkl+ruZTesgv45bFlqQpERq5erxsO5w2G5Gvx+1
NYEfYypXx6sDKg5rrfQ+PNuDafzb5WhY6S5i5NiGl0rzu+8mD8R/Q1J9z+AQSlEU
+RsRrRtAqwTZpKbIY22jsmKwrC2mRE2Qzia+uXw3QzAEjfC26xHwt7zsViaEPWrd
vjwpTGbEVJ07Ragpt0MCzvS5x5NBWk5vAuiME/K9e0yme3HQxRhTNTm2zwuODAb7
251N6A26qrXLkuSnTaDSQ9L04q+hD6YrGzhF9Go6octI0355ATYdb9dbmwlOmQ8X
6u8yVvVOFJ/i/oPfLzI0K55/QnsocYWZNPSd0D6QVYIiqgLL0VyMSs6Q0Ro6Q4rs
VrBbVVtWBVK+WjdgdHKsijpKFFHQKZZPSf3JD6/thNBDSLHOjb+yLoDSiTBloaHY
lnoOhJhjOUAPD1P1dp3JK7cbf2td29JqUwr4EAZnC9XlOLyCkp+7KbjBpkh6Sp1Z
s0MXP/4kKOsypwKEpq9e0QILpn2us0maQCD2iKD8+pzYVzJMOKeK5sTJVDPv3nMj
IuNXVdZa6D8vMvoUzaRFn4F0GiqL1sqQr5oEUgS1f+Avki9iZiMY/0tU6SvP2yk8
4G+bekQpBKJpRXLW5o/bhnWJSUFfNCUlmboG5nfIGcAh75T7OJHBkZYVEL51UIKM
HGkGBOJ4cXATAW+fAXvKTwPi+DWQx/1noilhFzEKAwVHMbg5ZA9LnXPu1aEZ0jm3
luNIJH88v4/FHCqe1sMJcquCnKLH8CLeFEX09h/ptHxXU9N6uNjbo4J4tzsrSmlr
qVRGJX51C2housls7Fqg0E4VAgCGN/ao53T3zQ7Ttg3D432AWq2pWB4zz3Rsg7Lk
itgMvA/T77U2uyi3gXQILlA5EoZa7ud8GU4Y0SLISDR9AH2+rvlbN8NL2pFAXSLX
Dpl6/Ut04xM0HFAJ8btwKf7DysOg80FAjSD0neVUEDyOk0NOPM7xenrxowY1Le1g
SKJJ0YvDccZT9ZH/ctq7VTwhJqB8ztkMTltWW/moVyljqVy3zl7iDgOEZVHOPnuP
N+0akjnQ7y2WUcM0KmBi7yy3bifIYxgAXF8PPcmqju3NRqBJuHp2Oxv3UD0oldRv
H4beE0UYd2OKnPShzNPrDHFdEnwRqYymqVxkVu5Tjk3TnhKfF2qfqS2XYgxsSBgP
liitJY8s6ZyRwCQ3Ot4KJh8BMJcZ8yvnP9AqOLrRVCa5eh9xbQ21R2Dh6XJSA8X/
Vufd+b0EZOlaxX+1p2LFCtPN1wz3hJJNcBgz47kX33VHdVFEBlGz8eH+XHni0Jz4
qXo41UZRbDr4HueJ7tdT766yNJzcs7c+MnyHcq0COjGQ+5P3+Qvo3Jlu/t3FX6v3
YZurM4NdF4GpOiEb3YjR1zKlDm6dcNo/3hiintvLiP8d9K9dnCgMDrnmMXeAzRtD
ItSsADhyN78DDXlaniQsyTr6zgln9i29+/i6pY3iQfRZZuTMUsBmZ4t3R5EYXaWN
5x4iUJvJ/Rd0UD882J1PZt15Q0LbEdbndSfUgHNC0PI2h1SUNu+ZQSr96HasB4h6
fy3Wlg8O9eUR3P8GMlTlAIT8BkHSjPy321E1GrHEEEZX2bPCxGf8ovaRt9kjRXzf
NaPW5Ot1Qjn28itxcSkaVuC3Qlq5ribtRYpizbA+Q2+Z55ypFLFoS9fRWVG8UBkW
Z68O0Jpx7dI/67UUV1Zbk/PO4m9SoTEwY5Qm7iMyAEHmzDSSfYDUB0XUlSdcBrKi
O2Bhi1jBw6O1K7JZGZiGCvKebg5tdjTtjqVHKLjo1CcRBrrpCMJuHlKMWW2OTSAX
A5IBmAYaEjz/zKDRnS7+FLy2hlbPgobocFez9c65QFRXKv4RMtAazpF94L9XEpaU
EVpRvZkpzjNN+9NL3Q/2OUinLyiaPjqCFvJxm1QCQ046v5xfa/vGLgparCbDnsQL
esvrOcqZzIWxnV1k1XBhd/4QawJhi8abOsQN1gMLSzybstuphehL4uUdHh3j4up6
yQzpvYYGdCPI+/yZSIXtsIA32gCNT9yO0045Q/539BWudsQJIcKipkuV4vaGG8Qs
9uerJ3jCrtIlU56KVyroUvcCpMjXCUYg8YUN+r6qE/K9NcsveLnKPNUyUxyq5xIi
1E6X/PcczOzkNpiruVzzbeZkbIMgzMaOoamV0Ibv7m8/Eh/vZLUSHt8p5BfG/GIr
IZ/hSrGlLgbL7pjXItu2+6ecovQJb5jceyqm6cZ4j2/znxi3H1P9jWngdAA5VRU5
/+12RqBVmG0mjczWuqIYf2Cx2dxIvdp60Eh49bOzWgcoCar3tw8NU/WtAzFqNsJD
BOx2kOhbpqFOoQuAMvjtH5S+m4rOHSg7yDYfBnQ++fc6QQtSQmBD5mSXjdk7MC0f
WmkaycxBv6NY8eXoXRe+3m5KY2XpseK7EyZvBK8Fc8cK5Lr+hcoSBMKdf+JLuRsz
BtqcMsAoBG/xD74R3GdZ3KKc9WPQ/oZJIo54YeBHQfwDDS7Piq0EDy4996Nt4gkg
/A37XVXJNacPZxL7u2syo1ZLUTaiyU2lMmRwwjqGG6UxJxL/LBcfWXKjCJ0q4E78
cCIGj4fxEzMgtLI1UxJ/Oatz04BzMyTM5A==
=beuv
-----END PGP MESSAGE-----

–1712745414/517092/35821/dobby31b.heinlein-hosting.de–

Es ist quasi eine Formatierung, hier im Beispiel der verschlüsselte Inhalt, wird in einen extra body gepackt, als Datei msg.asc.
Bei FairEmail z.B. wird wenn die Nachricht ankommt, diese Datei msg.asc als Anhang runter geladen und dann erst entschlüsselt. Da alle meine Mails auf dem Server verschlüsselt sind, sehen die auch alle so aus, der Header hingegen enthält jedes mal andere Informationen,

Ob, wie oder wofür die Anbieter diese Information verwenden ist mir aber bisher nicht bekannt. Aufgrund der Eigenheit dieser „Tracking“ Information, gehe ich aber ausschließlich vom Einsatz der Server Betreiber selber aus, der diese Information „verarbeiten“ oder überhaupt generieren kann. Ich würde es als Art Poststempel bezeichnen.
Ich müsste mal prüfen ob diese Merkmale nur bei mir auf dem Server so sind, oder ob zum Beispiel bei einem weiteren Anbieter diese Merkmale verändert, überschrieben oder gelöscht werden.

das sind nach meinem Verständnis andere IDs als die von @Senf. Boundary IDs werden bei allen Attachments verwendet und verschlüsselte Nachrichten sind Attachments.

Genau, und dabei ist es egal ob mit PGP, S/MIME oder TLS verschlüsselt wurde und was

hier beschrieben hat, entspricht dem was hier unter „7.2.1 Multipart: The common syntax“ für die Notierung der boundary IDs vorgegeben wird.

– –

am Anfang die „two hyphen characters“ beenden einen < body >.

– –

„two hyphen characters“ am Ende und am Anfang der boundary ID, beenden einen verschachtelten/verkapselten < body >.

Deshalb meine Schlussfolgerung, das es sich hier um genau diese boundary IDs handelt. Ich kann natürlich irren, aber bis jetzt keine plausiblere Antwort gefunden.

Das ist das Thema, nicht attachments usw.

a) war doch schon geklärt

Meine Hinweise sind in diesem Bezug zu betrachten.

1 „Gefällt mir“

Nope. TLS verändert den Inhalt der Nachricht nicht und erfindet auch keine IDs. Davon dass @Senf eine verschlüsselte Mail empfangen hat war keine Rede.

Boundarys iDs, gehören nicht zur Nachricht und da erfindet auch kein TLS iDs, die werden vom Betreiber des Servers verwendet um e-Mails zu formatieren damit jeder client diese Nachricht korrekt darstellen kann.