Gnu.org im Jahr 1998 stecken geblieben

Ja, ich weiß, Ihr könnt es nicht mehr lesen, der xte Mailserver der keine TLS 1.2 kann, nur leider hat der hier eggs.gnu.org eine wichtige Rolle, der handelt nämlich Emails für gnu.org . Kein TLS 1.2 , keine Emails mehr aus Europa.

„.. und dabei ist FOSS & TLS 1.2 kein Widerspruch.“

Trying TLS on eggs.gnu.org[209.51.188.92:25] (10):

secondstest stage and result
[000.007]Connected to server
[000.167]<–220 eggs.gnu.org ESMTP Exim 4.71 Sat, 09 Feb 2019 11:54:20 -0500
[000.167]We are allowed to connect
[000.167] –>EHLO www6.CheckTLS.com
[000.174]<–250-eggs.gnu.org Hello www6.checktls.com [159.89.187.50]
250-SIZE 52428800
250-PIPELINING
250-STARTTLS
250 HELP
[000.174]We can use this server
[000.175]TLS is an option on this server
[000.175] –>STARTTLS
[000.185]<–220 TLS go ahead
[000.186]STARTTLS command works on this server
[000.275]Connection converted to SSL
SSLVersion in use: TLSv1
Cipher in use: DHE-RSA-AES256-SHA
Certificate 1 of 3 in chain: Cert VALIDATED: ok
Cert Hostname VERIFIED (eggs.gnu.org = eggs.gnu.org | DNS:eggs.gnu.org | DNS:mail.gnu.org)
cert not revoked by CRL
cert not revoked by OCSP
serialNumber=03:f9:06:4d:6c:6d:1e:1c:83:03:50:8a:32:c0:d5:a9:da:99
subject= /CN=eggs.gnu.org
issuer= /C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
Certificate 2 of 3 in chain: Cert VALIDATED: ok
cert not revoked by CRL
cert not revoked by OCSP
serialNumber=0a:01:41:42:00:00:01:53:85:73:6a:0b:85:ec:a7:08
subject= /C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
Certificate 3 of 3 in chain: Cert VALIDATED: ok
cert not revoked by CRL
cert not revoked by OCSP
serialNumber=44:af:b0:80:d6:a3:27:ba:89:30:39:86:2e:f8:40:6b
subject= /O=Digital Signature Trust Co./CN=DST Root CA X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3

wenn man mal genauer hinsieht mit :  „openssl s_client -connect eggs.gnu.org:25 -starttls smtp -tls1“

Subject=/CN=eggs.gnu.org
….
New, SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
….
250 HELP

sieht dann auch, daß der Cipher noch aus SSLv3 Zeiten stammt, was nicht verwundert, weil TLS 1.0 nur SSLv3 mit SNI Support ist.

Falls jemand von Euch jemand den GNU Leuten Emails schicken will, machts gleich in Klartext 😀

1&1 Mails von Spamhaus geblockt.. was nun ?

Info aus der Spamwelt: 1&1 Mailserver bei Spamhaus auf der Blockliste gelandet, und jetzt ??

1&1 Mailserver von Spamhaus geblockt

Wie wir heute von Kunden meines Arbeitgebers erfahren haben, können diese über 1&1 keine Mails mehr an bestimmte Adressen senden. Da haben wir mal nachgesehen und mußten feststellen, daß Spamhaus die IP’s der Mailserver von  1&1 gesperrt hat:

2019-01-09 10:01:11 H=mout-xforward.kundenserver.de [82.165.159.37] X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no F= rejected RCPT <empfänger@unserserver.eu>: found in zen.spamhaus.org</empfänger@unserserver.eu>
2019-01-09 10:02:03 H=mout-xforward.kundenserver.de [82.165.159.43] X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no F= rejected RCPT <empfänger@unserserver.eu>: found in zen.spamhaus.org</empfänger@unserserver.eu>

Es handelt sich um ein /30 Subnetz, daß von 1&1 zu einem einzigen Zweck benutzt wird. Interessant wird es,wenn man bei Spamhaus den Grund für die Sperre einsieht:

Blocklist Lookup Results

82.165.159.37 is listed in the SBL, in the following records:

    SBL275659

82.165.159.37 is not listed in the PBL
82.165.159.37 is not listed in the XBL

Der von 1&1 verwendete Netzblock ist bereits seit Anfang 2017 gesperrt, wie man dem Link oben entnehmen kann. Das liegt daran, daß 1&1 diesen Block nur benutzt, wenn die Emails intern bei 1&1 als Spams bewertet wurden. Daher kann auch nur 1&1 helfen.

Ref: SBL275659
82.165.159.36/30 is listed on the Spamhaus Block List – SBL
2017-02-09 23:24:04 GMT | courtesy.spamhaus.org
mout-xforward.kundenserver.de

The IP addresses listed in this SBL are used by 1&1 solely for delivering emails that have been internally (by 1&1) classified as SPAM.

You have been referred to this page for one of the following reasons:

