Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Telekom: Wichtige Sicherheitswarnung
18 views
Skip to first unread message
Marco Moock
Sep 28, 2022, 9:13:23 AM9/28/22
to
Am 28.09.2022 um 14:15:44 Uhr schrieb Volker Delf:
> Zitat der Telekom per Brief:
> "Von Hinweisgebern haben wir Informationen erhalten,
> dass über Ihren Internetzugang Spam- oder
> Phishing-Mails versendet wurden."
Erfrage mehr Informationen.
Lief das über SMTP Port 25 oder wurde der Spam an die
Telekom-Eingangsserver mit Authentifizierung verschickt?
Hast du daheim nen Server in Betrieb?
> Zitat der Telekom per Brief:
> "Von Hinweisgebern haben wir Informationen erhalten,
> dass über Ihren Internetzugang Spam- oder
> Phishing-Mails versendet wurden."
Erfrage mehr Informationen.
Lief das über SMTP Port 25 oder wurde der Spam an die
Telekom-Eingangsserver mit Authentifizierung verschickt?
Hast du daheim nen Server in Betrieb?
Peter J. Holzer
Sep 28, 2022, 12:41:39 PM9/28/22
to
On 2022-09-28 12:15, Volker Delf <nop...@ist.invalid> wrote:
> Zitat der Telekom per Brief:
> "Von Hinweisgebern haben wir Informationen erhalten,
> dass über Ihren Internetzugang Spam- oder
> Phishing-Mails versendet wurden."
>
> Ein Ändern des E-Mail-Passwortes und des Web-Passwortes
> Zitat der Telekom per Brief:
> "Von Hinweisgebern haben wir Informationen erhalten,
> dass über Ihren Internetzugang Spam- oder
> Phishing-Mails versendet wurden."
>
> zur betroffenen E-Mail-Adresse ist erforderlich, um
> weiterhin E-Mails versenden zu können.
Das ist etwas widersprüchlich. Einerseits ist da von einem
Internetzugang die Rede, andererseits wird zum Ändern des Passworts für
deinen E-Mail-Account aufgefordert. Das eine hat aber mit dem anderen
nicht unbedingt etwas zu tun.
> Was ist da geschehen?
Kann man auf Grund der spärlichen Informationen nicht sagen. Ich
schließe mich Marco an: Frag nach!
> Soweit mir bekannt speichert die Telekom den Hashwert
> des Passwortes.
>
> Seit Jahren ist das E-Mail-Passwort im E-Mail-Programm
> nicht geändert worden.
Das schließt natürlich nicht aus, dass das Passwort geleckt ist (eher im
Gegenteil).
Aber da vom Internetzugang die Rede ist, kann der Spam auch anders
verschickt worden sein (z.B. könnte dein Rechner Teil eines Botnetzes
sein).
hp
Herrand Petrowitsch
Sep 28, 2022, 12:48:51 PM9/28/22
to
Peter J. Holzer schrieb:
Gruss Herrand
--
Emails an die angegebene Adresse werden gelegentlich sogar gelesen.
> Volker Delf <nop...@ist.invalid> wrote:
>> Zitat der Telekom per Brief:
>> [...]
>> Zitat der Telekom per Brief:
>> Seit Jahren ist das E-Mail-Passwort im E-Mail-Programm
>> nicht geändert worden.
>
> Das schließt natürlich nicht aus, dass das Passwort geleckt ist (eher im
> Gegenteil).
>
> Aber da vom Internetzugang die Rede ist, kann der Spam auch anders
> verschickt worden sein (z.B. könnte dein Rechner Teil eines Botnetzes
> sein).
Bei einem Invaliden mit ~20 Jahre altem NUA keine Seltenheit.
>> nicht geändert worden.
>
> Das schließt natürlich nicht aus, dass das Passwort geleckt ist (eher im
> Gegenteil).
>
> Aber da vom Internetzugang die Rede ist, kann der Spam auch anders
> verschickt worden sein (z.B. könnte dein Rechner Teil eines Botnetzes
> sein).
Gruss Herrand
--
Emails an die angegebene Adresse werden gelegentlich sogar gelesen.
Marco Moock
Sep 29, 2022, 4:58:34 AM9/29/22
to
Am 29.09.2022 um 09:37:08 Uhr schrieb Volker Delf:
> Zitat von der Telekom per E-Mail:
> "Über unsere E-Mail-Systeme wurden mit Ihrer
> Benutzerkennung Spam- oder Phishing-Mails versendet."
Dann ändere umgehend dein Passwort da.
Am besten setzt du auch alle Rechner neu auf, wenn du 100%
sicherstellen willst, dass da keine Schadsoftware mehr drauf ist.
Virenscans sind hierfür unzureichend.
> Zitat von der Telekom per E-Mail:
> "Über unsere E-Mail-Systeme wurden mit Ihrer
> Benutzerkennung Spam- oder Phishing-Mails versendet."
Dann ändere umgehend dein Passwort da.
Am besten setzt du auch alle Rechner neu auf, wenn du 100%
sicherstellen willst, dass da keine Schadsoftware mehr drauf ist.
Virenscans sind hierfür unzureichend.
Marcel Mueller
Sep 29, 2022, 2:02:28 PM9/29/22
to
Am 28.09.22 um 14:15 schrieb Volker Delf:
Ich würde sagen Phishing-Mail.
Wären wirklich größere Mengen Spam über den Account versendet worden,
würde Passwort ändern den infizierten Rechner sicher auch nicht säubern. ;-)
Allerdings hat die Telekom tatsächlich zuweilen ziemlich niedrige
Schwellen für die automatische Missbrauch-Detektion. Wenn man da mal in
kurzer Zeit ein paar mehr Mails versendet, landet man schnell mal auf
einer Blacklist.
> Soweit mir bekannt speichert die Telekom den Hashwert
> des Passwortes.
Ja, und?
Marcel
> Zitat der Telekom per Brief:
> "Von Hinweisgebern haben wir Informationen erhalten,
> dass über Ihren Internetzugang Spam- oder
> Phishing-Mails versendet wurden."
>
> Ein Ändern des E-Mail-Passwortes und des Web-Passwortes
> zur betroffenen E-Mail-Adresse ist erforderlich, um
> weiterhin E-Mails versenden zu können.
>
> Was ist da geschehen?
> dass über Ihren Internetzugang Spam- oder
> Phishing-Mails versendet wurden."
>
> Ein Ändern des E-Mail-Passwortes und des Web-Passwortes
> zur betroffenen E-Mail-Adresse ist erforderlich, um
> weiterhin E-Mails versenden zu können.
>
Ich würde sagen Phishing-Mail.
Wären wirklich größere Mengen Spam über den Account versendet worden,
würde Passwort ändern den infizierten Rechner sicher auch nicht säubern. ;-)
Allerdings hat die Telekom tatsächlich zuweilen ziemlich niedrige
Schwellen für die automatische Missbrauch-Detektion. Wenn man da mal in
kurzer Zeit ein paar mehr Mails versendet, landet man schnell mal auf
einer Blacklist.
> Soweit mir bekannt speichert die Telekom den Hashwert
> des Passwortes.
Marcel
Wendelin Uez
Sep 30, 2022, 10:53:22 AM9/30/22
to
> Bei einem Invaliden mit ~20 Jahre altem NUA keine Seltenheit.
patentieren lassen.
Peter J. Holzer
Sep 30, 2022, 12:20:54 PM9/30/22
to
On 2022-09-29 17:05, Wendelin Uez <wu...@online.de> wrote:
>> Bei einem Invaliden mit ~20 Jahre altem NUA keine Seltenheit.
>
> Den TO anhand seines NUA als Invaliden zu diagnostizieren
Das hat sich ziemlich sicher auf die E-Mail-Adresse bezogen, nicht auf
>> Bei einem Invaliden mit ~20 Jahre altem NUA keine Seltenheit.
>
> Den TO anhand seines NUA als Invaliden zu diagnostizieren
den NUA.
> solltest du dir patentieren lassen.
hp
Marco Moock
Oct 5, 2022, 3:07:37 AM10/5/22
to
Am 01.10.2022 um 01:09:24 Uhr schrieb Martin Gerdes:
> Wenn die Folgeversion(en) besser ist (sind) und das
> Preis/Aufwand/Leistungsverhältnis paßt, werden die Leute schon
> upgraden.
>
> Neuheit ist kein Wert an sich.
Sicherheit aber vielleicht schon.
Dazu kommt, dass sich die IT-Welt weiterdreht und manche Dinge wie TLS
sich über die Jahre ändern.
> Wenn die Folgeversion(en) besser ist (sind) und das
> Preis/Aufwand/Leistungsverhältnis paßt, werden die Leute schon
> upgraden.
>
> Neuheit ist kein Wert an sich.
Sicherheit aber vielleicht schon.
Dazu kommt, dass sich die IT-Welt weiterdreht und manche Dinge wie TLS
sich über die Jahre ändern.
Marco Moock
Oct 5, 2022, 5:21:49 AM10/5/22
to
Am 05.10.2022 um 10:57:14 Uhr schrieb Volker Delf:
> Das Totschlagargument "Sicherheit" muss für vieles herhalten. Worin
> besteht denn hier konkret beim NUA die "Unsicherheit"?
Es gibt MUAs und NUAs, die automatisch Dateianhänge öffnen bzw. bei
bestimmten Dateianhängen Sicherheitsprobleme hatten. Ich habe da
Outlook in Erinnerung.
Dazu kommt, dass ältere Software oft nicht die aktuellen
Verschlüsselungsprotokolle unterstützt.
> Das Totschlagargument "Sicherheit" muss für vieles herhalten. Worin
> besteht denn hier konkret beim NUA die "Unsicherheit"?
Es gibt MUAs und NUAs, die automatisch Dateianhänge öffnen bzw. bei
bestimmten Dateianhängen Sicherheitsprobleme hatten. Ich habe da
Outlook in Erinnerung.
Dazu kommt, dass ältere Software oft nicht die aktuellen
Verschlüsselungsprotokolle unterstützt.
Wendelin Uez
Oct 5, 2022, 7:50:25 AM10/5/22
to
> Es gibt MUAs und NUAs, die automatisch Dateianhänge öffnen bzw. bei
> bestimmten Dateianhängen Sicherheitsprobleme hatten. Ich habe da
> Outlook in Erinnerung.
Da mein uralter Newsreader diesen Unsinn nicht macht, wohl aber manch
> bestimmten Dateianhängen Sicherheitsprobleme hatten. Ich habe da
> Outlook in Erinnerung.
aktuelles Produkt, spricht das eigentlich formal eher gegen die Verwendung
neuer Produkte.
> Dazu kommt, dass ältere Software oft nicht die aktuellen
> Verschlüsselungsprotokolle unterstützt.
Marcel Logen
Oct 5, 2022, 8:03:38 AM10/5/22
to
Wendelin Uez in de.comp.security.misc:
>>Dazu kommt, dass ältere Software oft nicht die aktuellen
>>Verschlüsselungsprotokolle unterstützt.
>
>Wer braucht in NGs Verschlüsselungsprotokolle, insbesondere aktuelle?
Willst Du Dein Passwort nicht schützen?
Marcel
--
╭──╮ ╭──╮ ╭───────╮ ..51..╭─────╮ ╭───╮
│ │ │ ╰───╮ ╰─────╮ ╰─────╮ ..51..╰───╮ ╰─╯ ╰───
╭──╯ ╰───╯ ╭───╯ ╭─╮ │ ╭─╯ ╭───╮ ╭───╯ ..67..
╭─╯ ╰─────╯ ╰────╯ ╰─────╯ ╰───────────╯ ..67..
>>Dazu kommt, dass ältere Software oft nicht die aktuellen
>>Verschlüsselungsprotokolle unterstützt.
>
>Wer braucht in NGs Verschlüsselungsprotokolle, insbesondere aktuelle?
Marcel
--
╭──╮ ╭──╮ ╭───────╮ ..51..╭─────╮ ╭───╮
│ │ │ ╰───╮ ╰─────╮ ╰─────╮ ..51..╰───╮ ╰─╯ ╰───
╭──╯ ╰───╯ ╭───╯ ╭─╮ │ ╭─╯ ╭───╮ ╭───╯ ..67..
╭─╯ ╰─────╯ ╰────╯ ╰─────╯ ╰───────────╯ ..67..
Marco Moock
Oct 5, 2022, 8:19:46 AM10/5/22
to
Am 05.10.2022 um 13:50:10 Uhr schrieb Wendelin Uez:
> Wer braucht in NGs Verschlüsselungsprotokolle, insbesondere aktuelle?
Wenn du dich anmeldest, wird das Kennwort übertragen. Ich habe es gerne
> Wer braucht in NGs Verschlüsselungsprotokolle, insbesondere aktuelle?
so, dass man das nicht einfach so mitschneiden kann.
Marco Moock
Oct 6, 2022, 2:19:52 PM10/6/22
to
Am 06.10.2022 um 00:07:32 Uhr schrieb Martin Gerdes:
> Ja, ja, die Männchen im Keller, die Paßwörter mitschneiden!
> Von denen hat Bernd Leptihn selig schon Mitte der 90er in seinem
> "Ratgeber Technik" gewarnt.
Sowas kann problemlos automatisiert ablaufen und später von jemandem
ggf. genutzt werden, um Unfug damit zu machen und es dir in die Schuhe
zu schieben. Ich gehe da auf Nummer (weitgehend) sicher und nutze TLS,
denn es ist für mich kein wirklicher Aufwand.
> Ja, ja, die Männchen im Keller, die Paßwörter mitschneiden!
> Von denen hat Bernd Leptihn selig schon Mitte der 90er in seinem
> "Ratgeber Technik" gewarnt.
Sowas kann problemlos automatisiert ablaufen und später von jemandem
ggf. genutzt werden, um Unfug damit zu machen und es dir in die Schuhe
zu schieben. Ich gehe da auf Nummer (weitgehend) sicher und nutze TLS,
denn es ist für mich kein wirklicher Aufwand.
Marco Moock
Oct 6, 2022, 2:20:27 PM10/6/22
to
Am 06.10.2022 um 00:07:32 Uhr schrieb Martin Gerdes:
> Warum sollte man eine "Altsoftware" nicht verwenden, solange sie die
> Anforderungen erfüllt?
Solange sie die Sicherheitsanforderungen erfüllt, kann man das tun.
Solange sie das nicht mehr tut, ist davon dringend abzuraten.
Lars Gebauer
Oct 7, 2022, 3:06:14 AM10/7/22
to
Am 07.10.2022 um 01:55 schrieb Martin Gerdes:
> Marco Moock <mo...@posteo.de> schrieb:
> interessant genug ist, daß man ihn hackt.
"Man" vielleicht nicht. Aber was ist mit der 13-jährigen computeraffinen
Rotzgöre aus der Nachbarschaft, die aus unerfindlichen Gründen einen
Rochus auf Dich hat? Oder die einfach nur das Crash-Kid "Weil ich es
kann!" gibt?
> Da ist vermutlich schon mein
> Mailzugang erheblich kritischer wichtiger, geschweige denn irgendein
> Kontozugang.
Das kommt dann noch hinzu.
--
"Das Problem ist nicht, dass eine relativ kleine Gruppe von Verrückten
behauptet, dass zwei plus zwei fünf ergibt, dass es zwölf verschiedene
Geschlechter gibt oder dass man bei der Energieversorgung die Gesetze
der Thermodynamik ignorieren kann. Das Problem ist, daß sich die große
Gruppe der Normalos künstlich dumm stellt und den selben Quatsch
behauptet, weil sie von den Verrückten nicht als verrückt bezeichnet
werden wollen."
--Vince Ebert
> Marco Moock <mo...@posteo.de> schrieb:
>>> Ja, ja, die Männchen im Keller, die Paßwörter mitschneiden!
>>> Von denen hat Bernd Leptihn selig schon Mitte der 90er in seinem
>>> "Ratgeber Technik" gewarnt.
>
>> Sowas kann problemlos automatisiert ablaufen und später von jemandem
>> ggf. genutzt werden, um Unfug damit zu machen und es dir in die Schuhe
>> zu schieben.
>
> Fragt sich halt, ob der Newszugang eines kleinen Lichts wie mir
>>> Von denen hat Bernd Leptihn selig schon Mitte der 90er in seinem
>>> "Ratgeber Technik" gewarnt.
>
>> Sowas kann problemlos automatisiert ablaufen und später von jemandem
>> ggf. genutzt werden, um Unfug damit zu machen und es dir in die Schuhe
>> zu schieben.
>
> interessant genug ist, daß man ihn hackt.
"Man" vielleicht nicht. Aber was ist mit der 13-jährigen computeraffinen
Rotzgöre aus der Nachbarschaft, die aus unerfindlichen Gründen einen
Rochus auf Dich hat? Oder die einfach nur das Crash-Kid "Weil ich es
kann!" gibt?
> Da ist vermutlich schon mein
> Mailzugang erheblich kritischer wichtiger, geschweige denn irgendein
> Kontozugang.
Das kommt dann noch hinzu.
--
"Das Problem ist nicht, dass eine relativ kleine Gruppe von Verrückten
behauptet, dass zwei plus zwei fünf ergibt, dass es zwölf verschiedene
Geschlechter gibt oder dass man bei der Energieversorgung die Gesetze
der Thermodynamik ignorieren kann. Das Problem ist, daß sich die große
Gruppe der Normalos künstlich dumm stellt und den selben Quatsch
behauptet, weil sie von den Verrückten nicht als verrückt bezeichnet
werden wollen."
--Vince Ebert
Wendelin Uez
Oct 9, 2022, 5:17:41 AM10/9/22
to
>>Wer braucht in NGs Verschlüsselungsprotokolle, insbesondere aktuelle?
>
> Willst Du Dein Passwort nicht schützen?
Das Paßwort für meinen NG-Provider schützt fast gar nichts, der Provider
>
> Willst Du Dein Passwort nicht schützen?
fordert auch weder neue Protokolle noch weiß ich, ob er sie überhaupt
unterstützt. Das ist mir für einen Softwarewechsel zu wenig.
Marco Moock
Oct 9, 2022, 5:23:09 AM10/9/22
to
darüber Spam posten kann. Ein Betreiber hat das Interesse, Missbrauch
auf einen User zurückzuführen (und den zu sperren) und damit auch das
Interesse, dass Zugangsdaten nicht Dritten zugänglich sind.
Marco Moock
Oct 9, 2022, 2:48:04 PM10/9/22
to
Am 09.10.2022 um 14:38:23 Uhr schrieb Andreas Kohlbach:
> Denn auch bei anderen Providern ist das heute (2022) noch so.
Bei welchem denn?
SMTP-Auth ist mehr als 20 Jahre verfügbar in den Servern und die
Clients können das auch.
> Denn auch bei anderen Providern ist das heute (2022) noch so.
Bei welchem denn?
SMTP-Auth ist mehr als 20 Jahre verfügbar in den Servern und die
Clients können das auch.
Arno Welzel
Oct 9, 2022, 3:06:18 PM10/9/22
to
Wendelin Uez, 2022-09-29 19:05:
>
>> Bei einem Invaliden mit ~20 Jahre altem NUA keine Seltenheit.
>
> Den TO anhand seines NUA als Invaliden zu diagnostizieren solltest du dir
> patentieren lassen.
Das war auf die Absenderadresse "nop...@ist.invalid" bezogen und die
Angabe "Forte Agent 1.93/32.576" im Header.
--
Arno Welzel
https://arnowelzel.de
>
>> Bei einem Invaliden mit ~20 Jahre altem NUA keine Seltenheit.
>
> Den TO anhand seines NUA als Invaliden zu diagnostizieren solltest du dir
> patentieren lassen.
Angabe "Forte Agent 1.93/32.576" im Header.
--
Arno Welzel
https://arnowelzel.de
Arno Welzel
Oct 9, 2022, 3:10:26 PM10/9/22
to
Andreas Kohlbach, 2022-10-09 20:38:
[...]
> Ich erinnere mich an die frühen 2000er, wo man, wenn ein öffentliches
> WIFI über T-Online ging, man einfach so Mail versenden konnte. Also jeder
> Hinz und Kunz, der gerade verbunden war.
Ich erinner mich daran nicht. Man musste immer zuerst POP3 machen, bevor
man über die selbe IP-Adresse etwas via SMTP senden durfte. Aber SMTP
AUTH war auch in den 2000ern schon bekannt.
> Denn auch bei anderen Providern ist das heute (2022) noch so.
Welche konkret? Ich kenne keinen, der das erlaubt.
[...]
> Ich erinnere mich an die frühen 2000er, wo man, wenn ein öffentliches
> WIFI über T-Online ging, man einfach so Mail versenden konnte. Also jeder
> Hinz und Kunz, der gerade verbunden war.
Ich erinner mich daran nicht. Man musste immer zuerst POP3 machen, bevor
man über die selbe IP-Adresse etwas via SMTP senden durfte. Aber SMTP
AUTH war auch in den 2000ern schon bekannt.
> Denn auch bei anderen Providern ist das heute (2022) noch so.
Georg Schwarz
Oct 16, 2022, 4:10:06 PM10/16/22
to
Volker Delf <nop...@ist.invalid> wrote:
> Zitat der Telekom per Brief:
> "Von Hinweisgebern haben wir Informationen erhalten,
> dass über Ihren Internetzugang Spam- oder
> Phishing-Mails versendet wurden."
ich würde die Telekom bitten, mir nähere Informationen zu nennen, falls
> Zitat der Telekom per Brief:
> "Von Hinweisgebern haben wir Informationen erhalten,
> dass über Ihren Internetzugang Spam- oder
> Phishing-Mails versendet wurden."
diese nicht sowieso schon im Schreiben drinstehen, also insbesondere
wann der Versandzeitpunkt gewesen sein soll, über welchen Weg, in
welchem Umfang.
Dann kann man weitersehen.
Ich hatte vor vielen Jahren auch so eine Meldung von der Telekom, und
letztlich kam heraus, dass die Telekom wohl etwas bei der Zuordnung
dynamischer IPs/Zeiten falsch gemacht haben muss.
Marco Moock
Oct 18, 2022, 3:50:44 AM10/18/22
to
Am 18.10.2022 um 09:40:57 Uhr schrieb Volker Delf:
> Merkwürdig ist jedenfalls, dass kurz vor dem Ereignis bis heute
> täglich ein bis zwei Spam E-Mails zur betroffenen E-Mail Adresse
> eintreffen:
>
> Return-Path: <bounces+meinName=t-onl...@mailer.humblebundle.com>
> From: "Humble Bundle" <con...@mailer.humblebundle.com>
>
> meinName ist meine E-Mail-Adresse vor @.
Dann prüfe bitte die Header und schaue, welche MTAs beteiligt sind. In
From: kann ALLES reingeschrieben werden.
> Merkwürdig ist jedenfalls, dass kurz vor dem Ereignis bis heute
> täglich ein bis zwei Spam E-Mails zur betroffenen E-Mail Adresse
> eintreffen:
>
> Return-Path: <bounces+meinName=t-onl...@mailer.humblebundle.com>
> From: "Humble Bundle" <con...@mailer.humblebundle.com>
>
> meinName ist meine E-Mail-Adresse vor @.
Dann prüfe bitte die Header und schaue, welche MTAs beteiligt sind. In
From: kann ALLES reingeschrieben werden.
Marco Moock
Oct 18, 2022, 10:38:51 AM10/18/22
to
Am 18.10.2022 um 16:31:54 Uhr schrieb Volker Delf:
> Received: from mta-88-229.sparkpostmail.com ([192.174.88.229]) by
> mailin71.mgt.mul.t-online.de
Mit hoher Wahrscheinlichkeit halt Spam.
SPF würde nicht zu mailer.humblebundle.com passen. Wobei das auch der
From: und nicht MAIL FROM: ist, der unterschiedlich sein könnte.
> Received: from mta-88-229.sparkpostmail.com ([192.174.88.229]) by
> mailin71.mgt.mul.t-online.de
Mit hoher Wahrscheinlichkeit halt Spam.
SPF würde nicht zu mailer.humblebundle.com passen. Wobei das auch der
From: und nicht MAIL FROM: ist, der unterschiedlich sein könnte.
Laurenz Trossel
Oct 18, 2022, 1:23:21 PM10/18/22
to
mailer.humblebundle.com. 300 IN TXT "v=spf1 include:spf.cordial.io -all"
spf.cordial.io. 300 IN TXT "v=spf1 include:spf.dynect.net exists:%{i}._spf.e.sparkpost.com ~all"
192.174.88.229._spf.e.sparkpost.com. 3600 IN A 192.174.88.229
Das sieht nach legitimer Mail von Humble Bundle aus.
Marco Moock
Oct 18, 2022, 2:12:47 PM10/18/22
to
Am 18.10.2022 um 17:23:20 Uhr schrieb Laurenz Trossel:
> mailer.humblebundle.com. 300 IN TXT "v=spf1
> include:spf.cordial.io -all" spf.cordial.io.
> 300 IN TXT "v=spf1 include:spf.dynect.net
> exists:%{i}._spf.e.sparkpost.com ~all"
> 192.174.88.229._spf.e.sparkpost.com. 3600 IN A 192.174.88.229
>
> Das sieht nach legitimer Mail von Humble Bundle aus.
Mist, ich habe _spf.e.sparkpost.com vergessen.
> mailer.humblebundle.com. 300 IN TXT "v=spf1
> include:spf.cordial.io -all" spf.cordial.io.
> 300 IN TXT "v=spf1 include:spf.dynect.net
> exists:%{i}._spf.e.sparkpost.com ~all"
> 192.174.88.229._spf.e.sparkpost.com. 3600 IN A 192.174.88.229
>
> Das sieht nach legitimer Mail von Humble Bundle aus.
Marco Moock
Oct 22, 2022, 6:38:46 AM10/22/22
to
Am 22.10.2022 um 12:23:31 Uhr schrieb Volker Delf:
> Sie verwenden das gleiche Passwort auch auf anderen
> Internet-Portalen?
> Dann ändern Sie am besten bitte auch die Passwörter..."
>
>
> Somit bin ich beschäftigt, diese Portale zu finden,
> wenn das die Ursache des Missbrauchs meiner Login-Daten war.
Niemals das gleiche Passwort für mehrere Dienste nehmen. Ist einer
gehackt, kann damit mit deinen Zugangsdaten ein anderer missbraucht
werden.
> Sie verwenden das gleiche Passwort auch auf anderen
> Internet-Portalen?
> Dann ändern Sie am besten bitte auch die Passwörter..."
>
>
> Somit bin ich beschäftigt, diese Portale zu finden,
> wenn das die Ursache des Missbrauchs meiner Login-Daten war.
Niemals das gleiche Passwort für mehrere Dienste nehmen. Ist einer
gehackt, kann damit mit deinen Zugangsdaten ein anderer missbraucht
werden.
Jens Schüßler
Oct 22, 2022, 3:40:04 PM10/22/22
to
* Volker Delf <nop...@ist.invalid> [22-10-22 10:23]:
>
> Eine weitere E-Mail von dem Telekom Sicherheitsteam <ab...@telekom.de>
> Aufgefordert wurde darin, das FTP-Passwort zu ändern.
>
Bist du dir eigentlich sicher das diese Mails wirklich von der Telekom
stammen?
Für mich riecht das alles dezent nach Phishing Mails.
https://www.telekom.de/hilfe/festnetz-internet-tv/sicherheit/missbrauch-von-diensten/informationen-zur-sicherheitswarnung/merkmale-sicherheitshinweis
>
> Eine weitere E-Mail von dem Telekom Sicherheitsteam <ab...@telekom.de>
> Aufgefordert wurde darin, das FTP-Passwort zu ändern.
>
Bist du dir eigentlich sicher das diese Mails wirklich von der Telekom
stammen?
Für mich riecht das alles dezent nach Phishing Mails.
https://www.telekom.de/hilfe/festnetz-internet-tv/sicherheit/missbrauch-von-diensten/informationen-zur-sicherheitswarnung/merkmale-sicherheitshinweis
Peter J. Holzer
Oct 22, 2022, 5:49:48 PM10/22/22
to
On 2022-10-22 19:26, Jens Schüßler <j.sc...@nurfuerspam.de> wrote:
> * Volker Delf <nop...@ist.invalid> [22-10-22 10:23]:
>> Eine weitere E-Mail von dem Telekom Sicherheitsteam <ab...@telekom.de>
>> Aufgefordert wurde darin, das FTP-Passwort zu ändern.
>>
>
> Bist du dir eigentlich sicher das diese Mails wirklich von der Telekom
> stammen?
Wenn ich mich recht erinnere, war Volker bereits deswegen mit der
> * Volker Delf <nop...@ist.invalid> [22-10-22 10:23]:
>> Eine weitere E-Mail von dem Telekom Sicherheitsteam <ab...@telekom.de>
>> Aufgefordert wurde darin, das FTP-Passwort zu ändern.
>>
>
> Bist du dir eigentlich sicher das diese Mails wirklich von der Telekom
> stammen?
Telekom in Kontakt.
> Für mich riecht das alles dezent nach Phishing Mails.
> https://www.telekom.de/hilfe/festnetz-internet-tv/sicherheit/missbrauch-von-diensten/informationen-zur-sicherheitswarnung/merkmale-sicherheitshinweis
| ...
| Jede E-Mail des Telekom Sicherheitsteams ist mit einem blauen @-Symbol versehen.
Was genau hindert einen Scammer, ein blaues @-Symbol in eine Mail zu
pflanzen?
hp
Jens Schüßler
Oct 22, 2022, 8:20:05 PM10/22/22
to
* Peter J. Holzer <hjp-u...@hjp.at> [22-10-22 21:49]:
Vermutlich nichts. Aber wundert nicht bei der Telekom.
Peter J. Holzer
Oct 23, 2022, 2:54:27 AM10/23/22
to
On 2022-10-22 21:49, Peter J. Holzer <hjp-u...@hjp.at> wrote:
> On 2022-10-22 19:26, Jens Schüßler <j.sc...@nurfuerspam.de> wrote:
>> Für mich riecht das alles dezent nach Phishing Mails.
>> https://www.telekom.de/hilfe/festnetz-internet-tv/sicherheit/missbrauch-von-diensten/informationen-zur-sicherheitswarnung/merkmale-sicherheitshinweis
>
>| Sie erkennen die Echtheit der E-Mail im E-Mail Center anhand des Siegels.
^^^^^^^^^^^^^^^^
> On 2022-10-22 19:26, Jens Schüßler <j.sc...@nurfuerspam.de> wrote:
>> Für mich riecht das alles dezent nach Phishing Mails.
>> https://www.telekom.de/hilfe/festnetz-internet-tv/sicherheit/missbrauch-von-diensten/informationen-zur-sicherheitswarnung/merkmale-sicherheitshinweis
>
>| Sie erkennen die Echtheit der E-Mail im E-Mail Center anhand des Siegels.
>| ...
>| Jede E-Mail des Telekom Sicherheitsteams ist mit einem blauen @-Symbol versehen.
>
> Was genau hindert einen Scammer, ein blaues @-Symbol in eine Mail zu
> pflanzen?
Mir fällt gerade auf, dass man die Echtheit "im E-Mail Center" erkennt.
>| Jede E-Mail des Telekom Sicherheitsteams ist mit einem blauen @-Symbol versehen.
>
> Was genau hindert einen Scammer, ein blaues @-Symbol in eine Mail zu
> pflanzen?
Ich nehme an, das ist deren Webmailer. Der kann vermutlich Mails von der
eigenen Organisation erkennen und markieren.
hp
Marcel Logen
Oct 23, 2022, 11:58:24 AM10/23/22
to
Peter J. Holzer in de.comp.security.misc:
Es ist deren Webmailer, ja.
Die Mails sind AFAIK von der Telekom entsprechend signiert
(DKIM). Und dann erscheint eben dieses blaue "@".
Marcel
--
╭─────╮ ╭─╮ ╭─────╮ ╭────╮ ╭─╮..55..╭─────╮ ╭──╮
...2..╭──╮ ╰─╮ ╰─╯ ╰──╮ ╰───╮ ╰──╮ │ ╭─╯ │ ╰───╮ │ │ │ │
│ ╰─╮ │ ..19..╭─╯ ╭──╮ │ ╰──╯ ╰─────╯ ╭──╯ ╰─╮ ╰─╯ ╰
╭──────╯ ╰──╯ ╰───╯ ╰──╯ ╰───────╯ ..67..
Die Mails sind AFAIK von der Telekom entsprechend signiert
(DKIM). Und dann erscheint eben dieses blaue "@".
Marcel
--
╭─────╮ ╭─╮ ╭─────╮ ╭────╮ ╭─╮..55..╭─────╮ ╭──╮
...2..╭──╮ ╰─╮ ╰─╯ ╰──╮ ╰───╮ ╰──╮ │ ╭─╯ │ ╰───╮ │ │ │ │
│ ╰─╮ │ ..19..╭─╯ ╭──╮ │ ╰──╯ ╰─────╯ ╭──╯ ╰─╮ ╰─╯ ╰
╭──────╯ ╰──╯ ╰───╯ ╰──╯ ╰───────╯ ..67..
Marcel Logen
Oct 24, 2022, 6:25:21 AM10/24/22
to
Volker Delf in de.comp.security.misc:
>Marcel Logen schrieb:
>>Die Mails sind AFAIK von der Telekom entsprechend signiert
>>(DKIM). Und dann erscheint eben dieses blaue "@".
>>
>Welches E-Mail Programm prüft denn die DKIM-Signature in den Kopfdaten?
Mir ist leider momentan keines bekannt.
Meist wird das wohl von den MTA gemacht, dann erscheint eine
entsprechende Zeile im Header:
| Authentication-Results: mailin75.aul.t-online.de;
| dkim=pass (2048-bit key; unprotected) header.d=telekom.de header.i=@telekom.de header.b=dmkLP/Lr;
| dkim-atps=neutral
Gestern abend habe ich anläßlich dieses Threads mal wieder die
DKIM-Signatur einer Rechnungsmail von der Telekom manuell über-
prüft. Das geht z. B. mit Unix-Tools in Verbindung mit OpenSSL,
ist aber etwas umständlich. Das Verfahren ist in RFC6376 be-
schrieben.
<https://www.rfc-editor.org/rfc/rfc6376>,
siehe insbes. die Abschnitte 3.7, 3.4.2 (3.4.5).
Marcel
--
╭──────╮ ╭───────╮ ╭─╮ ╭───────╮ ..60..╭──────
╰─╮ ╰─╮ │ │ │ ╰──╯ ╭────╯ ╭─╮ │..67..
╮ ╭──╯ ╭───╯ ╭────╯ │ ╭─╮ ╭──╯ │ ╭──╮ ╭─╮ │ ╰──╯..67..
╰──╯ ╰──────╯ ╰──╯ ╰─╯ ╰─╯ ╰───╯ ╰─╯ ..67..
>Marcel Logen schrieb:
>>Die Mails sind AFAIK von der Telekom entsprechend signiert
>>(DKIM). Und dann erscheint eben dieses blaue "@".
>>
Mir ist leider momentan keines bekannt.
Meist wird das wohl von den MTA gemacht, dann erscheint eine
entsprechende Zeile im Header:
| Authentication-Results: mailin75.aul.t-online.de;
| dkim=pass (2048-bit key; unprotected) header.d=telekom.de header.i=@telekom.de header.b=dmkLP/Lr;
| dkim-atps=neutral
Gestern abend habe ich anläßlich dieses Threads mal wieder die
DKIM-Signatur einer Rechnungsmail von der Telekom manuell über-
prüft. Das geht z. B. mit Unix-Tools in Verbindung mit OpenSSL,
ist aber etwas umständlich. Das Verfahren ist in RFC6376 be-
schrieben.
<https://www.rfc-editor.org/rfc/rfc6376>,
siehe insbes. die Abschnitte 3.7, 3.4.2 (3.4.5).
Marcel
--
╭──────╮ ╭───────╮ ╭─╮ ╭───────╮ ..60..╭──────
╰─╮ ╰─╮ │ │ │ ╰──╯ ╭────╯ ╭─╮ │..67..
╮ ╭──╯ ╭───╯ ╭────╯ │ ╭─╮ ╭──╯ │ ╭──╮ ╭─╮ │ ╰──╯..67..
╰──╯ ╰──────╯ ╰──╯ ╰─╯ ╰─╯ ╰───╯ ╰─╯ ..67..
Peter J. Holzer
Oct 24, 2022, 4:26:10 PM10/24/22
to
On 2022-10-24 09:10, Volker Delf <nop...@ist.invalid> wrote:
> Marcel Logen schrieb:
(Wobei eine gültige DKIM-Signature natürlich nicht aussagt, dass die
Mail von der Telekom stammt. Wenn das blaue @ also nur bedeutet, dass
die DKIM-Signature korrekt ist, dann muss der User noch andere Daten
überprüfen.)
hp
> Marcel Logen schrieb:
>>Die Mails sind AFAIK von der Telekom entsprechend signiert
>>(DKIM). Und dann erscheint eben dieses blaue "@".
>>
>>(DKIM). Und dann erscheint eben dieses blaue "@".
>>
> Welches E-Mail Programm prüft denn die DKIM-Signature in den Kopfdaten?
Offenbar der Webmailer der Telekom.
(Wobei eine gültige DKIM-Signature natürlich nicht aussagt, dass die
Mail von der Telekom stammt. Wenn das blaue @ also nur bedeutet, dass
die DKIM-Signature korrekt ist, dann muss der User noch andere Daten
überprüfen.)
hp
Marcel Logen
Oct 26, 2022, 11:08:03 AM10/26/22
to
Peter J. Holzer in de.comp.security.misc:
>On 2022-10-24 09:10, Volker Delf <nop...@ist.invalid> wrote:
>> Marcel Logen schrieb:
>>>Die Mails sind AFAIK von der Telekom entsprechend signiert
>>>(DKIM). Und dann erscheint eben dieses blaue "@".
Siehe hierzu meine Nachfrage bei "Telekom hilft":
>> Marcel Logen schrieb:
>>>Die Mails sind AFAIK von der Telekom entsprechend signiert
>>>(DKIM). Und dann erscheint eben dieses blaue "@".
<https://telekomhilft.telekom.de/t5/E-Mail-Center/eMail-Siegel-blaues-quot-quot/td-p/5910983>
<https://telekomhilft.telekom.de/t5/E-Mail-Center/eMail-Siegel-blaues-quot-quot/td-p/5910983/page/2#answers>
>> Welches E-Mail Programm prüft denn die DKIM-Signature in den Kopfdaten?
>
>Offenbar der Webmailer der Telekom.
Programme gezählt.
>(Wobei eine gültige DKIM-Signature natürlich nicht aussagt, dass die
>Mail von der Telekom stammt. Wenn das blaue @ also nur bedeutet, dass
>die DKIM-Signature korrekt ist, dann muss der User noch andere Daten
>überprüfen.)
führt, sollte man doch sicher sein. Oder mißverstehe ich
da etwas?
Marcel
--
╭────╮ ╭───╮ ╭──╮ ╭──╮ ╭──╮ ╭───╮ ╭─────╮ ╭──╮ ..67..
╭──╯ ╭─╯ ╰─╮ ╰─╯ ╰──╯ ╰─╯ ╰─╮ │ ╰─╯ ╭──╯ ╭─╯ ╰─╮ ..67..
│ ╭─╯ ╭──╯ ..20..╭─────────╯ ╰────╮ ╰────╯ ╭───╯ ╭───────╮
──╯ ╰─────╯ ╰─────────────────╯ ╰─────╯ ..64..╰──
Peter J. Holzer
Oct 26, 2022, 1:50:38 PM10/26/22
to
On 2022-10-26 15:08, Marcel Logen <33320000...@ybtra.de> wrote:
> Peter J. Holzer in de.comp.security.misc:
>>On 2022-10-24 09:10, Volker Delf <nop...@ist.invalid> wrote:
>>> Marcel Logen schrieb:
>>>>Die Mails sind AFAIK von der Telekom entsprechend signiert
>>>>(DKIM). Und dann erscheint eben dieses blaue "@".
>
> Siehe hierzu meine Nachfrage bei "Telekom hilft":
>
><https://telekomhilft.telekom.de/t5/E-Mail-Center/eMail-Siegel-blaues-quot-quot/td-p/5910983>
><https://telekomhilft.telekom.de/t5/E-Mail-Center/eMail-Siegel-blaues-quot-quot/td-p/5910983/page/2#answers>
>
>>> Welches E-Mail Programm prüft denn die DKIM-Signature in den Kopfdaten?
>>
>>Offenbar der Webmailer der Telekom.
>
> Einen Webmailer hatte ich jetzt nicht unter die eMail-
> Programme gezählt.
Jetzt bin ich etwas verwirrt. Hast nicht du das blaue @ in die
> Peter J. Holzer in de.comp.security.misc:
>>On 2022-10-24 09:10, Volker Delf <nop...@ist.invalid> wrote:
>>> Marcel Logen schrieb:
>>>>Die Mails sind AFAIK von der Telekom entsprechend signiert
>>>>(DKIM). Und dann erscheint eben dieses blaue "@".
>
> Siehe hierzu meine Nachfrage bei "Telekom hilft":
>
><https://telekomhilft.telekom.de/t5/E-Mail-Center/eMail-Siegel-blaues-quot-quot/td-p/5910983>
><https://telekomhilft.telekom.de/t5/E-Mail-Center/eMail-Siegel-blaues-quot-quot/td-p/5910983/page/2#answers>
>
>>> Welches E-Mail Programm prüft denn die DKIM-Signature in den Kopfdaten?
>>
>>Offenbar der Webmailer der Telekom.
>
> Einen Webmailer hatte ich jetzt nicht unter die eMail-
> Programme gezählt.
Diskussion eingebracht?
>>(Wobei eine gültige DKIM-Signature natürlich nicht aussagt, dass die
>>Mail von der Telekom stammt. Wenn das blaue @ also nur bedeutet, dass
>>die DKIM-Signature korrekt ist, dann muss der User noch andere Daten
>>überprüfen.)
>
> Hm, welche denn? Wenn man alle Schritte aus RFC6376 aus-
> führt, sollte man doch sicher sein. Oder mißverstehe ich
> da etwas?
eine gültige DKIM-Signature nicht aus, dass eine Mail von der Telekom
kommt, sondern dass die Mail von einem Provider kommt, der seine
ausgehenden Mails signiert und dass die signierten Teile der Mail nicht
unterwegs geändert wurden. Wenn ich den Account "telekomsupport" bei
Gmail anlege und dann Mails über Gmail als telekom...@gmail.com
versende, haben die eine gültige Signatur.
2. Ich kann auch selber einen Mail-Server aufsetzen, der Mails
DKIM-signiert und habe dann volle Kontrolle darüber, was ich signiere.
Ich kann dann z.B. auch "From: <sup...@telekom.de>" signieren.
Auch das wäre eine gültige DKIM-Signatur.
Zusätzlich zur Gültigkeit der Signatur muss man also überprüfen:
* Wer hat die Mail signiert? Wenn die Mail angeblich vom Support-Team
der Telekom stammt, sollte das die Telekom selbst sein. Gehört die d=
Domain der Telekom, und wenn ja, ist das die Domain, die die Telekom
üblicherweise für DKIM-Signaturen verwendet?
* Welche Teile der Mail wurden überhaupt signiert? Normalerweise ist da
der From-Header (der uns hier interessiert) dabei, aber streng
genommen darf man sich auch darauf nicht verlassen.
* Ist die Absender-Adresse die richtige?
hp
Peter J. Holzer
Oct 27, 2022, 11:03:35 AM10/27/22
to
On 2022-10-27 12:05, Christian @Soemtron <christian...@soemtron.de> wrote:
> GMX-Postfach gemacht. Dies sind die regelmäßig vorkommenden Header:
[...]
> Mail 2:
> Authentication-Results: gmx.net; dkim=pass header.i=@domain.tld
> Authentication-Results: gmx.net; dkim=fail header.i=@domain.tld
[...]
> Allesamt Mails, die garantiert echt und von seriösen Absendern sind.
> Irgendeinen Nutzen kann ich da nicht erkennen. Besonders #2 ist drollig.
Eine derartige Überprüfung können natürlich mehrere MTAs am Weg machen.
Und die können zu unterschiedlichen Ergebnissen kommen (wobei ich
"zuerst fail und dann pass" auch etwas überraschend finde. Aber da Du
den ganzen Kontext weggelassen und die Domainnamen zensiert hast, kann
man über die Ursache nicht einmal spekulieren).
hp
> Marcel Logen <33320000...@ybtra.de> schrieb:
>> Meist wird das wohl von den MTA gemacht, dann erscheint eine
>> entsprechende Zeile im Header:
>
>> | Authentication-Results: mailin75.aul.t-online.de;
>> | dkim=pass (2048-bit key; unprotected) header.d=telekom.de
>> header.i=@telekom.de header.b=dmkLP/Lr;
>> | dkim-atps=neutral
>
> Habe ich bisher nie beachtet und gerade mal eine Stichprobe in meinem
>> Meist wird das wohl von den MTA gemacht, dann erscheint eine
>> entsprechende Zeile im Header:
>
>> | Authentication-Results: mailin75.aul.t-online.de;
>> | dkim=pass (2048-bit key; unprotected) header.d=telekom.de
>> header.i=@telekom.de header.b=dmkLP/Lr;
>> | dkim-atps=neutral
>
> GMX-Postfach gemacht. Dies sind die regelmäßig vorkommenden Header:
[...]
> Mail 2:
> Authentication-Results: gmx.net; dkim=pass header.i=@domain.tld
> Authentication-Results: gmx.net; dkim=fail header.i=@domain.tld
[...]
> Allesamt Mails, die garantiert echt und von seriösen Absendern sind.
> Irgendeinen Nutzen kann ich da nicht erkennen. Besonders #2 ist drollig.
Eine derartige Überprüfung können natürlich mehrere MTAs am Weg machen.
Und die können zu unterschiedlichen Ergebnissen kommen (wobei ich
"zuerst fail und dann pass" auch etwas überraschend finde. Aber da Du
den ganzen Kontext weggelassen und die Domainnamen zensiert hast, kann
man über die Ursache nicht einmal spekulieren).
hp
Marcel Logen
Oct 27, 2022, 11:54:37 AM10/27/22
to
Peter J. Holzer in de.comp.security.misc:
>On 2022-10-26 15:08, Marcel Logen <33320000...@ybtra.de> wrote:
>> Peter J. Holzer in de.comp.security.misc:
>>>On 2022-10-24 09:10, Volker Delf <nop...@ist.invalid> wrote:
[...]
>On 2022-10-26 15:08, Marcel Logen <33320000...@ybtra.de> wrote:
>> Peter J. Holzer in de.comp.security.misc:
>>>On 2022-10-24 09:10, Volker Delf <nop...@ist.invalid> wrote:
>>>> Welches E-Mail Programm prüft denn die DKIM-Signature in den Kopfdaten?
>>>
>>>Offenbar der Webmailer der Telekom.
>>
>> Einen Webmailer hatte ich jetzt nicht unter die eMail-
>> Programme gezählt.
>
>Jetzt bin ich etwas verwirrt. Hast nicht du das blaue @ in die
>Diskussion eingebracht?
DKIM-Signaturen prüfen kann. Danach hatte Volker ja gefragt.
(Nur der Webmailer der Telekom ist mir als 'System' bekannt,
das so etwas kann. Aber der ist in meinen Augen kein "eMail-
Programm".)
>>>(Wobei eine gültige DKIM-Signature natürlich nicht aussagt, dass die
>>>Mail von der Telekom stammt. Wenn das blaue @ also nur bedeutet, dass
>>>die DKIM-Signature korrekt ist, dann muss der User noch andere Daten
>>>überprüfen.)
>>
>> Hm, welche denn? Wenn man alle Schritte aus RFC6376 aus-
>> führt, sollte man doch sicher sein. Oder mißverstehe ich
>> da etwas?
>
>1. Viele Mail-Provider verwenden DKIM, nicht nur die Telekom. Somit sagt
>eine gültige DKIM-Signature nicht aus, dass eine Mail von der Telekom
>kommt, sondern dass die Mail von einem Provider kommt, der seine
>ausgehenden Mails signiert und dass die signierten Teile der Mail nicht
>unterwegs geändert wurden. Wenn ich den Account "telekomsupport" bei
>Gmail anlege und dann Mails über Gmail als telekom...@gmail.com
>versende, haben die eine gültige Signatur.
von gmail.com?
>2. Ich kann auch selber einen Mail-Server aufsetzen, der Mails
>DKIM-signiert und habe dann volle Kontrolle darüber, was ich signiere.
>Ich kann dann z.B. auch "From: <sup...@telekom.de>" signieren.
>Auch das wäre eine gültige DKIM-Signatur.
der nicht zur Telekom gehört.
>Zusätzlich zur Gültigkeit der Signatur muss man also überprüfen:
>
>* Wer hat die Mail signiert? Wenn die Mail angeblich vom Support-Team
> der Telekom stammt, sollte das die Telekom selbst sein. Gehört die d=
> Domain der Telekom, und wenn ja, ist das die Domain, die die Telekom
> üblicherweise für DKIM-Signaturen verwendet?
>* Welche Teile der Mail wurden überhaupt signiert? Normalerweise ist da
> der From-Header (der uns hier interessiert) dabei, aber streng
> genommen darf man sich auch darauf nicht verlassen.
>* Ist die Absender-Adresse die richtige?
| The From header field MUST be signed (that is, included in the "h="
| tag of the resulting DKIM-Signature header field).
und
| If the "h=" tag does not include the From header field, the Verifier
| MUST ignore the DKIM-Signature header field and return PERMFAIL (From
| field not signed).
Zitat aus <https://de.wikipedia.org/wiki/DomainKeys>:
| [...] Stimmen der gelieferte entschlüsselte und der selbst berech-
| nete Hashcode überein, stammt die E-Mail wirklich von der angegebe-
| nen Domäne. Der oder die verwendeten öffentliche(n) Schlüssel werden
| hierzu im DNS-Eintrag der sendenden Domäne publiziert. Das heißt,
| dass der DNS als Zertifizierungsstelle fungiert. Eine mit Hilfe von
| DomainKeys signierte E-Mail bietet also die Möglichkeit, sicher nach-
| zuprüfen, ob die in der E-Mail-Absenderadresse enthaltene Domäne kor-
| rekt ist und dass die E-Mail auf dem Weg der Zustellung nicht ver-
| ändert wurde.
Marcel
--
──╮ ╭──────────╮ ╭─╮ ╭──╮ ╭─╮ ╭───╮ ..64..╭─╯
│ ╭───╮ ╭─╮ ╰──────╮ ╰─╯ ╰──╯ ╰──╮ ╭─╯ ╰─╮ ..52..│ │ ╭───╯
│ ╰─╮ ╰─╯ │ ╭──────╯ │ │ ╰───╮ ╰─╮ ╰───╯..67..
╰────╯ ╰──╯ ╰─╯ ╰──────╯ ..67..
Marcel Logen
Oct 28, 2022, 1:48:34 AM10/28/22
to
Marcel Logen in de.comp.security.misc:
>Peter J. Holzer in de.comp.security.misc:
>>On 2022-10-26 15:08, Marcel Logen <33320000...@ybtra.de> wrote:
>>> Peter J. Holzer in de.comp.security.misc:
gmail.com die Mail signiert.
Aber würden die das tatsächlich für alle Mails machen, die
ihnen unter die Finger kommen? Grübel.
Marcel
--
╭─╮ ╭────╮ ╭────────────╮ ╭───╮ ╭──────╮ ..62..╭───╯
│ │ ╭─╯ ╭─╯ ╰─────────╮ │ ╰─╮ ╰─╮ ╰──╮ ╰─╮ ..60..╭─╯
╮ ╭─╯ ╰──╯ ╭─╯ ╭─╮ ╭──╮ │ ╰──╮ │ │ ╭──╯ ╭──╯ ╭─────╮ │..67..
╰──╯ ╰───╯ ╰───╯ ╰───╯ ╰─╯ ╰──╯ ╰────╯ ╰──╯..67..
>Peter J. Holzer in de.comp.security.misc:
>>On 2022-10-26 15:08, Marcel Logen <33320000...@ybtra.de> wrote:
>>> Peter J. Holzer in de.comp.security.misc:
>>>>(Wobei eine gültige DKIM-Signature natürlich nicht aussagt, dass die
>>>>Mail von der Telekom stammt. Wenn das blaue @ also nur bedeutet, dass
>>>>die DKIM-Signature korrekt ist, dann muss der User noch andere Daten
>>>>überprüfen.)
>>>
>>> Hm, welche denn? Wenn man alle Schritte aus RFC6376 aus-
>>> führt, sollte man doch sicher sein. Oder mißverstehe ich
>>> da etwas?
>>
>>1. Viele Mail-Provider verwenden DKIM, nicht nur die Telekom. Somit sagt
>>eine gültige DKIM-Signature nicht aus, dass eine Mail von der Telekom
>>kommt, sondern dass die Mail von einem Provider kommt, der seine
>>ausgehenden Mails signiert und dass die signierten Teile der Mail nicht
>>unterwegs geändert wurden. Wenn ich den Account "telekomsupport" bei
>>Gmail anlege und dann Mails über Gmail als telekom...@gmail.com
>>versende, haben die eine gültige Signatur.
>
>Und wie kommst Du für das Signieren an den geheimen Schlüssel
>von gmail.com?
Ah, OK, Mißverständnis. Du meinst hier wahrscheinlich, daß
>>>>Mail von der Telekom stammt. Wenn das blaue @ also nur bedeutet, dass
>>>>die DKIM-Signature korrekt ist, dann muss der User noch andere Daten
>>>>überprüfen.)
>>>
>>> Hm, welche denn? Wenn man alle Schritte aus RFC6376 aus-
>>> führt, sollte man doch sicher sein. Oder mißverstehe ich
>>> da etwas?
>>
>>1. Viele Mail-Provider verwenden DKIM, nicht nur die Telekom. Somit sagt
>>eine gültige DKIM-Signature nicht aus, dass eine Mail von der Telekom
>>kommt, sondern dass die Mail von einem Provider kommt, der seine
>>ausgehenden Mails signiert und dass die signierten Teile der Mail nicht
>>unterwegs geändert wurden. Wenn ich den Account "telekomsupport" bei
>>Gmail anlege und dann Mails über Gmail als telekom...@gmail.com
>>versende, haben die eine gültige Signatur.
>
>Und wie kommst Du für das Signieren an den geheimen Schlüssel
>von gmail.com?
gmail.com die Mail signiert.
Aber würden die das tatsächlich für alle Mails machen, die
ihnen unter die Finger kommen? Grübel.
Marcel
--
╭─╮ ╭────╮ ╭────────────╮ ╭───╮ ╭──────╮ ..62..╭───╯
│ │ ╭─╯ ╭─╯ ╰─────────╮ │ ╰─╮ ╰─╮ ╰──╮ ╰─╮ ..60..╭─╯
╮ ╭─╯ ╰──╯ ╭─╯ ╭─╮ ╭──╮ │ ╰──╮ │ │ ╭──╯ ╭──╯ ╭─────╮ │..67..
╰──╯ ╰───╯ ╰───╯ ╰───╯ ╰─╯ ╰──╯ ╰────╯ ╰──╯..67..
Peter J. Holzer
Oct 28, 2022, 4:54:42 AM10/28/22
to
On 2022-10-28 05:48, Marcel Logen <33320000...@ybtra.de> wrote:
> Marcel Logen in de.comp.security.misc:
>>Peter J. Holzer in de.comp.security.misc:
> Marcel Logen in de.comp.security.misc:
>>Peter J. Holzer in de.comp.security.misc:
>>>1. Viele Mail-Provider verwenden DKIM, nicht nur die Telekom. Somit sagt
>>>eine gültige DKIM-Signature nicht aus, dass eine Mail von der Telekom
>>>kommt, sondern dass die Mail von einem Provider kommt, der seine
>>>ausgehenden Mails signiert und dass die signierten Teile der Mail nicht
>>>unterwegs geändert wurden. Wenn ich den Account "telekomsupport" bei
>>>Gmail anlege und dann Mails über Gmail als telekom...@gmail.com
>>>versende, haben die eine gültige Signatur.
>>
>>Und wie kommst Du für das Signieren an den geheimen Schlüssel
>>von gmail.com?
>
> Ah, OK, Mißverständnis. Du meinst hier wahrscheinlich, daß
> gmail.com die Mail signiert.
So ist es.
>>>eine gültige DKIM-Signature nicht aus, dass eine Mail von der Telekom
>>>kommt, sondern dass die Mail von einem Provider kommt, der seine
>>>ausgehenden Mails signiert und dass die signierten Teile der Mail nicht
>>>unterwegs geändert wurden. Wenn ich den Account "telekomsupport" bei
>>>Gmail anlege und dann Mails über Gmail als telekom...@gmail.com
>>>versende, haben die eine gültige Signatur.
>>
>>Und wie kommst Du für das Signieren an den geheimen Schlüssel
>>von gmail.com?
>
> Ah, OK, Mißverständnis. Du meinst hier wahrscheinlich, daß
> gmail.com die Mail signiert.
> Aber würden die das tatsächlich für alle Mails machen, die
> ihnen unter die Finger kommen? Grübel.
hp
Marcel Logen
Oct 28, 2022, 5:03:16 AM10/28/22
to
Marcel Logen in de.comp.security.misc:
>Peter J. Holzer in de.comp.security.misc:
signierte SPAM-(Phishing(?)-)Mail bekommen.
Hier einige Daten dazu:
| DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
| d=ijasshop.com; s=default; h=Content-Type:Date:Subject:To:From:Message-ID:
| Reply-To:MIME-Version:Sender:Cc:Content-Transfer-Encoding:Content-ID:
| Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
| :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
| List-Subscribe:List-Post:List-Owner:List-Archive;
| bh=rybrbjAzn+8wYIzSs0RkOWLyGncej6L9Qflpo7pnpYs=; b=hNz5145j9b9EzwLQKDabnoXaOY
| 5RDy6Oq7yEjxvI8phXo6c26FfzjBfWhLl2LJ33kiPqY7sa/rcHcyMuceyRzjOKK/RCeCITOidu+9D
| mF+q5elu83ONp3gHa1BifLdM+MAXpPH9UoEXqS2D5i7r3k+npI0XTPH25TYv84RZ1zMKBkGAVptkt
| Z7YmwXHafDI34KmhQ01JrHXQlQ1TvojdtgEqzUFW7zyYvhR6JbP6+ueUawAkV8CMJyyN5J8nwJVY+
| PVDjX6OAghsPizhOUjDI0O6nINSOcHnNkMsXhvabX+Dvq3qcqnMec9NOLO/4JQiK1rsBArsRGt56d
| ntr8HQfA==;
| $ host -t TXT default._domainkey.ijasshop.com
| default._domainkey.ijasshop.com descriptive text "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAutdOC6D1Rbl2cAHJZpepRXtufBllHUYcy6/0R7rSk9iNId1RVaa6emU/tytURiLxLq2uyzoyPkx7/jBZNciF3ghcGAv2cI02ZX5SPYweZJEjW9wTor5nyXPjoYx9Z16SXnfStBV4x04vLz/PZOrw5olNoyhmE8PJ23VGeQ4oLESvJVSDhccosM3cCIP6ySoat" "SK6lEdXwrxqdT1MfoeTtGgyXhxD22ZyY1hLGzYfLLaxiCMcmqOQBFXo2d3QNg7oIQMZ2KXBpeqcAFTZ4NkOrwtE0qqTNy+ge8c/yyX1LqP9gZh99lNk0mQS4NIa59RYAVAigr2ZvPtlfwbujK7z1QIDAQAB;"
Demnach lautet der öffentliche Schlüssel:
| $ od -Ad -tx1 key.2bin
| 0000000 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01
| 0000016 01 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01
| 0000032 00 ba d7 4e 0b a0 f5 45 b9 76 70 01 c9 66 97 a9
| 0000048 45 7b 6e 7c 19 65 1d 46 1c cb af f4 47 ba d2 93
| 0000064 d8 8d 21 dd 51 55 a6 ba 7a 65 3f b7 2b 54 46 22
| 0000080 f1 2e ad ae cb 3a 32 3e 4c 7b fe 30 59 35 c8 85
| 0000096 de 08 5c 18 0b f6 70 8d 36 65 7e 52 3d 8c 1e 64
| 0000112 91 23 5b dc 13 a2 be 67 c9 73 e3 a1 8c 7d 67 5e
| 0000128 92 5e 77 d2 b4 15 78 c7 4e 2f 2f 3f cf 64 ea f0
| 0000144 e6 89 4d a3 28 66 13 c3 c9 db 75 46 79 0e 28 2c
| 0000160 44 af 25 54 83 85 c7 28 b0 cd dc 08 83 fa c9 2a
| 0000176 1a b5 22 ba 94 47 57 c2 bc 6a 75 3d 4c 7e 87 93
| 0000192 b4 68 32 5e 1c 43 db 66 72 63 58 4b 1b 36 1f 2c
| 0000208 b6 b1 88 23 1c 9a a3 90 04 55 e8 d9 dd d0 36 0e
| 0000224 e8 21 03 19 d8 a5 c1 a5 ea 9c 00 54 d9 e0 d9 0e
| 0000240 af 0b 44 d2 aa 93 37 2f a0 7b c7 3f cb 25 f5 2e
| 0000256 a3 fd 81 98 7d f6 53 64 d2 64 12 e0 d2 1a e7 d4
| 0000272 58 01 50 22 82 bd 99 bc fb 65 7f 06 ee 8c ae f3
| 0000288 d5 02 03 01 00 01
| 0000294
Der relevante (von mir entsprechend RFC6376 bearbeitete) Mail-
Headerteil lautet:
| user15@o15:~/ybtra-o15/dkim/u_1$ cat -vET mailheader.2
| content-type:multipart/mixed; boundary="----=_NextPart_001_CC8B_4C886555.497AEC63"^M$
| date:Fri, 28 Oct 2022 02:58:37 +0000^M$
| subject:Help us prevent your wallet form suspension^M$
| to:33320000...@ybtra.de^M$
| from:"=?utf-8?Q?M=D0=B5taMask-2Factor?=" <in...@ijasshop.com>^M$
| message-id:<b11d5c5289854a3b...@ijasshop.com>^M$
| reply-to:"=?utf-8?Q?M=D0=B5taMask-2Factor?=" <nor...@mta.io>^M$
| mime-version:1.0^M$
| dkim-signature:v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ijasshop.com; s=default; h=Content-Type:Date:Subject:To:From:Message-ID: Reply-To:MIME-Version:Sender:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=rybrbjAzn+8wYIzSs0RkOWLyGncej6L9Qflpo7pnpYs=; b=;user15@o15:~/ybtra-o15/dkim/u_1$
Den bodyhash (bh) habe ich überprüft: ist OK.
Die Signatur ist:
| user15@o15:~/ybtra-o15/dkim/u_1$ od -Ad -tx1 sig.2bin
| 0000000 84 dc f9 d7 8e 63 f5 bf 44 cf 02 d0 28 36 9b 9e
| 0000016 85 da 39 8e 51 0f 2e 8e ab bc 84 8f 1b c8 f2 98
| 0000032 57 a3 a7 36 e8 57 f3 8c 17 d6 84 b9 76 2c 9d f7
| 0000048 92 23 ea 63 bb 1a fe b7 07 73 23 2e 71 ec 91 ce
| 0000064 33 8a 2b f4 42 78 22 13 3a 27 6e fb d0 e6 17 ea
| 0000080 b9 7a 5b bc dc e3 69 de 01 da d4 18 9f 2d d3 3e
| 0000096 30 05 e9 3c 7f 54 a0 45 ea 4b 60 f9 8b ba f7 93
| 0000112 e9 e9 23 45 d3 3c 7d b9 4d 8b fc e1 16 75 cc c2
| 0000128 81 90 60 15 a6 d9 2d 67 b6 26 c1 71 da 7c 32 37
| 0000144 e0 a9 a1 43 4d 49 ac 75 d0 95 0d 53 be 88 dd b6
| 0000160 01 2a cd 41 56 ef 3c 98 be 14 7a 25 b3 fa fa e7
| 0000176 94 6b 00 24 57 c0 8c 27 2c 8d e4 9f 27 c0 95 58
| 0000192 f8 f5 43 8d 7e 8e 02 08 6c 3e 2c e1 39 48 c3 23
| 0000208 43 ba 9c 83 52 39 c1 e7 36 43 2c 5e 1b da 6d 7f
| 0000224 83 be ad ea 72 a9 cc 79 cf 4d 38 b3 bf e0 94 22
| 0000240 2b 5a ec 04 0a ec 44 6b 79 e9 d9 ed af c1 d0 7c
| 0000256
So kann ich die DKIM-Signatur verifizieren:
| user15@o15:~/ybtra-o15/dkim/u_1$ openssl dgst -verify key.2bin -keyform DER -signature sig.2bin mailheader.2
| Verified OK
Das heißt für mich, daß auch ein Spammer eine gültige Signa-
tur erzeugen kann. Man muß also - wie Du schreibst - tatsäch-
lich noch prüfen, ob die From-Adresse zur DKIM-Domain gehört.
Marcel
--
╭───╮ ╭──╮ ╭─╮ ╭──╮ ..34..╭──╮ ╭──╮ ╭───╮ ╭──╮ ╭─╮
╮ ╰─╮ ╰─╯ ╰──╯ │ ..20..╭─╯ ╰──╮ ╭─╯ ╰──╯ ╰─╮ │ ╰─╯ ╰─╯ ╰─────
╰─╮ ╰─╮ ╭──────╯ ╭─╯ ╰───╯ ╭─────────╯ ╰─────╮ ..67..
╰────╯ ╰────────────╯ ╰──────────────────╯ ..67..
>Peter J. Holzer in de.comp.security.misc:
>>2. Ich kann auch selber einen Mail-Server aufsetzen, der Mails
>>DKIM-signiert und habe dann volle Kontrolle darüber, was ich signiere.
>>Ich kann dann z.B. auch "From: <sup...@telekom.de>" signieren.
>>Auch das wäre eine gültige DKIM-Signatur.
>
>Kann schon sein, aber Du signierst mit einem geheimen Schlüssel,
>der nicht zur Telekom gehört.
>
>>Zusätzlich zur Gültigkeit der Signatur muss man also überprüfen:
>>
>>* Wer hat die Mail signiert? Wenn die Mail angeblich vom Support-Team
>> der Telekom stammt, sollte das die Telekom selbst sein. Gehört die d=
>> Domain der Telekom, und wenn ja, ist das die Domain, die die Telekom
>> üblicherweise für DKIM-Signaturen verwendet?
>>* Welche Teile der Mail wurden überhaupt signiert? Normalerweise ist da
>> der From-Header (der uns hier interessiert) dabei, aber streng
>> genommen darf man sich auch darauf nicht verlassen.
>>* Ist die Absender-Adresse die richtige?
Ich habe zufällig heute eine (rechnerisch gültig) DKIM-
>>DKIM-signiert und habe dann volle Kontrolle darüber, was ich signiere.
>>Ich kann dann z.B. auch "From: <sup...@telekom.de>" signieren.
>>Auch das wäre eine gültige DKIM-Signatur.
>
>Kann schon sein, aber Du signierst mit einem geheimen Schlüssel,
>der nicht zur Telekom gehört.
>
>>Zusätzlich zur Gültigkeit der Signatur muss man also überprüfen:
>>
>>* Wer hat die Mail signiert? Wenn die Mail angeblich vom Support-Team
>> der Telekom stammt, sollte das die Telekom selbst sein. Gehört die d=
>> Domain der Telekom, und wenn ja, ist das die Domain, die die Telekom
>> üblicherweise für DKIM-Signaturen verwendet?
>>* Welche Teile der Mail wurden überhaupt signiert? Normalerweise ist da
>> der From-Header (der uns hier interessiert) dabei, aber streng
>> genommen darf man sich auch darauf nicht verlassen.
>>* Ist die Absender-Adresse die richtige?
signierte SPAM-(Phishing(?)-)Mail bekommen.
Hier einige Daten dazu:
| DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
| d=ijasshop.com; s=default; h=Content-Type:Date:Subject:To:From:Message-ID:
| Reply-To:MIME-Version:Sender:Cc:Content-Transfer-Encoding:Content-ID:
| Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
| :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
| List-Subscribe:List-Post:List-Owner:List-Archive;
| bh=rybrbjAzn+8wYIzSs0RkOWLyGncej6L9Qflpo7pnpYs=; b=hNz5145j9b9EzwLQKDabnoXaOY
| 5RDy6Oq7yEjxvI8phXo6c26FfzjBfWhLl2LJ33kiPqY7sa/rcHcyMuceyRzjOKK/RCeCITOidu+9D
| mF+q5elu83ONp3gHa1BifLdM+MAXpPH9UoEXqS2D5i7r3k+npI0XTPH25TYv84RZ1zMKBkGAVptkt
| Z7YmwXHafDI34KmhQ01JrHXQlQ1TvojdtgEqzUFW7zyYvhR6JbP6+ueUawAkV8CMJyyN5J8nwJVY+
| PVDjX6OAghsPizhOUjDI0O6nINSOcHnNkMsXhvabX+Dvq3qcqnMec9NOLO/4JQiK1rsBArsRGt56d
| ntr8HQfA==;
| $ host -t TXT default._domainkey.ijasshop.com
| default._domainkey.ijasshop.com descriptive text "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAutdOC6D1Rbl2cAHJZpepRXtufBllHUYcy6/0R7rSk9iNId1RVaa6emU/tytURiLxLq2uyzoyPkx7/jBZNciF3ghcGAv2cI02ZX5SPYweZJEjW9wTor5nyXPjoYx9Z16SXnfStBV4x04vLz/PZOrw5olNoyhmE8PJ23VGeQ4oLESvJVSDhccosM3cCIP6ySoat" "SK6lEdXwrxqdT1MfoeTtGgyXhxD22ZyY1hLGzYfLLaxiCMcmqOQBFXo2d3QNg7oIQMZ2KXBpeqcAFTZ4NkOrwtE0qqTNy+ge8c/yyX1LqP9gZh99lNk0mQS4NIa59RYAVAigr2ZvPtlfwbujK7z1QIDAQAB;"
Demnach lautet der öffentliche Schlüssel:
| $ od -Ad -tx1 key.2bin
| 0000000 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01
| 0000016 01 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01
| 0000032 00 ba d7 4e 0b a0 f5 45 b9 76 70 01 c9 66 97 a9
| 0000048 45 7b 6e 7c 19 65 1d 46 1c cb af f4 47 ba d2 93
| 0000064 d8 8d 21 dd 51 55 a6 ba 7a 65 3f b7 2b 54 46 22
| 0000080 f1 2e ad ae cb 3a 32 3e 4c 7b fe 30 59 35 c8 85
| 0000096 de 08 5c 18 0b f6 70 8d 36 65 7e 52 3d 8c 1e 64
| 0000112 91 23 5b dc 13 a2 be 67 c9 73 e3 a1 8c 7d 67 5e
| 0000128 92 5e 77 d2 b4 15 78 c7 4e 2f 2f 3f cf 64 ea f0
| 0000144 e6 89 4d a3 28 66 13 c3 c9 db 75 46 79 0e 28 2c
| 0000160 44 af 25 54 83 85 c7 28 b0 cd dc 08 83 fa c9 2a
| 0000176 1a b5 22 ba 94 47 57 c2 bc 6a 75 3d 4c 7e 87 93
| 0000192 b4 68 32 5e 1c 43 db 66 72 63 58 4b 1b 36 1f 2c
| 0000208 b6 b1 88 23 1c 9a a3 90 04 55 e8 d9 dd d0 36 0e
| 0000224 e8 21 03 19 d8 a5 c1 a5 ea 9c 00 54 d9 e0 d9 0e
| 0000240 af 0b 44 d2 aa 93 37 2f a0 7b c7 3f cb 25 f5 2e
| 0000256 a3 fd 81 98 7d f6 53 64 d2 64 12 e0 d2 1a e7 d4
| 0000272 58 01 50 22 82 bd 99 bc fb 65 7f 06 ee 8c ae f3
| 0000288 d5 02 03 01 00 01
| 0000294
Der relevante (von mir entsprechend RFC6376 bearbeitete) Mail-
Headerteil lautet:
| user15@o15:~/ybtra-o15/dkim/u_1$ cat -vET mailheader.2
| content-type:multipart/mixed; boundary="----=_NextPart_001_CC8B_4C886555.497AEC63"^M$
| date:Fri, 28 Oct 2022 02:58:37 +0000^M$
| subject:Help us prevent your wallet form suspension^M$
| to:33320000...@ybtra.de^M$
| from:"=?utf-8?Q?M=D0=B5taMask-2Factor?=" <in...@ijasshop.com>^M$
| message-id:<b11d5c5289854a3b...@ijasshop.com>^M$
| reply-to:"=?utf-8?Q?M=D0=B5taMask-2Factor?=" <nor...@mta.io>^M$
| mime-version:1.0^M$
| dkim-signature:v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ijasshop.com; s=default; h=Content-Type:Date:Subject:To:From:Message-ID: Reply-To:MIME-Version:Sender:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=rybrbjAzn+8wYIzSs0RkOWLyGncej6L9Qflpo7pnpYs=; b=;user15@o15:~/ybtra-o15/dkim/u_1$
Den bodyhash (bh) habe ich überprüft: ist OK.
Die Signatur ist:
| user15@o15:~/ybtra-o15/dkim/u_1$ od -Ad -tx1 sig.2bin
| 0000000 84 dc f9 d7 8e 63 f5 bf 44 cf 02 d0 28 36 9b 9e
| 0000016 85 da 39 8e 51 0f 2e 8e ab bc 84 8f 1b c8 f2 98
| 0000032 57 a3 a7 36 e8 57 f3 8c 17 d6 84 b9 76 2c 9d f7
| 0000048 92 23 ea 63 bb 1a fe b7 07 73 23 2e 71 ec 91 ce
| 0000064 33 8a 2b f4 42 78 22 13 3a 27 6e fb d0 e6 17 ea
| 0000080 b9 7a 5b bc dc e3 69 de 01 da d4 18 9f 2d d3 3e
| 0000096 30 05 e9 3c 7f 54 a0 45 ea 4b 60 f9 8b ba f7 93
| 0000112 e9 e9 23 45 d3 3c 7d b9 4d 8b fc e1 16 75 cc c2
| 0000128 81 90 60 15 a6 d9 2d 67 b6 26 c1 71 da 7c 32 37
| 0000144 e0 a9 a1 43 4d 49 ac 75 d0 95 0d 53 be 88 dd b6
| 0000160 01 2a cd 41 56 ef 3c 98 be 14 7a 25 b3 fa fa e7
| 0000176 94 6b 00 24 57 c0 8c 27 2c 8d e4 9f 27 c0 95 58
| 0000192 f8 f5 43 8d 7e 8e 02 08 6c 3e 2c e1 39 48 c3 23
| 0000208 43 ba 9c 83 52 39 c1 e7 36 43 2c 5e 1b da 6d 7f
| 0000224 83 be ad ea 72 a9 cc 79 cf 4d 38 b3 bf e0 94 22
| 0000240 2b 5a ec 04 0a ec 44 6b 79 e9 d9 ed af c1 d0 7c
| 0000256
So kann ich die DKIM-Signatur verifizieren:
| user15@o15:~/ybtra-o15/dkim/u_1$ openssl dgst -verify key.2bin -keyform DER -signature sig.2bin mailheader.2
| Verified OK
Das heißt für mich, daß auch ein Spammer eine gültige Signa-
tur erzeugen kann. Man muß also - wie Du schreibst - tatsäch-
lich noch prüfen, ob die From-Adresse zur DKIM-Domain gehört.
Marcel
--
╭───╮ ╭──╮ ╭─╮ ╭──╮ ..34..╭──╮ ╭──╮ ╭───╮ ╭──╮ ╭─╮
╮ ╰─╮ ╰─╯ ╰──╯ │ ..20..╭─╯ ╰──╮ ╭─╯ ╰──╯ ╰─╮ │ ╰─╯ ╰─╯ ╰─────
╰─╮ ╰─╮ ╭──────╯ ╭─╯ ╰───╯ ╭─────────╯ ╰─────╮ ..67..
╰────╯ ╰────────────╯ ╰──────────────────╯ ..67..
Marcel Logen
Oct 28, 2022, 5:13:21 AM10/28/22
to
Marcel Logen in de.comp.security.misc:
>So kann ich die DKIM-Signatur verifizieren:
>
>| user15@o15:~/ybtra-o15/dkim/u_1$ openssl dgst -verify key.2bin -keyform DER -signature sig.2bin mailheader.2
>| Verified OK
Vielleicht sollte ich noch dazuschreiben, daß mein OpenSSL/
1.1.1n (von Debian/10.13) standardmäßig SHA256 als Hash ver-
wendet.
| user15@o15:~/ybtra-o15/dkim/u_1$ openssl dgst -sha1 -verify key.2bin -keyform DER -signature sig.2bin mailheader.2
| Verification Failure
Ingrid
--
╭──────╮ ╭────────╮ ╭──╮ ╭─────────────────────╮ ╭───────────
╭─╯ ╭───╯ ╭──╯ ..19..╰───╯ │ ╰──────────╮ ╭────╯ ╰─────╮
─╯ ╭─╯ ╭──╯ ╭─────╯ ..36..╭────╯ ╭──╯ ╭──╮ ╭──╮ │
╰────╯ ╰───────────────╯ ..44..╰────╯ ╰──╯ ╰──╯
>So kann ich die DKIM-Signatur verifizieren:
>
>| user15@o15:~/ybtra-o15/dkim/u_1$ openssl dgst -verify key.2bin -keyform DER -signature sig.2bin mailheader.2
>| Verified OK
1.1.1n (von Debian/10.13) standardmäßig SHA256 als Hash ver-
wendet.
| user15@o15:~/ybtra-o15/dkim/u_1$ openssl dgst -sha1 -verify key.2bin -keyform DER -signature sig.2bin mailheader.2
| Verification Failure
Ingrid
--
╭──────╮ ╭────────╮ ╭──╮ ╭─────────────────────╮ ╭───────────
╭─╯ ╭───╯ ╭──╯ ..19..╰───╯ │ ╰──────────╮ ╭────╯ ╰─────╮
─╯ ╭─╯ ╭──╯ ╭─────╯ ..36..╭────╯ ╭──╯ ╭──╮ ╭──╮ │
╰────╯ ╰───────────────╯ ..44..╰────╯ ╰──╯ ╰──╯
Peter J. Holzer
Oct 28, 2022, 5:25:35 AM10/28/22
to
On 2022-10-27 15:54, Marcel Logen <33320000...@ybtra.de> wrote:
> Peter J. Holzer in de.comp.security.misc:
>>On 2022-10-26 15:08, Marcel Logen <33320000...@ybtra.de> wrote:
>>> Peter J. Holzer in de.comp.security.misc:
>>>>On 2022-10-24 09:10, Volker Delf <nop...@ist.invalid> wrote:
>>>>> Welches E-Mail Programm prüft denn die DKIM-Signature in den Kopfdaten?
>>>>Offenbar der Webmailer der Telekom.
>>>
>>> Einen Webmailer hatte ich jetzt nicht unter die eMail-
>>> Programme gezählt.
>>
>>Jetzt bin ich etwas verwirrt. Hast nicht du das blaue @ in die
>>Diskussion eingebracht?
>
> Ja, stimmt. Aber ich kenne kein eMail-Programm, welches die
> DKIM-Signaturen prüfen kann. Danach hatte Volker ja gefragt.
> (Nur der Webmailer der Telekom ist mir als 'System' bekannt,
> das so etwas kann. Aber der ist in meinen Augen kein "eMail-
> Programm".)
Du hast eine zu enge Definition von "Mail-Programm". Ein Programm, das
> Peter J. Holzer in de.comp.security.misc:
>>On 2022-10-26 15:08, Marcel Logen <33320000...@ybtra.de> wrote:
>>> Peter J. Holzer in de.comp.security.misc:
>>>>On 2022-10-24 09:10, Volker Delf <nop...@ist.invalid> wrote:
>>>>> Welches E-Mail Programm prüft denn die DKIM-Signature in den Kopfdaten?
>>>>Offenbar der Webmailer der Telekom.
>>>
>>> Einen Webmailer hatte ich jetzt nicht unter die eMail-
>>> Programme gezählt.
>>
>>Jetzt bin ich etwas verwirrt. Hast nicht du das blaue @ in die
>>Diskussion eingebracht?
>
> Ja, stimmt. Aber ich kenne kein eMail-Programm, welches die
> DKIM-Signaturen prüfen kann. Danach hatte Volker ja gefragt.
> (Nur der Webmailer der Telekom ist mir als 'System' bekannt,
> das so etwas kann. Aber der ist in meinen Augen kein "eMail-
> Programm".)
dazu verwendet wird, Mails zu lesen und zu schreiben, ist jedenfalls ein
Mail-Programm. Warum sollte das davon abhängen, ob es am Server oder
Computer des Users (oder verteilt auf beide) läuft?
>>>>(Wobei eine gültige DKIM-Signature natürlich nicht aussagt, dass die
>>>>Mail von der Telekom stammt. Wenn das blaue @ also nur bedeutet, dass
>>>>die DKIM-Signature korrekt ist, dann muss der User noch andere Daten
>>>>überprüfen.)
>>1. Viele Mail-Provider verwenden DKIM, nicht nur die Telekom. Somit sagt
>>eine gültige DKIM-Signature nicht aus, dass eine Mail von der Telekom
>>kommt, sondern dass die Mail von einem Provider kommt, der seine
>>ausgehenden Mails signiert und dass die signierten Teile der Mail nicht
>>unterwegs geändert wurden. Wenn ich den Account "telekomsupport" bei
>>Gmail anlege und dann Mails über Gmail als telekom...@gmail.com
>>versende, haben die eine gültige Signatur.
>
> Und wie kommst Du für das Signieren an den geheimen Schlüssel
> von gmail.com?
>
>>2. Ich kann auch selber einen Mail-Server aufsetzen, der Mails
>>DKIM-signiert und habe dann volle Kontrolle darüber, was ich signiere.
>>Ich kann dann z.B. auch "From: <sup...@telekom.de>" signieren.
>>Auch das wäre eine gültige DKIM-Signatur.
>
> Kann schon sein, aber Du signierst mit einem geheimen Schlüssel,
> der nicht zur Telekom gehört.
Das ist aber egal, wenn die Bedingung nur "gültige DKIM-Signatur"
>>eine gültige DKIM-Signature nicht aus, dass eine Mail von der Telekom
>>kommt, sondern dass die Mail von einem Provider kommt, der seine
>>ausgehenden Mails signiert und dass die signierten Teile der Mail nicht
>>unterwegs geändert wurden. Wenn ich den Account "telekomsupport" bei
>>Gmail anlege und dann Mails über Gmail als telekom...@gmail.com
>>versende, haben die eine gültige Signatur.
>
> Und wie kommst Du für das Signieren an den geheimen Schlüssel
> von gmail.com?
>
>>2. Ich kann auch selber einen Mail-Server aufsetzen, der Mails
>>DKIM-signiert und habe dann volle Kontrolle darüber, was ich signiere.
>>Ich kann dann z.B. auch "From: <sup...@telekom.de>" signieren.
>>Auch das wäre eine gültige DKIM-Signatur.
>
> Kann schon sein, aber Du signierst mit einem geheimen Schlüssel,
> der nicht zur Telekom gehört.
lautet. Ich signiere mit meinem privaten Key, inkludiere meine Domain,
der Verifier holt sich von dort meinen Public Key, überprüft das, und
stellt fest, dass alles zusammenpasst. Solange der Empfänger nicht
nachschaut, *wer* die Nachricht signiert hat, und sich darüber wundert,
dass eine Mail, die angeblich von <sup...@telekom.de> kommt, von
"hjp.at" signiert ist, fällt das nicht auf.
>>Zusätzlich zur Gültigkeit der Signatur muss man also überprüfen:
>>
>>* Wer hat die Mail signiert? Wenn die Mail angeblich vom Support-Team
>> der Telekom stammt, sollte das die Telekom selbst sein. Gehört die d=
>> Domain der Telekom, und wenn ja, ist das die Domain, die die Telekom
>> üblicherweise für DKIM-Signaturen verwendet?
>>* Welche Teile der Mail wurden überhaupt signiert? Normalerweise ist da
>> der From-Header (der uns hier interessiert) dabei, aber streng
>> genommen darf man sich auch darauf nicht verlassen.
>>* Ist die Absender-Adresse die richtige?
>
> Zitate aus RFC6376:
>
>| The From header field MUST be signed (that is, included in the "h="
>| tag of the resulting DKIM-Signature header field).
wenn ich den From-Header in transit ändern will. Bei Phishing-Mails
irrelevant. Die anderen beiden Punkte sind davon ohnehin unberührt.
> Zitat aus <https://de.wikipedia.org/wiki/DomainKeys>:
>
>| [...] Stimmen der gelieferte entschlüsselte und der selbst berech-
>| nete Hashcode überein, stammt die E-Mail wirklich von der angegebe-
>| nen Domäne. Der oder die verwendeten öffentliche(n) Schlüssel werden
>| hierzu im DNS-Eintrag der sendenden Domäne publiziert. Das heißt,
>| dass der DNS als Zertifizierungsstelle fungiert. Eine mit Hilfe von
>| DomainKeys signierte E-Mail bietet also die Möglichkeit, sicher nach-
>| zuprüfen, ob die in der E-Mail-Absenderadresse enthaltene Domäne kor-
>| rekt ist und dass die E-Mail auf dem Weg der Zustellung nicht ver-
>| ändert wurde.
"angegebene Domäne" ist die aus dem DKIM-Signature Header, nicht die aus
der Absender-Adresse. Wenn ich z.B. beruflich Mails versende, ist das
"wsr01.onmicrosoft.com". Im From-Header steht aber unsere Domain, keine
Microsoft-Domain.
hp
Peter J. Holzer
Oct 28, 2022, 5:29:49 AM10/28/22
to
On 2022-10-28 07:52, Christian @Soemtron <christian...@soemtron.de> wrote:
> Peter J. Holzer <hjp-u...@hjp.at> schrieb:
> Ergebnissen kamen?
Woher sollte ich das wissen? Das war aus dem, was Du gepostet hast,
nicht herauszulesen.
>> (wobei ich "zuerst fail und dann pass" auch etwas überraschend
>> finde. Aber da Du den ganzen Kontext weggelassen und die
>> Domainnamen zensiert hast, kann man über die Ursache nicht einmal
>> spekulieren).
>
> Das kam schon von verschiedenen Absendern. Dachte nicht, daß es
> interessiert. Aktuell:
>
> Return-Path: <us...@aerzte-finanz.de>
> Authentication-Results: gmx.net; dkim=pass header.i=@aerzte-finanz.de
> Authentication-Results: gmx.net; dkim=fail header.i=@aerzte-finanz.de
> Received: from mx07-00181c02.pphosted.com ([185.132.180.43])
> by mx-ha.gmx.net (mxgmx103 [212.227.17.5])
> with ESMTPS (Nemesis) id 1MMX9j-1oX8lN3P43-00JXfF for <m...@gmx.de>;
> Thu, 27 Oct 2022 11:13:58 +0200
> Received: from pps.filterd (m0208901.ppops.net [127.0.0.1])
> by mx07-00181c02.pphosted.com (8.17.1.5/8.17.1.5)
> with ESMTP id 29R8Ysfo009740 for <m...@gmx.de>;
> Thu, 27 Oct 2022 09:13:58 GMT
> From: <us...@aerzte-finanz.de>
Gut, das sieht jedenfalls danach aus, dass beide Überprüfungen vom
gleichen MTA durchgeführt wurden (kein Received-Header dazwischen).
Warum der zwei Prüfungen durchführt, ist eine gute Frage. Gab es
vielleicht zwei DKIM-Signature Header?
hp
> Peter J. Holzer <hjp-u...@hjp.at> schrieb:
>> Eine derartige Überprüfung können natürlich mehrere MTAs am Weg
>> machen. Und die können zu unterschiedlichen Ergebnissen kommen
>
> Lief diese Mail denn also über 2 MTAs von GMX? Die zu unterschiedlichen
>> machen. Und die können zu unterschiedlichen Ergebnissen kommen
>
> Ergebnissen kamen?
Woher sollte ich das wissen? Das war aus dem, was Du gepostet hast,
nicht herauszulesen.
>> (wobei ich "zuerst fail und dann pass" auch etwas überraschend
>> finde. Aber da Du den ganzen Kontext weggelassen und die
>> Domainnamen zensiert hast, kann man über die Ursache nicht einmal
>> spekulieren).
>
> interessiert. Aktuell:
>
> Return-Path: <us...@aerzte-finanz.de>
> Authentication-Results: gmx.net; dkim=pass header.i=@aerzte-finanz.de
> Authentication-Results: gmx.net; dkim=fail header.i=@aerzte-finanz.de
> Received: from mx07-00181c02.pphosted.com ([185.132.180.43])
> by mx-ha.gmx.net (mxgmx103 [212.227.17.5])
> with ESMTPS (Nemesis) id 1MMX9j-1oX8lN3P43-00JXfF for <m...@gmx.de>;
> Thu, 27 Oct 2022 11:13:58 +0200
> Received: from pps.filterd (m0208901.ppops.net [127.0.0.1])
> by mx07-00181c02.pphosted.com (8.17.1.5/8.17.1.5)
> with ESMTP id 29R8Ysfo009740 for <m...@gmx.de>;
> Thu, 27 Oct 2022 09:13:58 GMT
> From: <us...@aerzte-finanz.de>
Gut, das sieht jedenfalls danach aus, dass beide Überprüfungen vom
gleichen MTA durchgeführt wurden (kein Received-Header dazwischen).
Warum der zwei Prüfungen durchführt, ist eine gute Frage. Gab es
vielleicht zwei DKIM-Signature Header?
hp
0 new messages