Springe zum Inhalt

Schlagwort: E-Mail

Veröffentlicht am

Lange Zeit war es still um ".DE Deutsche Domain" bzw. den Absender deutschedomain.com. Die letzten dokumentierten Fälle stammen aus Oktober und November 2015. Heute jedoch flatterte wieder einer dieser Abzockversuche ins digitale Postfach:

Sehr geehrte Frau / Herr,

Nachfolgend die Einzelheiten zu der Domainregistrierung für 2016 / 2017.

Wir hoffen, Sie ausreichend informiert zu haben.

Mit freundlichen Grüssen

Anna Müller

Kundendienst
DE Deutsche Domain
info@deutschedomain.com

Schon dass hier keine korrekte Anrede verwendet wurde sollte aufhorchen lassen. Im Anhang befindet sich dann ein bemerkenswertes PDF mit Namen "Rechnung 232366.pdf":

Rechnung 232366

Was als erstes an dieser "Rechnung" auffällt: sie ist schlicht an niemanden gerichtet. Ebenfalls unklar ist der Rechnungsgegenstand. Um welche Domain handelt es sich hier? Die bei Rechnungen erforderliche USt-ID oder Steuernummer fehlt ebenfalls.

Der Betrugsversuch wird erst im Kleingedruckten offenbar. Dort ist unter anderem zu lesen:

Dies ist ein angebot und keine rechnung, die zahlung auf dieses angebot hin wird als annahme des angebotes oder auftragsbestätigung verstanden.

Das Ganze ist also mitnichten eine Rechnung, sondern ein (selten dämliches) Angebot, bei dem noch nicht einmal die angebotene Leistung, auch nicht aus dem Kleingedruckten, ersichtlich ist.

Welche Fakten kann man dem PDF noch entnehmen?

  • Die Echtheit der angegebenen Telefonnummer wage ich zu bezweifeln. Nur fünfstellige Telefonnummern in Berlin?
  • Als Kontaktadresse ist nur ein Postfach (also keine ladungsfähige Adresse) in Berlin angegeben.
  • Überwiesen werden soll an eine spanische Bank (zu erkennen an dem Kürzel "ES" am Anfang der IBAN). Die Prüfung der IBAN ergibt, dass das Konto bei der Zweigstelle 0104 der UNICAJA BANCO, S.A., Malaga geführt wird.
  • Dass der PDF-Seitentitel "Página 1" (spanisch für "Seite 1") und der Benutzername "Usuario" (spanisch für "Benutzer") lautet, deutet darauf hin, dass Spanien auch der Ursprungsort des PDFs ist.
  • Zum Erstellen des PDFs wurde anscheinend CorelDRAW X5 verwendet. Dieser Hinweis und die eingebetteten Schriftarten ArialMT und Arial-BoldMT deuten auf einen Windows-Rechner hin.

Was gibt der E-Mail-Header her?

Hier die relevanten Header-Zeilen:

Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0087.outbound.protection.outlook.com [157.55.234.87])
	by mx1.xxxxxxxxxxxxxxxx (Postfix) with ESMTPS id 1CC7A1607DB
	for <xxxxxxxxxxxxxxx>; Wed, 22 Jun 2016 17:08:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=netorgft810459.onmicrosoft.com; s=selector1-deutschedomain-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
 bh=UnZdiQs+DjMOkpBEYzTHPetqguKBJJhWGiDHDKuXLdk=;
 b=QMUkUfPEOzaQ4YlCFJWSvogzaGNjWMEvIWpkyuUO2KZkGyfXFsE59KJQjKsOpY4TxONWY2ZVLAWOOW23e6Sk8oPLk3mf+LYtsNnJh9iuJEoRoYiJ3P5lkc2BJApAxFV6nA1FbVsyqlFNY6LJG8ASPbu8WRLaZrXwrPpy0cybPr4=
Received: from DB4PR07MB0752.eurprd07.prod.outlook.com (10.242.223.17) by
 DB4PR07MB0750.eurprd07.prod.outlook.com (10.242.223.156) with Microsoft SMTP
 Server (TLS) id 15.1.523.12; Wed, 22 Jun 2016 15:08:28 +0000
Received: from DB4PR07MB0752.eurprd07.prod.outlook.com ([10.242.223.17]) by
 DB4PR07MB0752.eurprd07.prod.outlook.com ([10.242.223.17]) with mapi id
 15.01.0517.014; Wed, 22 Jun 2016 15:08:28 +0000
From: ".DE Deutsche Domain" <info11@deutschedomain.com>
To: ".DE Deutsche Domain" <info11@deutschedomain.com>
Subject: Domainregistrierung 2016 / 2017
Thread-Topic: Domainregistrierung 2016 / 2017
Thread-Index: AQHRzJd7BFty2iqWAE2esWDAagHjbQ==
Importance: high
X-Priority: 1
Date: Wed, 22 Jun 2016 15:08:27 +0000
Message-ID: <DB4PR07MB0752EA922CC0101E71AEFD8DA62C0@DB4PR07MB0752.eurprd07.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is )
 smtp.mailfrom=info11@deutschedomain.com; 