a) Your own legitimate emails have been erroneously classified as SPAM by 1&1’s systems. In this case please contact 1&1 directly using the following link to clear up the matter:

http://postmaster.1und1.de/en/blacklisting/?ip=82.165.159.36&c=sbl

b) You found non-delivery reports „bounces“ in your mailbox for messages other than your own. This indicates that a third party has sent these emails through your mailbox without your consent. Please take the following steps to re-establish the security of your 1&1 mailbox:

i) Check your computer for viruses:
Perform a thorough anti-virus scan on all computers which have been used to access the mailbox.

ii) Choose a new password for the affected mailbox.

Please carefully note that if you contact Spamhaus regarding this SBL listing, you will not receive any answer and the listing will not be removed. Your only resolution path is through 1&1, as indicated above.

 

Jetzt stellt sich natürlich sofort die Frage:

Wieso 1&1 als Spam erkannte EMails überhaupt rausschickt ?

Die Sache ist eigentlich ganz clever:

  1. Kundenemails gehen erstmal raus, ohne daß es eine Fehlermeldung gibt.
  2. Der eigene Mailcluster für „normale“ Emails wird nicht (oder eher seltener) von Blacklistenbetreibern geblockt.
  3. Nutzer von Spamhaus und anderen IP basierten Blacklisten bekommen diese „Spams“ nicht.

Das sieht erstmal wie ein Win – Win aus.. aber eigentlich gewinnt nur 1&1, denn die haben erstmal keinen Supportaufwand ( das habe ich natürlich direkt geändert 😀 ), der landet jetzt erstmal bei dem, bei dem die Email nicht angekommen ist und natürlich dem Absender, der hat den meisten Ärger.

Der Absender muß den Empfänger anrufen, weil mailen geht ja nicht. Der Supporter vom Empfänger muß jetzt losgehen, seine Logs checken und findet den Block von Spamhaus, fragt Spamhaus und gibt dem Absender zurück, daß ist sein Problem, er solle mal 1&1 fragen.  Bumerangmäßig kommt der Aufwand wieder bei 1und1 an.

Ich lehne mich mal ganz weit aus dem Fenster und behaupte..

… das liegt alles an BWL ( Betriebswirtschaftslehre ) und deren Mantra „Kosten, die nicht bei mir anfallen, sind keine Kosten.“ .

Ich denke mir das so: Die Abteilung von 1&1 , welche die Mailserver betreut, hat das eingerichtet, damit die Anfragen, wieso Emails nicht angekommen sind, erstmal beim Allgemeinen Supporttelefon landen. Das dürfte eine andere Abteilung sein. Die filtern erstmal alle weg, die nur mal eine Email zurück bekommen haben.

Bei den ganz harten Fälle haben Andere den Hauptteil der Arbeit schon für die erledigt: Sie wissen woran es lag => Spamklassifizierung von 1&1 . Damit muß der Level 2 des Technischen Supports nicht mehr lange suchen, was Zeit und Geld spart. Die Kosten dafür wurden auf den Kunden und ganz elegant auf die Supportabteilung von einem völlig anderen Unternehmen abgewälzt. Übrig bleibt ein kleiner Rest, der Minimal im Vergleich zum großen Gesamtbetrag ist. Spiel, Satz und Sieg 1&1 🙁

Was wäre wenn..

Allerdings würden alle Anderen gar keine Kosten mehr haben, wenn 1&1 die erkannten Spams gleich zurück an den Absender schickt und klar reinschreibt, daß es Spams waren. Das würde aber Kundenunzufriedenheit fördern und in der Endkonsequenz bedeutet, daß sich Kunden in Foren beschweren, daß man über 1&1 Mailserver keine Mails mehr raussenden könnte. Schlecht fürs Geschäft, insofern ist das für 1&1 natürlich erstmal die bessere Lösung, die Emails rauszusenden und zu schauen was passiert, zumal 1&1 sichergestellt hat, daß der Kunde nicht von Ihnen trotzdem den wahren Grund ( Spam ) erfährt.  Jetzt entlädt sich der Frust darüber, daß ein anderer Mailserver die Emails als Spam zurück gesendet hat, beim Empfänger und nachdem klar ist, was passiert ist, ist dessen Frustlevel schon wieder gesunken, wenn er sich dann beim 1&1 Support meldet.

Ich überlege gerade, im nächsten Meeting eine ähnliche Struktur vorzuschlagen, da man als „Absenderprovider“ damit nur gewinnen kann, während alle anderen verlieren 🙁

Mozillas Bugtracker zu blöd für TLS

Also da könnte man aus der Haut fahren. Wir haben das Jahr 2018. In 2008 wurde TLS 1.2 als Stand der Technik eingeführt und was bekommt man, wenn sich in den Bugtracker von Mozilla einloggen will ??? DAS HIER :

Your account has been disabled

Your Bugzilla account has been disabled due to issues delivering emails to your address.

Your mail server (dsn; a27-61.smtp-out.us-west-2.amazonses.com) said: (failed) smtp; 550-Sender did not use TLS secured connection. Sender benutzte keine TLS 550 gesicherte Verbindung.


If you believe your account should be restored, please send email to bugzilla-admin@mozilla.org explaining why.

 

Klar failed das, weil die Mozilla Admins zu blöd sind um TLS beim Senden in Ihrem Mailserver zu aktivieren! In 2018! Und nächstes Jahr ist TLS 1.3 draußen. Au Backe.. wozu macht die IETF das wohl neu .. zum Spaß wohl kaum!? Und zu allem übel ist die Meldung auch noch falsch, weil das da DEREN MAILSERVER IST! 😀

Jetzt überlegt mal was das heißt, wenn ein Security Bug von weltweiten Ausmaß besprochen wird. Was machen die dann, sich im Nebel unter einer Londoner Brücke treffen ?

Wo wir grade dabei sind :

Der SystemD Bugzilla hatte da wohl ein größeres DATENLECK :

reject.log-20180909:2018-09-04 00:11:32 H=mail.logite.biz.ua [89.163.132.50] F=<amsizcz@logite.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: found in zen.spamhaus.org</systemdbugzilla@
reject.log-20180909:2018-09-05 02:30:21 H=mail.windersale.biz.ua [217.79.182.196] F=<iskohmf@windersale.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180909:2018-09-05 18:39:10 H=mail.zimerton.biz.ua [89.163.142.60] F=<exbiclz@zimerton.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180909:2018-09-06 20:00:27 H=mail.axiroks.co.ua [217.79.181.114] F=<ablojmp@axiroks.co.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180916:2018-09-09 22:24:27 H=mail.aquaclean.biz.ua [62.141.32.162] F=<ynmipfy@aquaclean.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180916:2018-09-09 22:58:07 H=mail.derosman.co.ua [5.104.110.186] F=<aysixkc@derosman.co.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180916:2018-09-11 02:40:28 H=mail.windersale.biz.ua [217.79.182.196] F=<etkuxnw@windersale.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180916:2018-09-12 10:29:33 H=mail.alihost.co.ua [213.202.212.238] F=<ivdewmw@alihost.co.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180916:2018-09-13 01:08:28 H=mail.windersale.biz.ua [217.79.182.196] F=<yrxocts@windersale.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180916:2018-09-14 00:36:32 H=mail.mafines.eu [213.202.212.252] F=<odyizfm@mafines.eu> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180923:2018-09-16 22:07:58 H=mail.shophostel.eu [89.163.131.100] F=<iwpekfy@shophostel.eu> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180923:2018-09-17 22:24:23 H=mail.kollisar.biz.ua [213.202.212.143] F=<ephorkm@kollisar.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180923:2018-09-19 03:44:26 H=mail.axiroks.co.ua [217.79.181.114] F=<ypficrx@axiroks.co.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180923:2018-09-21 02:58:35 H=mail.windersale.biz.ua [217.79.182.196] F=<uvbiczw@windersale.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180930:2018-09-23 23:52:36 H=mail.alihost.co.ua [213.202.212.238] F=<upyyzdr@alihost.co.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180930:2018-09-25 03:05:04 H=mail.developmnt.eu [62.141.46.214] F=<opvojcx@developmnt.eu> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180930:2018-09-25 18:04:27 H=mail.mafines.eu [213.202.212.252] F=<ytvelrs@mafines.eu> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180930:2018-09-25 18:10:29 H=mail.gorgyam.eu [5.199.135.188] F=<ympyrmv@gorgyam.eu> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180930:2018-09-27 01:50:59 H=mail.axiroks.co.ua [217.79.181.114] F=<alpafcb@axiroks.co.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@

(Der Editor von WordPress verweigert den Text in seiner Rohform zu zeigen und will unbedingt das nicht existente Tag schliessen. All Fail WordPress! )

SO! muß das aussehen Mozilla!

2018-09-22 00:21:23 1g3Tnc-0005cl-8K <= bugzilla@redhat.com H=mx1-phx2.redhat.com [209.132.183.26] P=esmtps X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no S=3923 id=bug-1599018-321468-Fft8v2y8dX@bugzilla.redhat.com

Damit die Admins bei Mozillapost bekommen, sind sie bei GOOGLE untergekommen :

2018-10-03 10:23:49 1g7cRf-0000Gr-Qb => bugzilla-admin@mozilla.org R=dnslookup T=remote_smtp H=aspmx.l.google.com [74.125.133.27] X=TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256 CV=yes K C=“250 2.0.0 OK l18-v6si623134wre.19 – gsmtp“

Und jetzt steht euch mal den Chiper an : „First Time spotted“ CHACHA20-POLY1305 . „Was ist das denn fürn Exot ?“ werdet Ihr Euch fragen… ja, das ist eine GOOGLE Erfindung. Wie man da lesen kann, nicht mal ein Standard, sondern nur eine Info 😉 Naja, scheint ja von OpenSSL implementiert worden zu sein.