x-originating-ip: [132.245.225.101]
x-ms-office365-filtering-correlation-id: 901118ad-2e91-4199-1271-08d39aaf10e2
x-microsoft-exchange-diagnostics: 1;DB4PR07MB0750;6:lzSdY+JQkpRaZDdcOMB05Lmlpqpyk1D1JkrsiiRjN4DqwK8Yn2X+6PM9lroNCF8vXTnurcnI6DL1E0MoeL1PNf3hE6bzpWmXx9H/iWuNu5dJgawWJPvlyGgNhRg9qTdw4TKf+3mJ6jWurzb3Ka3wVQMccyrA07OUwwodkHlkoYhAo2EWXV121l+IBI14BQTk3m+75fmT+hGL6DWMghv9dy1XD45iDe4+BKS854v1r3siPJkB/znvTGpVdAsRSRDaoi7FFcCje/r5iv6HA+DUBeEEdR5z4NNx2eNWWBaiiTGTPgkKwRs0T7JcVa8tjTHj;5:qCNYOOyHwdFfT6+BC3LsFF3FiM/FP/EzAV/lCOT+hC+4BhXiXCso9Fpu9koGouYoF28ObNIQlIr39BbncTkUPs+u3XK/DrEKi0aA9eymGjRo/K79vFAB6k6byb+Yzh4uwxpHNP6pcnyLRgpl69y78w==;24:sftGZ8jmC8gZ2FlheIYLPKq669lGhisU/6dfwI2zmdq3WU3PkOM0IZM8H7IQU2+4Tc+v/kfpjYlvofYt6daSoJbCPvlgOGpdWpBcFLiRffc=;7:CV4V4bVkM00okIx2HupB1wf+wiB5nWpQt9R1vq6aOFghsbO1H2Ys015m/xFyPQa4+686+40BhiGfzff6Upr1WHJG2/+CH7Cs4WRy2rnrTjN0bRGx/ODbj6dg1EF+xIZy7D18N9pV/2FOv0ags4YdCrOM7R26C9zFuZEG5DJyCCG16oE2eMjZO4WVr0lCqLeu8Cv5xvJRxdl4NxGDhGLaBGCxi6Gn7xGWfqvynfH/XGAE5Cy+BQdPcepIZnItQXCW
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR07MB0750;
x-microsoft-antispam-prvs: <DB4PR07MB07503B8F11E38473B6726D44A62C0@DB4PR07MB0750.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(102415321)(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046);SRVR:DB4PR07MB0750;BCL:0;PCL:0;RULEID:;SRVR:DB4PR07MB0750;
x-forefront-prvs: 0981815F2F
x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(7916002)(199003)(189002)(106356001)(106116001)(105586002)(87936001)(189998001)(76576001)(33656002)(101416001)(3280700002)(19627405001)(229853001)(66066001)(3660700001)(8666005)(97736004)(4001450100002)(110136002)(107886002)(74316001)(99936001)(10400500002)(50986999)(122556002)(54356999)(81686999)(9686002)(6200100001)(86362001)(11100500001)(8676002)(19625215002)(81166006)(81156014)(586003)(558084003)(19580405001)(2906002)(19580395003)(16236675004)(68736007)(5002640100001)(7696003)(92566002)(7736002)(5003600100003)(7846002)(77096005)(8936002)(3846002)(2900100001)(102836003)(6116002)(7059030);DIR:OUT;SFP:1101;SCL:1;SRVR:DB4PR07MB0750;H:DB4PR07MB0752.eurprd07.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:de;
received-spf: None (protection.outlook.com: deutschedomain.com does not
 designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/mixed;
	boundary="_004_DB4PR07MB0752EA922CC0101E71AEFD8DA62C0DB4PR07MB0752eurp_"
MIME-Version: 1.0
X-OriginatorOrg: deutschedomain.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2016 15:08:27.7593
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a87ceb82-ac57-4031-b8db-3e4f2cb4dd53
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB0750

Anscheinend wurde die E-Mail direkt über das Webinterface von Microsoft bzw. Live gesendet. Die angegebene x-originating-ip ist einem Netblock von Microsoft zugeordnet. Der Umstand, dass Microsoft eine DKIM-Signatur einfügt und das Setzen der Absenderdomain erlaubt deutet darauf hin, dass ein Benutzerkonto verwendet wurde, welches durch Microsoft auch der Absenderdomain deutschedomain.com zugeordnet werden kann.

Mehr kann den ganzen Microsoft spezifischen Headern wohl nur Microsoft selbst entnehmen.

Die Domain deutschedomain.com

Die Domain wurde über GODADDY registriert. Als Inhaber wurde eine Firma "NL Domein Hosting" in Amsterdam angegeben. Lt. Google Maps gibt es die angegebene Adresse des Domaininhabers nicht. Die angegebene Telefonnumer aus den Niederlanden hat schon eine Ortsvorwahl welche nicht existiert.

Der für diese Domain zuständige Mailserver wird ebenfalls von GODADDY betrieben. Das hilft also auch nicht weiter.

Fazit

Es bleibt nur eins: auf gar keinen Fall zahlen! Evtl. sogar Anzeige gegen Unbekannt bei der Polizei erstatten.

Veröffentlicht am

Finn hat mehrere gute Anleitungen geschrieben, wie man dem lokalen Postfix

  • DKIM womit der Empfänger feststellen kann, ob die Mail wirklich vom zuständigen Mailserver des Absenders stammt
  • SPF um zu verhindern, dass andere Mailserver die eigenen Domain als Absender verenden
  • DMARC um festzulegen, was der Mailserver des Empfängers bei fehlgeschlagener Prüfung nach DKIM und SPF mit der Mail tun soll

beibringt. Ich bin noch mittendrin in der Konfiguration. DKIM funktioniert nun schon hervorragend.

2

Veröffentlicht am 2 Kommentare zu Problem: K-9 Mail, OpenKeychain und Anhänge

Wer K-9 Mail benutzt (nebenbei das beliebtestet OpenSoure-Programm für E-Mails unter Android) und zur Verschlüsselung der E-Mails mit PGP OpenKeychain verwendet, wird über kurz oder lang vor folgendem Problem stehen: dem Verschlüsseln von Anhängen.

Leider unterstützt K-9 Mail bisher den Standard PGP-MIME nicht, sondern kann verschlüsselte Nachrichten nur im Format PGP-Inline verschicken. Daraus ergeben sich gleich zwei Probleme:

  1. Beim Versenden von verschlüsselten Nachrichten wird nur der Nachrichtentext verschlüsselt. Etwaige Anhänge werden unverschlüsselt verschickt.Dieses Problem kann umgangen werden, indem die Anhänge zuerst mit OpenKeychain verschlüsselt werden und diese verschlüsselten Dateien dann der E-Mail angehängt werden. Sehr unhandlich.
  2. Beim Empfang von PGP-verschlüsselten Nachrichten können nur per PGP-Inline-kodierte Nachrichten sofort in K-9 Mail angezeigt werden.PGP-MIME-kodierte Nachrichten müssen erst abgespeichert werden und können anschließend in OpenKeychain entschlüsselt werden. Ebenfalls sehr unhandlich.

Wie man in folgenden Thread nachlesen kann, sind für die Implementierung von PGP-MIME in K-9 Mail umfassende Arbeiten an der Storage-Engine notwendig. Leider hat bis heute noch niemand entsprechend Zeit für eine Implementierung gefunden, obwohl es anscheinend zu den am meisten von den Benutzern gewünschten Erweiterungen zählt (inklusive mir). Wer mag, kann einen Anreiz für die Entwickler schaffen, indem er sie finanziell unterstützt. Ein entsprechende Seite bei Bountysource ist eingerichtet und steht aktuell bei US$ 1.015.

Veröffentlicht am

Ab und zu findet man im weiten Netz auch Konfigurationen, in denen für den MX-Record einer Domain ein CNAME geliefert wird. RFC2181 verbietet ausdrücklich, für den MX-Record einen CNAME zu verwenden:

10.3. MX and NS records
 
   The domain name used as the value of a NS resource record, or part of
   the value of a MX resource record must not be an alias.  Not only is
   the specification clear on this point, but using an alias in either
   of these positions neither works as well as might be hoped, nor well
   fulfills the ambition that may have led to this approach.  This
   domain name must have as its value one or more address records.
   Currently those will be A records, however in the future other record
   types giving addressing information may be acceptable.  It can also
   have other RRs, but never a CNAME RR.

Es ist also ausdrücklich verboten, auf eine MX-Anfrage einen CNAME-Record zu liefern. Ganz praktisch: der PHP-Mailer von 1&1 verschickt an CNAME-Records bei einer MX-Anfrage keine E-Mails, sondern deren Mailsystem lehnt dann den Versand der E-Mail ab.

Veröffentlicht am

Spam und Viren liegen heutzutage massenweise im (ungefilterten) Postfach. Neu ist jedoch, dass diese digital signiert versendet werden. Vor Kurzem traf hier eine E-Mail ein, die angeblich eine Information für den Empfänger einer Überweisung über Western Union sein sollte. In einem Anhang befand sich natürlich ein Virus.

Erstaunlich ist allerdings, mit was für einem Zertifikat die E-Mail unterschrieben wurde. Es handelt sich hier um ein gültiges Zertifikat der Firma Actalis S.p.A.: ...weiterlesen "Digital signierte Virus Mail"