Hallo Liste, Google blockt in letzter Zeit Mails von meinem Server an Gmail Accounts.
***@gmail.com: host gmail-smtp-in.l.google.com[2a00:1450:400c:c09::1b] said: 550-5.7.1 [2a01:4f8:c17:12f8::2 12] Our system has detected that this 550-5.7.1 message is likely unsolicited mail. To reduce the amount of spam sent 550-5.7.1 to Gmail, this message has been blocked. Please visit 550-5.7.1 https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1 for more information. q9si858297wmf.73 - gsmtp (in reply to end of DATA command)
Hat jemand eine Idee was die da prüfen um zu dem Ergebnis zu kommen?
Jochen
* J. Fahrner jf@fahrner.name:
Hallo Liste, Google blockt in letzter Zeit Mails von meinem Server an Gmail Accounts.
***@gmail.com: host gmail-smtp-in.l.google.com[2a00:1450:400c:c09::1b] said: 550-5.7.1 [2a01:4f8:c17:12f8::2 12] Our system has detected that this 550-5.7.1 message is likely unsolicited mail. To reduce the amount of spam sent 550-5.7.1 to Gmail, this message has been blocked. Please visit 550-5.7.1 https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1 for more information. q9si858297wmf.73 - gsmtp (in reply to end of DATA command)
Hat jemand eine Idee was die da prüfen um zu dem Ergebnis zu kommen?
Hast Du SPF und DKIM am Start?
p@rick
* J. Fahrner jf@fahrner.name:
Am 2019-02-27 13:13, schrieb Patrick Ben Koetter:
Hast Du SPF und DKIM am Start?
Ja beides.
Bist Du zum Feedback Loop bei Google angemeldet? Dann kannst Du ggf. den wahren Grund recherchieren.
p@rick
On 27.02.2019 13:22, J. Fahrner wrote:
Am 2019-02-27 13:13, schrieb Patrick Ben Koetter:
Hast Du SPF und DKIM am Start?
Ja beides.
kannst Du exakt so ein Mail welches da zurückgeknallt wird vom strukturellen Inhalt zeigen Format - html, plain sind Links vorhanden, wohin gehen diese? etwaige Felder im Header können hier relevant sein
* J. Fahrner jf@fahrner.name:
Am 2019-02-27 13:13, schrieb Patrick Ben Koetter:
Hast Du SPF und DKIM am Start?
Ja beides.
DMARC?
p@rick
Am 2019-02-27 13:56, schrieb Patrick Ben Koetter:
- J. Fahrner jf@fahrner.name:
Am 2019-02-27 13:13, schrieb Patrick Ben Koetter:
Hast Du SPF und DKIM am Start?
Ja beides.
DMARC?
Laut appmaildev.com Prüfreport ist alles in Ordnung. Ich sehe da keinen Grund warum Google das ablehnen sollte.
============================================================================ This is SPF/DKIM/DMARC/RBL report generated by a test tool provided by AdminSystem Software Limited.
Any problem, please contact support@emailarchitect.net ============================================================================ Report-Id: 3c6fe315 Sender: xxx@fahrner.name Header-From: xxx@fahrner.name HELO-Domain: server.fahrner.name Source-IP: 88.198.89.240 Validator-Version: 1.08 ============================================================================ Original email header:
x-sender: xxx@fahrner.name x-receiver: test-3c6fe315@appmaildev.com Received: from server.fahrner.name ([88.198.89.240]) by appmaildev.com with Microsoft SMTPSVC(8.5.9600.16384); Wed, 27 Feb 2019 12:33:09 +0000 Received: from roundcube.fahrner.name (localhost.localdomain [127.0.0.1]) by server.fahrner.name (Postfix) with ESMTP id 11DAF101F60 for test-3c6fe315@appmaildev.com; Wed, 27 Feb 2019 13:33:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fahrner.name; s=dkim; t=1551270789; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references; bh=cJ1CPihF7oM5a/4pQaRuKUhDnJoeSUjAYsNqUkn49iE=; b=qgWNi3NVBdRc6xRDcHObZESb6QTiYhb3oRJhJHJaznWZRPC8NfgBWT/Plp6OwzzeczM+T7 qfNSiSsywadC+u/YH2CddJNBU7u0OAk16nm8mL06c0iDZfPdz7myYVtgonbR3Nrq4MuMYa c9nh6c6RcMgM5Ejz3dendKZkgBGtQak= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 27 Feb 2019 13:33:08 +0100 From: Joachim Fahrner xxx@fahrner.name To: test-3c6fe315@appmaildev.com Subject: Test DKIM Message-ID: 09a9d9b5b738db5bf089952c055375bc@fahrner.name X-Sender: xxx@fahrner.name User-Agent: Roundcube Webmail/1.3.8 Return-Path: xxx@fahrner.name X-OriginalArrivalTime: 27 Feb 2019 12:33:10.0267 (UTC) FILETIME=[994984B0:01D4CE98]
============================================================================ SPF: Pass ============================================================================
SPF-Record: v=spf1 mx -all Sender-IP: 88.198.89.240 Sender-Domain-Helo-Domain: fahrner.name
Query TEXT record from DNS server for: fahrner.name [TXT]: google-site-verification=WA1zKN0guMFR7X0wUgBCQzWvxAUcnlwkC2ZFscfCXEs [TXT]: v=spf1 mx -all Parsing SPF record: v=spf1 mx -all
Mechanisms: v=spf1
Mechanisms: mx Testing mechanism mx Query MX record from DNS server for: fahrner.name [MX]: server.fahrner.name Testing mechanism A:server.fahrner.name/128 Query A record from DNS server for: server.fahrner.name [A]: 88.198.89.240 Testing CIDR: source=88.198.89.240; 88.198.89.240/128 mx hit, Qualifier: +
============================================================================ DKIM: pass ============================================================================
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fahrner.name; s=dkim; t=1551270789; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references; bh=cJ1CPihF7oM5a/4pQaRuKUhDnJoeSUjAYsNqUkn49iE=; b=qgWNi3NVBdRc6xRDcHObZESb6QTiYhb3oRJhJHJaznWZRPC8NfgBWT/Plp6OwzzeczM+T7 qfNSiSsywadC+u/YH2CddJNBU7u0OAk16nm8mL06c0iDZfPdz7myYVtgonbR3Nrq4MuMYa c9nh6c6RcMgM5Ejz3dendKZkgBGtQak= Signed-by: xxx@fahrner.name Expected-Body-Hash: cJ1CPihF7oM5a/4pQaRuKUhDnJoeSUjAYsNqUkn49iE= Public-Key: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCveg3UhG1yz4KDznQwnd4u2CwBUeb0UhdFU8Ml6gbSBs7v/DlftlDdJxKS+FRfE6e38Jx9k6qR1lXwDSFEOl1LkhzSZJasNLhOA26jYC6l3vYrbSO9asl9PkWe1tHjBfkg5gqVDCxvMgiAONe+WMyEXbwLksFIKh7L5PCZPrmn3QIDAQAB;
DKIM-Result: pass
============================================================================ DMARC: pass ============================================================================
_dmarc.fahrner.name: v=DMARC1;p=none Received-SPF: pass (appmaildev.com: domain of xxx@fahrner.name designates 88.198.89.240 as permitted sender) client-ip=88.198.89.240 Authentication-Results: appmaildev.com; dkim=pass header.d=fahrner.name; spf=pass (appmaildev.com: domain of xxx@fahrner.name designates 88.198.89.240 as permitted sender) client-ip=88.198.89.240; dmarc=pass (adkim=r aspf=r p=none) header.from=fahrner.name;
============================================================================ DomainKey: none ============================================================================
DomainKey-Result: none (no signature) If DKIM result is passed, you can ignore DomainKey result: none
============================================================================ PTR: ExistsRecord ============================================================================
Sender-IP: 88.198.89.240 Query 240.89.198.88.in-addr.arpa Host: server.fahrner.name
============================================================================ RBL: NotListed ============================================================================
bl.spamcop.net:Not Listed (OK) - http://bl.spamcop.net cbl.abuseat.org:Not Listed (OK) - http://cbl.abuseat.org b.barracudacentral.org:Not Listed (OK) - http://www.barracudacentral.org/rbl/removal-request dnsbl.sorbs.net:Not Listed (OK) - http://www.sorbs.net http.dnsbl.sorbs.net:Not Listed (OK) - http://www.sorbs.net dul.dnsbl.sorbs.net:Not Listed (OK) - http://www.sorbs.net misc.dnsbl.sorbs.net:Not Listed (OK) - http://www.sorbs.net smtp.dnsbl.sorbs.net:Not Listed (OK) - http://www.sorbs.net socks.dnsbl.sorbs.net:Not Listed (OK) - http://www.sorbs.net spam.dnsbl.sorbs.net:Not Listed (OK) - http://www.sorbs.net web.dnsbl.sorbs.net:Not Listed (OK) - http://www.sorbs.net zombie.dnsbl.sorbs.net:Not Listed (OK) - http://www.sorbs.net pbl.spamhaus.org:Not Listed (OK) - http://www.spamhaus.org/pbl/ sbl.spamhaus.org:Not Listed (OK) - http://www.spamhaus.org/sbl/ xbl.spamhaus.org:Not Listed (OK) - http://www.spamhaus.org/xbl/ zen.spamhaus.org:Not Listed (OK) - http://www.spamhaus.org/zen/ ubl.unsubscore.com:Not Listed (OK) - http://www.lashback.com/blacklist/ rbl.spamlab.com:Not Listed (OK) - http://tools.appriver.com/index.aspx?tool=rbl dyna.spamrats.com:Not Listed (OK) - http://www.spamrats.com noptr.spamrats.com:Not Listed (OK) - http://www.spamrats.com spam.spamrats.com:Not Listed (OK) - http://www.spamrats.com dnsbl.inps.de:Not Listed (OK) - http://dnsbl.inps.de/index.cgi?lang=en drone.abuse.ch:Not Listed (OK) - http://dnsbl.abuse.ch httpbl.abuse.ch:Not Listed (OK) - http://dnsbl.abuse.ch korea.services.net:Not Listed (OK) - http://korea.services.net spamrbl.imp.ch:Not Listed (OK) - http://antispam.imp.ch wormrbl.imp.ch:Not Listed (OK) - http://antispam.imp.ch virbl.bit.nl:Not Listed (OK) - http://virbl.bit.nl rbl.suresupport.com:Not Listed (OK) - http://suresupport.com/postmaster dsn.rfc-ignorant.org:Not Listed (OK) - http://www.rfc-ignorant.org/policy-dsn.php spamguard.leadmon.net:Not Listed (OK) - http://www.leadmon.net/SpamGuard/ dnsbl.tornevall.org:Not Listed (OK) - http://opm.tornevall.org netblock.pedantic.org:Not Listed (OK) - http://pedantic.org multi.surbl.org:Not Listed (OK) - http://www.surbl.org ix.dnsbl.manitu.net:Not Listed (OK) - http://www.dnsbl.manitu.net tor.dan.me.uk:Not Listed (OK) - http://www.dan.me.uk/dnsbl rbl.efnetrbl.org:Not Listed (OK) - http://rbl.efnetrbl.org dnsbl.dronebl.org:Not Listed (OK) - http://www.dronebl.org access.redhawk.org:Not Listed (OK) - http://www.redhawk.org/index.php?option=com_wrapper&Itemid=33 db.wpbl.info:Not Listed (OK) - http://www.wpbl.info rbl.interserver.net:Not Listed (OK) - http://rbl.interserver.net query.senderbase.org:Not Listed (OK) - http://www.senderbase.org/about bogons.cymru.com:Not Listed (OK) - http://www.team-cymru.org/Services/Bogons/ csi.cloudmark.com:Not Listed (OK) - http://www.cloudmark.com/en/products/cloudmark-sender-intelligence/index
cbl.anti-spam.org.cn:DnsTimeout - http://www.anti-spam.org.cn/?Locale=en_US cdl.anti-spam.org.cn:DnsTimeout - http://www.anti-spam.org.cn/?Locale=en_US short.rbl.jp:DnsTimeout - http://www.rbl.jp virus.rbl.jp:DnsTimeout - http://www.rbl.jp
============================================================================ Original message source ============================================================================ x-sender: xxx@fahrner.name x-receiver: test-3c6fe315@appmaildev.com Received: from server.fahrner.name ([88.198.89.240]) by appmaildev.com with Microsoft SMTPSVC(8.5.9600.16384); Wed, 27 Feb 2019 12:33:09 +0000 Received: from roundcube.fahrner.name (localhost.localdomain [127.0.0.1]) by server.fahrner.name (Postfix) with ESMTP id 11DAF101F60 for test-3c6fe315@appmaildev.com; Wed, 27 Feb 2019 13:33:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fahrner.name; s=dkim; t=1551270789; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references; bh=cJ1CPihF7oM5a/4pQaRuKUhDnJoeSUjAYsNqUkn49iE=; b=qgWNi3NVBdRc6xRDcHObZESb6QTiYhb3oRJhJHJaznWZRPC8NfgBWT/Plp6OwzzeczM+T7 qfNSiSsywadC+u/YH2CddJNBU7u0OAk16nm8mL06c0iDZfPdz7myYVtgonbR3Nrq4MuMYa c9nh6c6RcMgM5Ejz3dendKZkgBGtQak= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 27 Feb 2019 13:33:08 +0100 From: Joachim Fahrner xxx@fahrner.name To: test-3c6fe315@appmaildev.com Subject: Test DKIM Message-ID: 09a9d9b5b738db5bf089952c055375bc@fahrner.name X-Sender: xxx@fahrner.name User-Agent: Roundcube Webmail/1.3.8 Return-Path: xxx@fahrner.name X-OriginalArrivalTime: 27 Feb 2019 12:33:10.0267 (UTC) FILETIME=[994984B0:01D4CE98]
Test DKIM
============================================================================
* J. Fahrner jf@fahrner.name:
Am 2019-02-27 13:56, schrieb Patrick Ben Koetter:
- J. Fahrner jf@fahrner.name:
Am 2019-02-27 13:13, schrieb Patrick Ben Koetter:
Hast Du SPF und DKIM am Start?
Ja beides.
DMARC?
Laut appmaildev.com Prüfreport ist alles in Ordnung. Ich sehe da keinen Grund warum Google das ablehnen sollte.
Ich kann (da unten) auch keinen Grund erkennen. Wenn jetzt nicht jemand aufspringt und mit dem Finger auf etwas deutet, was wir übersehen haben, dann hilft wohl nur eine Runde Feedback Loop.
Generell kann ich sagen, dass Google eine Runde strenger geworden ist. Das war vergangene Woche auch ein Thema auf der M³AAWG-Konferenz in San Francisco. Google steht mit "strenger" aber nicht alleine da. Viele US-Provider ziehen die Daumenschrauben an. Sie wollen Phishing und Spoofing eindämmen.
Ich sehe das auch, wenn ich mir die Tickets bei uns im Plattform-Support ansehe. Über alle Mailplattformen hinweg messen wir einen signifikanten Anstieg an Zustellproblemen in Richtung Google, Microsoft und Yahoo.
Perfiderweise argumentieren sie dann mit einem Wechsel auf deren Infrastrukturen und sagen, dann seien die Probleme weg. Das hinterläßt ein wenig den faden Nachgeschmack von Erpressung.
p@rick
Patrick Ben Koetter - 27.02.19, 14:16:
Generell kann ich sagen, dass Google eine Runde strenger geworden ist. Das war vergangene Woche auch ein Thema auf der M³AAWG-Konferenz in San Francisco. Google steht mit "strenger" aber nicht alleine da. Viele US-Provider ziehen die Daumenschrauben an. Sie wollen Phishing und Spoofing eindämmen.
Ich sehe das auch, wenn ich mir die Tickets bei uns im Plattform-Support ansehe. Über alle Mailplattformen hinweg messen wir einen signifikanten Anstieg an Zustellproblemen in Richtung Google, Microsoft und Yahoo.
Perfiderweise argumentieren sie dann mit einem Wechsel auf deren Infrastrukturen und sagen, dann seien die Probleme weg. Das hinterläßt ein wenig den faden Nachgeschmack von Erpressung.
Noch dazu hatte ich es immer wieder mal auch mit einem Spammer, der ein Google-Konto verwendet, zu tun. Google war dabei alles anderes als hilfreich, weswegen ich mittlerweile einen solchem Spammer ohne Rücksprache mit Google blocke.
Mit anderen Worten: Wer da anzieht, sollte auch vor der eigenen Haustür kehren.
Am 2019-02-27 15:06, schrieb Martin Steigerwald:
Noch dazu hatte ich es immer wieder mal auch mit einem Spammer, der ein Google-Konto verwendet, zu tun. Google war dabei alles anderes als hilfreich, weswegen ich mittlerweile einen solchem Spammer ohne Rücksprache mit Google blocke.
Mit anderen Worten: Wer da anzieht, sollte auch vor der eigenen Haustür kehren.
Die Beobachtung kann ich bestätigen. Die sollten sich erstmal auf ihren ausgehenden Spam konzentrieren, bevor sie die Hürden inbound ins Unermessliche steigern. Das blöde ist ja, dass Google bei Mails mittlerweile so groß ist, dass man es nicht mehr ignorieren kann, und sich mit deren Sch... Hürden zeitintensiv auseinandersetzen muss. :-(
Jetzt soll ich mich auch noch bei ihrem Drecks Postmaster Tool anmelden und meine Domain da registrieren. Das allein ist ja schon eine Frechheit. Man stelle sich mal vor, alle würden das so machen: Microsoft, Yahoo, GMX, Web.de, Posteo... da würde man ja nicht mehr fertig werden. Und dann funktioniert deren Tool noch nicht mal gescheit. Habe wie befohlen einen TXT-Record in mein DNS eingefügt (man stelle sich wieder vor, jeder würde das verlangen), und jetzt warte ich schon seit Stunden darauf, dass die Domain akzeptiert wird. Obwohl der TXT-Record im Internet von jeder Online-DNS-Abfrage gesehen wird, kann Google den immer noch nicht finden.
"Das Prüftoken in den TXT-Einträgen Ihrer Domain konnte nicht gefunden werden. Sie müssen eventuell einige Minuten warten, bevor Ihre Änderungen in den TXT-Einträgen wirksam werden.".
Dreck, Dreck, dreckerter Dreck!
Jochen
J. Fahrner - 27.02.19, 15:25:
Am 2019-02-27 15:06, schrieb Martin Steigerwald:
Noch dazu hatte ich es immer wieder mal auch mit einem Spammer, der ein Google-Konto verwendet, zu tun. Google war dabei alles anderes als hilfreich, weswegen ich mittlerweile einen solchem Spammer ohne Rücksprache mit Google blocke.
Mit anderen Worten: Wer da anzieht, sollte auch vor der eigenen Haustür kehren.
Die Beobachtung kann ich bestätigen. Die sollten sich erstmal auf ihren ausgehenden Spam konzentrieren, bevor sie die Hürden inbound ins Unermessliche steigern. Das blöde ist ja, dass Google bei Mails mittlerweile so groß ist, dass man es nicht mehr ignorieren kann, und sich mit deren Sch... Hürden zeitintensiv auseinandersetzen muss.
Jetzt soll ich mich auch noch bei ihrem Drecks Postmaster Tool anmelden und meine Domain da registrieren. Das allein ist ja schon eine Frechheit. Man stelle sich mal vor, alle würden das so machen: Microsoft, Yahoo, GMX, Web.de, Posteo... da würde man ja nicht mehr fertig werden. Und dann funktioniert deren Tool noch nicht mal gescheit. Habe wie befohlen einen TXT-Record in mein DNS eingefügt (man stelle sich wieder vor, jeder würde das verlangen), und jetzt warte ich schon seit Stunden darauf, dass die Domain akzeptiert wird. Obwohl der TXT-Record im Internet von jeder Online-DNS-Abfrage gesehen wird, kann Google den immer noch nicht finden.
Ich hab zur Zeit keine Einliefer-Probleme bei Google, von denen ich wüsste. Ein Web-Formular habe ich damals zum Melden von Spam nicht verwendet. Ich glaube, da hätte ich damals auch ein Google-Konto gewollt, was ich schlicht nicht mehr habe.
Ich hab damals nach einigen Recherchen security@google.com gefunden und dort hin geschrieben, die haben mir für den vom Google-Konto ausgehenden Spam damals nur gesagt, mach halt SPF. Frecherweise hatte der nämlich als Absender *meine* Mail-Adresse eingetragen. Hab ich SPF strikt gemacht, was half. Dann gingen aber Mails über KDE-Mailinglisten-Server nicht. Also habe ich das wieder als nicht strikt gemacht.
Vergleich zu Mailchimp, von denen ich auch kein Fan bin: Spam-Report an Abuse-Mail-Adresse geschickt. Innerhalb von Stunden eine Antwort bekommen, dass sie der Sache nachgehen und den Absender für den Versand an meine Adresse erst mal geblockt haben.
Es geht also auch anders.
Ciao,
On 27.02.2019 15:06, Martin Steigerwald wrote:
Noch dazu hatte ich es immer wieder mal auch mit einem Spammer, der ein Google-Konto verwendet, zu tun. Google war dabei alles anderes als hilfreich, weswegen ich mittlerweile einen solchem Spammer ohne Rücksprache mit Google blocke. Mit anderen Worten: Wer da anzieht, sollte auch vor der eigenen Haustür kehren.
so sehe ich das auch, mir fällt nämlich im Log meines Mailservers folgendes auf
Google-Server, Outlook.com (MS)-Server od. Yahoo-Server wollen Mails mit Absender des jeweils anderen einliefern ...
Im Auftrag von Patrick Ben Koetter
- J. Fahrner jf@fahrner.name:
Am 2019-02-27 13:56, schrieb Patrick Ben Koetter:
- J. Fahrner jf@fahrner.name:
Am 2019-02-27 13:13, schrieb Patrick Ben Koetter:
Hast Du SPF und DKIM am Start?
Ja beides.
DMARC?
Laut appmaildev.com Prüfreport ist alles in Ordnung. Ich sehe da keinen Grund warum Google das ablehnen sollte.
Ich kann (da unten) auch keinen Grund erkennen. Wenn jetzt nicht jemand aufspringt und mit dem Finger auf etwas deutet, was wir übersehen haben, dann hilft wohl nur eine Runde Feedback Loop.
PTR auch kontrolliert ? Von Jemandem auf Spam gesetzt worden :-)
War die letzte woche auch aufs Peers Liste ein Thema :-)
Generell kann ich sagen, dass Google eine Runde strenger geworden ist. Das war vergangene Woche auch ein Thema auf der M³AAWG-Konferenz in San Francisco. Google steht mit "strenger" aber nicht alleine da. Viele US-Provider ziehen die Daumenschrauben an. Sie wollen Phishing und Spoofing eindämmen.
So so ? wollen die das ??? Dabei kommt der meiste Mist doch von denen mit ihren kostenlosen Mailkonten :-(
Ich sehe das auch, wenn ich mir die Tickets bei uns im Plattform-Support ansehe. Über alle Mailplattformen hinweg messen wir einen signifikanten Anstieg an Zustellproblemen in Richtung Google, Microsoft und Yahoo.
Perfiderweise argumentieren sie dann mit einem Wechsel auf deren Infrastrukturen und sagen, dann seien die Probleme weg. Das hinterläßt ein wenig den faden Nachgeschmack von Erpressung.
Tja wir haben Google groß gemacht nun ernten wir die Früchte unseres Tuns :-)
Ich hab schon vor längerer Zeit gesagt es wird mal zeit das wir denen die Server zum Überlaufen bringen Wir gehen wegen jedem Scheiß auf die Straße .... Nur bei so was werden wir uns nicht einig das da mal alle sich die auf den Mail-serverlisten sind zusammen tun :-)
Wenn wir streiken dann liegen auch die Großen auf der Nase
p@rick
Mit freundlichen Grüßen
Uwe Drießen -- Software & Computer
Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner !
Uwe Drießen Lembergstraße 33 67824 Feilbingert
Tel.: 06708660045
Am 27.02.19 um 12:46 schrieb J. Fahrner:
Hallo Liste, Google blockt in letzter Zeit Mails von meinem Server an Gmail Accounts.
***@gmail.com: host gmail-smtp-in.l.google.com[2a00:1450:400c:c09::1b] said: 550-5.7.1 [2a01:4f8:c17:12f8::2 12] Our system has detected that this 550-5.7.1 message is likely unsolicited mail. To reduce the amount of spam sent 550-5.7.1 to Gmail, this message has been blocked. Please visit 550-5.7.1 https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1 for more information. q9si858297wmf.73 - gsmtp (in reply to end of DATA command)
Hat jemand eine Idee was die da prüfen um zu dem Ergebnis zu kommen?
Jochen
google hat zb mal pauschal etliche Hetzner Ips/Netze gesperrt da musste man eine form ausfuellen...hab ich aber grad nicht parat
Am 2019-02-27 18:56, schrieb Robert Schetterer:
google hat zb mal pauschal etliche Hetzner Ips/Netze gesperrt
Meiner ist bei Hetzner. Das wäre ja ne schöne Sauerei :-(
Am 2019-02-27 19:40, schrieb J. Fahrner:
Am 2019-02-27 18:56, schrieb Robert Schetterer:
google hat zb mal pauschal etliche Hetzner Ips/Netze gesperrt
Meiner ist bei Hetzner. Das wäre ja ne schöne Sauerei :-(
Selbst wenn ich mir von Google aus schreibe und dann darauf antworte, wird die Mail abgewiesen. Die sind doch völlig Gaga!
* J. Fahrner jf@fahrner.name:
Am 2019-02-27 19:40, schrieb J. Fahrner:
Am 2019-02-27 18:56, schrieb Robert Schetterer:
google hat zb mal pauschal etliche Hetzner Ips/Netze gesperrt
Meiner ist bei Hetzner. Das wäre ja ne schöne Sauerei :-(
Selbst wenn ich mir von Google aus schreibe und dann darauf antworte, wird die Mail abgewiesen. Die sind doch völlig Gaga!
Irgenwie erinnert mich Dein Verhalten an das Stereotyp von Männer, die lieber 10 mal um den Block kreisen und sich ärgern, weil sie den Weg nicht finden, als einmal anzuhalten und nach dem Weg zu fragen. *SCNR*
Was sagt denn Googles Feedback Loop?
p@rick
Am 2019-02-27 20:38, schrieb Patrick Ben Koetter:
Was sagt denn Googles Feedback Loop?
Keine Ahnung wie man das einrichtet. Liest sich ziemlich kompliziert. Ist mir den Aufwand ehrlich gesagt nicht wert. In den Postmaster Tools wurde die Domain endlich aktiv, aber das hätte ich mir auch sparen können:
"Momentan sind keine Daten zum Anzeigen vorhanden. Versuchen Sie es später noch einmal."
Neue Erkenntnis: wenn ich Postfix nur über ipv4 senden lasse, dann geht die Mail durch. Nur bei ipv6 werden sie geblockt.
Am 28.02.19 um 13:16 schrieb J. Fahrner:
Neue Erkenntnis: wenn ich Postfix nur über ipv4 senden lasse, dann geht die Mail durch. Nur bei ipv6 werden sie geblockt.
ja das ist bekannt...schon seit Jahren so, bei ipv6 ist deren erkennung mist
Zitat von "J. Fahrner" jf@fahrner.name:
Neue Erkenntnis: wenn ich Postfix nur über ipv4 senden lasse, dann geht die Mail durch. Nur bei ipv6 werden sie geblockt.
Ist fast schon so lange wie wir IPv6 haben ein Problem. Bei Google werden immer wieder IPv6 Verbindungen abgewiesen wenn sie ein (temporäres) Problem mit der PTR Auflösung haben. Wir haben deshalb schon seit Jahren einen IPv4 Only Transport für diese technischen Leuchten.
Am 2019-03-01 09:32, schrieb lst_hoe02@kwsoft.de:
Ist fast schon so lange wie wir IPv6 haben ein Problem. Bei Google werden immer wieder IPv6 Verbindungen abgewiesen wenn sie ein (temporäres) Problem mit der PTR Auflösung haben. Wir haben deshalb schon seit Jahren einen IPv4 Only Transport für diese technischen Leuchten.
Ehrlich gesagt ist mir das zu blöd, mein ganzes Postfix-Setup zu verhunzen, nur weil ein Mailprovider zu doof ist IPv6 richtig zu implementieren. Auch wenn der Google heisst.
Könnte man nicht im unbound irgendwas machen, damit für Google keine AAAA-Records geliefert werden?
Jochen
* J. Fahrner jf@fahrner.name:
Am 2019-03-01 09:32, schrieb lst_hoe02@kwsoft.de:
Ist fast schon so lange wie wir IPv6 haben ein Problem. Bei Google werden immer wieder IPv6 Verbindungen abgewiesen wenn sie ein (temporäres) Problem mit der PTR Auflösung haben. Wir haben deshalb schon seit Jahren einen IPv4 Only Transport für diese technischen Leuchten.
Ehrlich gesagt ist mir das zu blöd, mein ganzes Postfix-Setup zu verhunzen, nur weil ein Mailprovider zu doof ist IPv6 richtig zu implementieren. Auch wenn der Google heisst.
Ich denke es ist nicht zulässig von "IPv6 wird bei mir abgelehnt" auf "Mailprovider zu doof (...) IPv6 richtig zu implementieren" zu schliessen. Bei uns läuft google und IPv6 störungsfrei und ich bin sicher, wir haben keinen Feenstaub über unserem Postfix ausgeschüttet.
Einen oder mehrere workaround-Transporte stellen – meine persönliche Meinung – kein "Verhunzuen" dar. Ich denke es gibt einfach zu viel Spielraum für Interpretation im SMTP-Standard und in E-Mails (MIME...), um von einer einzigen Wahrheit ausgehen zu können.
Ich fahre deshalb den Ansatz, dass ich mich auf mein Ziel "ich will sicher transportieren und mit hoher Wahrscheinlicheit zustellen" konzentriere. Ich könnte auch "Recht haben", aber dann habe ich halt Recht und nichts zugestellt.
Könnte man nicht im unbound irgendwas machen, damit für Google keine AAAA-Records geliefert werden?
Möglicherweise. In Postfix hast Du sehr wahrscheinlich in viel kürzerer Zeit eine Lösung umgesetzt.
My 2ct
p@rick
Am 2019-03-01 18:29, schrieb Patrick Ben Koetter:
Ich denke es ist nicht zulässig von "IPv6 wird bei mir abgelehnt" auf "Mailprovider zu doof (...) IPv6 richtig zu implementieren" zu schliessen.
Sorry, aber als Diplom-Informatiker sehe ich das anders. IPv4 oder IPv6 sind nichts anderes als Transportschichten. Semantisch DARF das keinen Unterschied machen. Wenn es das doch tut, dann ist auf einer Seite was faul. Meine Seite habe ich mittlerweile ausgeschlossen, auch reverse DNS ist sichergestellt. Von daher ist für mich, auch andere Berichte bestätigen das, eindeutig Google der Schuldige. Andere Mailhosts machen per IPv6 ja auch keine Probleme.
Ich bleibe bei meiner Meinung, Google ist "zu doof" !!!
Aus Sicht es OSI Models will ich Fahrner Recht geben. IP transportiert nur und wenn auf Anwendungsschicht die Daten anders behandelt werden ist das blöd. Ich sehe auch keinen Grund, warum das jemand machen sollte???
Am 01.03.19 um 19:24 schrieb J. Fahrner:
Am 2019-03-01 18:29, schrieb Patrick Ben Koetter:
Ich denke es ist nicht zulässig von "IPv6 wird bei mir abgelehnt" auf "Mailprovider zu doof (...) IPv6 richtig zu implementieren" zu schliessen.
Sorry, aber als Diplom-Informatiker sehe ich das anders. IPv4 oder IPv6 sind nichts anderes als Transportschichten. Semantisch DARF das keinen Unterschied machen. Wenn es das doch tut, dann ist auf einer Seite was faul. Meine Seite habe ich mittlerweile ausgeschlossen, auch reverse DNS ist sichergestellt. Von daher ist für mich, auch andere Berichte bestätigen das, eindeutig Google der Schuldige. Andere Mailhosts machen per IPv6 ja auch keine Probleme.
Ich bleibe bei meiner Meinung, Google ist "zu doof" !!!
* Denny Hanschke postmaster@blubbablasen.de:
Aus Sicht es OSI Models will ich Fahrner Recht geben. IP transportiert nur und wenn auf Anwendungsschicht die Daten anders behandelt werden ist das blöd. Ich sehe auch keinen Grund, warum das jemand machen sollte???
Aus Sicht des OSI Modells habt ihr recht. Ich denke aber, dass diese Sicht nicht ausreicht, um eine umfassende Sicht auf das Thema zu erhalten.
Ich denke, was ich jetzt schreibe, kennt ihr schon:
Der Namespace von IPv6 ist um ein Vielfaches größer als der von IPv4. In diesem Space greifen Blacklists nicht mehr - sie sind schlichtweg nicht mehr anwendbar, weil keiner so große Platten hat um eine IPv6 Blacklists zu hosten.
Dieses Problem ist ein wichtiger Antrieb für die Entwicklung reputationsbasierter Erkennungsmethoden gewesen. Die sind so erfolgreich, dass sie IP-basierte Methoden ergänzen und ihnen teilweise sogar das Wasser abgraben.
Ich vermute (wissen kann ich es nicht), der Grund für die Ablehnung war zu geringe oder negative Reputation der genutzten IPv6. Negative Reputation würde ich jetzt mal spontan ausschließen. Zu geringe Reputation kann ich mir vorstellen.
Dieser Logik folgend lehnt ein Google im Zweifel einfach ab. Da kannst Du soviel richtig machen wie Du willst. SPF, DKIM, DMARC und PTR am Platz. Die von Dir vorgelegten Tests zeigen ja, Deine E-Mail war formal beanstandungsfrei.
p@rick
Am 01.03.19 um 19:24 schrieb J. Fahrner:
Am 2019-03-01 18:29, schrieb Patrick Ben Koetter:
Ich denke es ist nicht zulässig von "IPv6 wird bei mir abgelehnt" auf "Mailprovider zu doof (...) IPv6 richtig zu implementieren" zu schliessen.
Sorry, aber als Diplom-Informatiker sehe ich das anders. IPv4 oder IPv6 sind nichts anderes als Transportschichten. Semantisch DARF das keinen Unterschied machen. Wenn es das doch tut, dann ist auf einer Seite was faul. Meine Seite habe ich mittlerweile ausgeschlossen, auch reverse DNS ist sichergestellt. Von daher ist für mich, auch andere Berichte bestätigen das, eindeutig Google der Schuldige. Andere Mailhosts machen per IPv6 ja auch keine Probleme.
Ich bleibe bei meiner Meinung, Google ist "zu doof" !!!
-- Denny Hanschke
/"\ \ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST M$ ATTACHMENTS / \/!\ I'll keep fightin' against M$ HTML-eMails...
public PGP Key for eMail-Encryption (2018-10-24): https://cloud.blubbablasen.de/index.php/s/ZH9AqYLDfDgkYTc
Im Auftrag von Patrick Ben Koetter
Der Namespace von IPv6 ist um ein Vielfaches größer als der von IPv4. In diesem Space greifen Blacklists nicht mehr - sie sind schlichtweg nicht mehr anwendbar, weil keiner so große Platten hat um eine IPv6 Blacklists zu hosten.
Und dann ist eine Mail von einer IPv6 die sauber DNS, PTR usw. hat direkt verdächtig ?
Dieses Problem ist ein wichtiger Antrieb für die Entwicklung reputationsbasierter Erkennungsmethoden gewesen. Die sind so erfolgreich, dass sie IP-basierte Methoden ergänzen und ihnen teilweise sogar das Wasser abgraben.
Ich vermute (wissen kann ich es nicht), der Grund für die Ablehnung war zu geringe oder negative Reputation der genutzten IPv6. Negative Reputation würde ich jetzt mal spontan ausschließen. Zu geringe Reputation kann ich mir vorstellen.
Deshalb müssen wir jetzt google mit 1000 Mails am Tag von den IPv6 fluten nur damit deren System erkennt wir sind Mailserver ? Die Logik hat sich mir nicht erschlossen. Wenn ich nur einen Brief am Tag schreibe dann wirft die Post mir den auch hinterher weil sie sagt es lohnt nicht? :-)
Ich denke es gibt auch im IPv6 genug Erkennungsmerkmale um echte Mailserver von Bots zu unterscheiden. Also nur weil die Groß sind geht noch lange nicht alles :-)
Das ist wie die Geschichte wer ist das wichtigste Organ im Körper (das es das kleine Arschloch war wissen ja hoffentlich alle) Ich bin so gerne das kleine ..... :-)
Ich bemühe mich nach Kräften die Mails meiner Kunden zuzustellen. Aber ich kann keinen anderen Mailserver dazu zwingen anzunehmen . Wenn die mails nicht durchgehen dann müssen zur not 70 cent drauf und so verschickt werden (dauert fast genauso lange)
Ich bin für Online Demonstration gegen die die uns das Leben immer so schwer machen.
p@rick
Mit freundlichen Grüßen
Uwe Drießen -- Software & Computer
Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner !
Uwe Drießen Lembergstraße 33 67824 Feilbingert
Tel.: 06708660045
Am 2019-03-01 22:43, schrieb Patrick Ben Koetter:
Zu geringe Reputation kann ich mir vorstellen.
Wie soll ich denn jemals zu eine positiven Reputation bei denen kommen, wenn die alle meine Mails abweisen???
* J. Fahrner jf@fahrner.name:
Am 2019-03-01 22:43, schrieb Patrick Ben Koetter:
Zu geringe Reputation kann ich mir vorstellen.
Wie soll ich denn jemals zu eine positiven Reputation bei denen kommen, wenn die alle meine Mails abweisen???
Kreisverweis. Ist mir bewusst. Ich habe auch keine Antwort darauf.
Du hattest die IPv6 gekürzt gepostet. Von wem stammt das Netz? Vielleicht von einem Provider, dessen Netz eine schlechte Reputation besitzt? Es gibt z.B. einige Anbieter, die auf ihren (shared host landschaften) zu wenig gegen outbound Spam getan haben. Die werden seit einer Weile kategorisch geblockt. Da kannst Du dann soviel richtig machen wie Du willst…
p@rick
Patrick Ben Koetter - 02.03.19, 08:22:
- J. Fahrner jf@fahrner.name:
Am 2019-03-01 22:43, schrieb Patrick Ben Koetter:
Zu geringe Reputation kann ich mir vorstellen.
Wie soll ich denn jemals zu eine positiven Reputation bei denen kommen, wenn die alle meine Mails abweisen???
Kreisverweis. Ist mir bewusst. Ich habe auch keine Antwort darauf.
Du hattest die IPv6 gekürzt gepostet. Von wem stammt das Netz? Vielleicht von einem Provider, dessen Netz eine schlechte Reputation besitzt? Es gibt z.B. einige Anbieter, die auf ihren (shared host landschaften) zu wenig gegen outbound Spam getan haben. Die werden seit einer Weile kategorisch geblockt. Da kannst Du dann soviel richtig machen wie Du willst…
Oha, ich dachte, bei Google würden genug Experten arbeiten, um Spam granularer zu filtern als komplette Netze zu blocken.
Das mache ich ja selbst mit meinem privaten Mailserver nicht, wo ich alle Domains eines gewissen in Gamergate-Kreisen verwendeten Mail- Providers, der auf Abuse Reports bezüglich Trolling Beleidigungen zurück schickte, blocke. Und das auch nur, weil mir im dem Fall falsche Positive ziemlich egal sind.
Aber das ist mein privater Mailserver, wo ich mein Hausrecht ausübe. Klar, hat Google auch, Hausrecht für seine Mail-Server. Die Anwender, die das verwenden, können ja grundsätzlich wechseln. Eine gewisse Verantwortung sehe ich angesichts der Größe von gmail allerdings doch. Ein Overblocking könnte eine ähnliche Wirkung entfalten wie gewollte Zensur.
Bei mir kommen ein paar Spam-Mails pro Tag durch. Aber abgesehen davon halte ich Spam dieser Tage für ein weitgehend gelöstes Problem, auch ohne ganze Netze zu blocken.
Aber gut, wir müssen das hier nicht ausdiskutieren. Ich hab für meinen Mailserver derzeit lieber Recht als dran rum zu biegen, damit Mails bei gmail-Anwendern ankommen. Und derzeit geht es ja auch ohne.
Am 2019-03-02 08:22, schrieb Patrick Ben Koetter:
Du hattest die IPv6 gekürzt gepostet. Von wem stammt das Netz?
Von Hetzner
On 01.03.2019 22:43, Patrick Ben Koetter wrote:
Der Namespace von IPv6 ist um ein Vielfaches größer als der von IPv4. In diesem Space greifen Blacklists nicht mehr - sie sind schlichtweg nicht mehr anwendbar, weil keiner so große Platten hat um eine IPv6 Blacklists zu hosten.
man blockiert hier die kleinste Einheit -> den ganzen /64-Prefix was bei IPv4 eine einzelne IP-Adresse ist, ist bei IPv6 ein ganzes /64-Prefix
Zitat von Patrick Ben Koetter p@sys4.de:
Ich vermute (wissen kann ich es nicht), der Grund für die Ablehnung war zu geringe oder negative Reputation der genutzten IPv6. Negative Reputation würde ich jetzt mal spontan ausschließen. Zu geringe Reputation kann ich mir vorstellen.
Dieser Logik folgend lehnt ein Google im Zweifel einfach ab. Da kannst Du soviel richtig machen wie Du willst. SPF, DKIM, DMARC und PTR am Platz. Die von Dir vorgelegten Tests zeigen ja, Deine E-Mail war formal beanstandungsfrei.
p@rick
Wenn das zu einer Verzögerung im Sinne von Greylisting führen würde ist das in Ordnung, aber die E-Mail von einer IPv6 Adresse ablehnen, nur weil ich als Provider zu wenig über diese Adresse weiß lässt schon tief blicken wie das Selbstverständnis bzw. was die Zielrichtung ist. Wer auf funktionierende E-Mail Wert legt sollte Google, Microsoft und mit Abtrichen Apple meiden, die wollen keinen offenen Mailaustausch sondern eine abgeschottete Kundenplatform ohne Exit Strategie.
Am 01.03.19 um 19:24 schrieb J. Fahrner:
Am 2019-03-01 18:29, schrieb Patrick Ben Koetter:
Ich denke es ist nicht zulässig von "IPv6 wird bei mir abgelehnt" auf "Mailprovider zu doof (...) IPv6 richtig zu implementieren" zu schliessen.
Sorry, aber als Diplom-Informatiker sehe ich das anders. IPv4 oder IPv6 sind nichts anderes als Transportschichten. Semantisch DARF das keinen Unterschied machen. Wenn es das doch tut, dann ist auf einer Seite was faul. Meine Seite habe ich mittlerweile ausgeschlossen, auch reverse DNS ist sichergestellt. Von daher ist für mich, auch andere Berichte bestätigen das, eindeutig Google der Schuldige. Andere Mailhosts machen per IPv6 ja auch keine Probleme.
Ich bleibe bei meiner Meinung, Google ist "zu doof" !!!
Recht haben und Recht bekommen sind 2 paar Stiefel predige ich jeden Tag an der UNI *g
Wenn dich google nervt dann blockiere sie halt ,niemand haelt dich auf
On 02.03.2019 10:06, Robert Schetterer wrote:
Recht haben und Recht bekommen sind 2 paar Stiefel predige ich jeden Tag an der UNI *g
das stimmt;
Wenn dich google nervt dann blockiere sie halt ,niemand haelt dich auf
genau das mache ich z.B.
smtpd_sender_restrictions = reject_unknown_sender_domain, reject_non_fqdn_sender, reject_rhsbl_sender rhsbl.sorbs.net, ... check_sender_access hash:/etc/postfix/sender_access, permit
/etc/postfix/sender_access hat bei mir folgenden Inhalt
<> REJECT 5.7.1 Empty sender refused ; auf die Art braucht mir niemand einen SPAM auf's Aug' drücken
email1 DUNNO ; explizite Ausnahmen welche erlaubt sind email2 DUNNO
domain1 DUNNO domain2 DUNNO
gmail.com REJECT 5.7.1 Domain (gmail.com) blocked ; f. ein paar habe ich gnädigerweise eine eigene Regel ... ; damit es nicht ganz so knallhart klingt *g
arpa REJECT 5.7.1 infrastructure TLD (.arpa) blocked
# keep these two marker lines # for the managed entr(y/ies) # BEGIN{
at DUNNO ; einzige Ausnahmen de DUNNO eu DUNNO
ac REJECT 5.7.1 ccTLD (.ac) blocked ; und jede andere TLD wird geblockt ... africa REJECT 5.7.1 gTLD (.africa) blocked ; com schließt hier gmail.com, msn.com, ... mit ein ... xn--11b4c3d REJECT 5.7.1 ccTLD/gTLD (IDN=.xn--11b4c3d) blocked ...
# }END
ich bekomme keinen einzigen SPAM mehr seit ich hier die Daumenschrauben so richtig angezogen habe etwaiges was zuviel geblockt wird, betrachte ich als Kolateralschaden
hier mit dem Skript wird das von Zeit zu Zeit aktualisiert
#!/bin/sh
DOMAINFILE=/root/tlds.list
if [ -e $DOMAINFILE ]; then rm -f $DOMAINFILE fi
wget --output-document=$DOMAINFILE https://data.iana.org/TLD/tlds-alpha-by-domain.txt
cat $DOMAINFILE |tr '[:upper:]' '[:lower:]' |grep "xn--" >/tmp/idnTLDs cat $DOMAINFILE |tr '[:upper:]' '[:lower:]' |grep "^[a-z][a-z][a-z]"
/tmp/gTLDs
cat $DOMAINFILE |tr '[:upper:]' '[:lower:]' |grep "^[a-z][a-z]$"
/tmp/ccTLDs
( cat /etc/postfix/sender_access |sed -n '1,/BEGIN{/p'
echo -e -n "#\n# Country-Code Domains\n#\n" awk -f /root/bin/hlpr/ccTLDs.awk /tmp/ccTLDs
echo -e -n "#\n# Generic Domains\n#\n" awk -f /root/bin/hlpr/gTLDs.awk /tmp/gTLDs
echo -e -n "#\n# IDN Domains\n#\n" awk -f /root/bin/hlpr/idnTLDs.awk /tmp/idnTLDs
cat /etc/postfix/sender_access |sed -n '/}END/,$p' ) >/tmp/rules
cp /tmp/rules /etc/postfix/sender_access
rm -f /tmp/rules
postmap /etc/postfix/sender_access
postfix reload
rm -f /tmp/ccTLDs rm -f /tmp/gTLDs rm -f /tmp/idnTLDs
die einzelnen AWK-Skripte
ccTLDs.awk
{ if ( ( $1 == "at" ) ||( $1 == "de" ) ||( $1 == "eu" ) ) { printf( "%s\tDUNNO\n", $1 ); } else { printf( "%s\tREJECT 5.7.1 ccTLD (.%s) blocked\n", $1, $1 ); } }
gTLDs.awk
!/arpa/ { if ( length( $1 ) < 8 ) { tabs = "\t\t\t"; } else { if ( length( $1 ) < 16 ) { tabs = "\t\t"; } else { tabs = "\t"; } } printf( "%s%sREJECT 5.7.1 gTLD (.%s) blocked\n", $1, tabs, $1 ); }
idnTLDs.awk
{ if ( length( $1 ) < 8 ) { tabs = "\t\t\t\t"; } else { if ( length( $1 ) < 16 ) { tabs = "\t\t\t"; } else { if ( length( $1 ) < 24 ) { tabs = "\t\t"; } else { tabs = "\t"; } } } printf( "%s%sREJECT 5.7.1 ccTLD/gTLD (IDN=.%s) blocked\n", $1, tabs, $1 ); }
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Google Germany GmbH 040 8 08 17 90 00
Verabredet euch dann sind da mal die Leitungen dicht Und immer höflich bleiben die Telefonisten können nix für *gg
vSp :-)
Mit freundlichen Grüßen
Uwe Drießen - -- Software & Computer
Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner !
Uwe Drießen Lembergstraße 33 67824 Feilbingert
Tel.: 06708660045
* Uwe Drießen driessen@fblan.de:
Google Germany GmbH 040 8 08 17 90 00
Verabredet euch dann sind da mal die Leitungen dicht Und immer höflich bleiben die Telefonisten können nix für *gg
Als List-Admin grätsche ich an dieser Stelle rein:
Ich halte es für falsch, hier zu Aktionen gegen einen Dienstleister aufzurufen und gleichzeitig "Verabredet euch dann sind da mal die Leitungen dicht" anzumerken. Ich werte das als Absicht, dem Ziel (hier: Google) wirtschaftlichen Schaden (nicht erreichbar == DOS) zuzufügen.
"Verärgert sein" kann ich nachvollziehen. "Schaden zufügen" steht nicht auf der Liste der Dinge, die ich nachvollziehen kann.
Ich bitte um eine angemessene Auseinandersetzung.
p@rick
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Im Auftrag von Patrick Ben Koetter
- Uwe Drießen driessen@fblan.de:
Google Germany GmbH 040 8 08 17 90 00
Verabredet euch dann sind da mal die Leitungen dicht Und immer höflich bleiben die Telefonisten können nix für *gg
Als List-Admin grätsche ich an dieser Stelle rein:
Ich halte es für falsch, hier zu Aktionen gegen einen Dienstleister aufzurufen und gleichzeitig "Verabredet euch dann sind da mal die Leitungen dicht" anzumerken. Ich werte das als Absicht, dem Ziel (hier: Google) wirtschaftlichen Schaden (nicht erreichbar == DOS) zuzufügen.
Ach du meine Güte Du glaubst doch nicht wirklich das hier 10 Leute es schaffen würden diese Rufnummer zur Selben Zeit anzurufen ? Wenn es 2 sind dann sind es SEHR viele :-) Ich kann dir versichern in Hamburg sind weitaus mehr Leitungen geschaltet als das wir die wirklich in irgendeiner Weise überlasten könnten :-) zudem haben die eine KI vorgeschaltet Menschen ?? Aus Fleisch und Blut ? Ich glaube da gibt es keine mehr bei Google oder die sind so abgespaced ...
"Verärgert sein" kann ich nachvollziehen. "Schaden zufügen" steht nicht auf der Liste der Dinge, die ich nachvollziehen kann.
Wir WOLLEN nicht VON DEM SCHADEN reden die Google der Reputation der unbescholtene Mailadmins zufügt ? Wir IGNORIEREN mal das die Kunden diese Mailadmins in dem Zuge für Unfähig halten ? Wir ÜBERSEHEN geflissentlich das Kunden abwandern. Wir VERGESSEN mal das das eigentlich gegen TKG verstößt und einer Unterdrückung von Nachrichten gleichkommt. (wer da noch was hat darf die Liste gerne vervollständigen :-))
Und nein wenn man mich mit dem Rücken an die Wand stellt dann werde ich nicht wählerisch sein beim Einsatz der Mittel um mir Gehör zu verschaffen.
Ich bitte um eine angemessene Auseinandersetzung.
Klar wenn du dann mal deine Kontakte zu Google aufwärmst ...... Wo ist das angemessen das man Mailserver welche mal 3 oder 4 Mails in der Woche an Google Kunden schicken die Mails nicht mehr loswerden? Und manchmal muss man ETWAS LAUTER reden damit da oben im Himmel gehört wird was auf der Erde gewünscht oder benötigt wird. Ich hab noch einen Kollegen der ALLE von Google geforderten Dkim, SPF, TXT sogar nach neuestem Draft , alle Domains bei Google registriert ... drin hat und keine Chance hat Mails an Kunden von Google bzw. was schlimmer ist das seine Kunden keine Mails an Googleadressen losbekommen zu schicken ohne das er auf eine Mail von denen Antwortet (das geht komischerweise) Ob sich das mit der DSVGO vereinbaren lässt das Google zu eigenen Zwecken außer dem Nachweis gegenüber den Strafverfolgungsbehörden Mitschneidet und auswertet wer da mit wem in Kontakt steht .....
Möchten wir da noch ein paar mehr Argumente mit einer fachlich sachlichen Auseinandersetzung und der Wahl der Mittel führen das wir die mal gleichmäßig verteilen ?
Ohne dich persönlich angreifen zu wollen "seit wann arbeitest du bei Google " :-)
Die betroffenen Mailadmins sind mit Ihrem Latein am Ende Wirkliche Aussagen warum man gesperrt werden würde bekommst du nur wenn du wirklich mehr als 1000 Mails an Google sendest (aber nicht in 20 Jahren gerechnet) Jemanden der dir sagt was BEI GOOGLE FAUL ist bekommst auch nicht aus Fleisch und Blut in einem Kommunikationsweg Das hat man dort wahrscheinlich nicht nötig
Also bei allem Verständnis für deine Haltung es wird aber so langsam mal zeit den Olymp wach zu bekommen. Damit die Götter wissen das es mehr als sie gibt und die auf der Erde auch durchaus ein Recht auf Existenz haben.
Nur mal 3 Tage diese Amerikanischen Konzerne jede Mail mit 450 ablehnen :-) Und es sind zur Zeit auch solche betroffen die mich immer für zu "außergewöhnlich" in meinen Aussagen gehalten haben. Heute kommt der eine oder andere auf die Idee das ich auch vor 2 Jahren schon einiges gesehen habe was heute kommt. Es steht schon in der Bibel "wehret den Anfängen" (Stammt ursprünglich vom römischen Dichter Ovid (43 v. Chr. bis um 18 n. Chr.)
Ja ich kenne auch das Zitat "wenn dir einer auf die rechte Wange haut dann halte auch die Linke hin" aber dann hab ich schmerzen im Gesicht und eine unnatürlich rote Farbe dazu ....
P.S. komischerweise betrifft es bei mir nur einen Kunden und dort auch nur 2 Gmail Adressen, an 20 andere kann der Kunde senden *g
p@rick
Mit freundlichen Grüßen
Uwe Drießen - -- Software & Computer
Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner !
Uwe Drießen Lembergstraße 33 67824 Feilbingert
Tel.: 06708660045
Uwe,
* Uwe Drießen driessen@fblan.de:
Im Auftrag von Patrick Ben Koetter
- Uwe Drießen driessen@fblan.de:
Google Germany GmbH 040 8 08 17 90 00
Verabredet euch dann sind da mal die Leitungen dicht Und immer höflich bleiben die Telefonisten können nix für *gg
Als List-Admin grätsche ich an dieser Stelle rein:
Ich halte es für falsch, hier zu Aktionen gegen einen Dienstleister aufzurufen und gleichzeitig "Verabredet euch dann sind da mal die Leitungen dicht" anzumerken. Ich werte das als Absicht, dem Ziel (hier: Google) wirtschaftlichen Schaden (nicht erreichbar == DOS) zuzufügen.
Ach du meine Güte Du glaubst doch nicht wirklich das hier 10 Leute es schaffen würden diese Rufnummer zur Selben Zeit anzurufen ? Wenn es 2 sind dann sind es SEHR viele :-) Ich kann dir versichern in Hamburg sind weitaus mehr Leitungen geschaltet als das wir die wirklich in irgendeiner Weise überlasten könnten :-) zudem haben die eine KI vorgeschaltet Menschen ?? Aus Fleisch und Blut ? Ich glaube da gibt es keine mehr bei Google oder die sind so abgespaced ...
"Verärgert sein" kann ich nachvollziehen. "Schaden zufügen" steht nicht auf der Liste der Dinge, die ich nachvollziehen kann.
Wir WOLLEN nicht VON DEM SCHADEN reden die Google der Reputation der unbescholtene Mailadmins zufügt ? Wir IGNORIEREN mal das die Kunden diese Mailadmins in dem Zuge für Unfähig halten ? Wir ÜBERSEHEN geflissentlich das Kunden abwandern. Wir VERGESSEN mal das das eigentlich gegen TKG verstößt und einer Unterdrückung von Nachrichten gleichkommt. (wer da noch was hat darf die Liste gerne vervollständigen :-))
Und nein wenn man mich mit dem Rücken an die Wand stellt dann werde ich nicht wählerisch sein beim Einsatz der Mittel um mir Gehör zu verschaffen.
Ich bitte um eine angemessene Auseinandersetzung.
Klar wenn du dann mal deine Kontakte zu Google aufwärmst ...... Wo ist das angemessen das man Mailserver welche mal 3 oder 4 Mails in der Woche an Google Kunden schicken die Mails nicht mehr loswerden? Und manchmal muss man ETWAS LAUTER reden damit da oben im Himmel gehört wird was auf der Erde gewünscht oder benötigt wird. Ich hab noch einen Kollegen der ALLE von Google geforderten Dkim, SPF, TXT sogar nach neuestem Draft , alle Domains bei Google registriert ... drin hat und keine Chance hat Mails an Kunden von Google bzw. was schlimmer ist das seine Kunden keine Mails an Googleadressen losbekommen zu schicken ohne das er auf eine Mail von denen Antwortet (das geht komischerweise) Ob sich das mit der DSVGO vereinbaren lässt das Google zu eigenen Zwecken außer dem Nachweis gegenüber den Strafverfolgungsbehörden Mitschneidet und auswertet wer da mit wem in Kontakt steht .....
Möchten wir da noch ein paar mehr Argumente mit einer fachlich sachlichen Auseinandersetzung und der Wahl der Mittel führen das wir die mal gleichmäßig verteilen ?
Ohne dich persönlich angreifen zu wollen "seit wann arbeitest du bei Google " :-)
Die betroffenen Mailadmins sind mit Ihrem Latein am Ende Wirkliche Aussagen warum man gesperrt werden würde bekommst du nur wenn du wirklich mehr als 1000 Mails an Google sendest (aber nicht in 20 Jahren gerechnet) Jemanden der dir sagt was BEI GOOGLE FAUL ist bekommst auch nicht aus Fleisch und Blut in einem Kommunikationsweg Das hat man dort wahrscheinlich nicht nötig
Also bei allem Verständnis für deine Haltung es wird aber so langsam mal zeit den Olymp wach zu bekommen. Damit die Götter wissen das es mehr als sie gibt und die auf der Erde auch durchaus ein Recht auf Existenz haben.
Nur mal 3 Tage diese Amerikanischen Konzerne jede Mail mit 450 ablehnen :-) Und es sind zur Zeit auch solche betroffen die mich immer für zu "außergewöhnlich" in meinen Aussagen gehalten haben. Heute kommt der eine oder andere auf die Idee das ich auch vor 2 Jahren schon einiges gesehen habe was heute kommt. Es steht schon in der Bibel "wehret den Anfängen" (Stammt ursprünglich vom römischen Dichter Ovid (43 v. Chr. bis um 18 n. Chr.)
Ja ich kenne auch das Zitat "wenn dir einer auf die rechte Wange haut dann halte auch die Linke hin" aber dann hab ich schmerzen im Gesicht und eine unnatürlich rote Farbe dazu ....
P.S. komischerweise betrifft es bei mir nur einen Kunden und dort auch nur 2 Gmail Adressen, an 20 andere kann der Kunde senden *g
mir war bewusst, dass Dir das nicht gefallen würde und ich habe Deine Antwort erwartet.
Ich bleibe dabei: Niemand darf die Mailingliste dazu nutzen, andere dazu aufzurufen jemandem Schaden zuzufügen. Ob es möglich ist, tatsächlich auch Schaden zu verursachen, ist dabei nicht von Bedeutung.
p@rick
Am 04.03.19 um 19:08 schrieb Patrick Ben Koetter:
mir war bewusst, dass Dir das nicht gefallen würde und ich habe Deine Antwort erwartet.
Ich bleibe dabei: Niemand darf die Mailingliste dazu nutzen, andere dazu aufzurufen jemandem Schaden zuzufügen. Ob es möglich ist, tatsächlich auch Schaden zu verursachen, ist dabei nicht von Bedeutung.
p@rick
ACK ich bin zwar kein Jurist aber ich vermute mal wenn ein List Admin hier nicht einschreitet kann man ihn sogar belangen
Das wirkliche Problem ist die marktbeherrschende Stellung von Google und Co, ein handvoll Konzerne macht im Grunde was sie wollen
Das hier sollte aber eine technische Liste sein keine politische.
Das technische Problem wurde geloest ich denke keiner hat Beifall geklatscht...aber um mehr zu erreichen ist zumindest diese Liste nicht der richtige Platz da gibt es andere Foren....
Am 2019-03-04 20:09, schrieb Robert Schetterer:
Das technische Problem wurde geloest ich denke keiner hat Beifall geklatscht.
Naja... ist das wirklich die Lösung "verwende kein IPv6 bei Gmail"?
-----Ursprüngliche Nachricht----- Von: postfix-users [mailto:postfix-users- bounces+driessen=fblan.de@de.postfix.org] Im Auftrag von J. Fahrner Gesendet: Montag, 4. März 2019 21:12 An: postfix-users@de.postfix.org Betreff: Re: Google blockt Mails
Am 2019-03-04 20:09, schrieb Robert Schetterer:
Das technische Problem wurde geloest ich denke keiner hat Beifall geklatscht.
Naja... ist das wirklich die Lösung "verwende kein IPv6 bei Gmail"?
Nein das ist nicht die Lösung weil es auch einige gibt die selbst mit dem Workaround keine Mails an google rausbekommen
Noch nicht mal an ihr eigenes Mailkonto bei Google Es sei denn sie Antworten auf eine Mail von sich selber die zuerst über Google gesendet wurde :-)
Heute Mittag 2 Stunden lang hin und her getestet bzw. der Kollege alleine seit heute Morgen 9 Uhr.
Waren das noch weitere technische Lösungen? :-))
Mit freundlichen Grüßen
Uwe Drießen -- Software & Computer
Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner !
Uwe Drießen Lembergstraße 33 67824 Feilbingert
Tel.: 06708660045
Am 2019-03-04 21:17, schrieb Uwe Drießen:
Nein das ist nicht die Lösung weil es auch einige gibt die selbst mit dem Workaround keine Mails an google rausbekommen
Noch nicht mal an ihr eigenes Mailkonto bei Google Es sei denn sie Antworten auf eine Mail von sich selber die zuerst über Google gesendet wurde :-)
Nicht mal das hatte bei mir via IPv6 geklappt! Mir scheint das eher ein Glücksspiel zu sein, seine Mails bei Google loszuwerden.
Ich habe da folgende Theorie: Google hat heftigste Probleme mit incoming Spam. Wie Patrick schon ausführte, sind Blacklists bei IPv6 nicht anwendbar. Also experimentiert (!) Google an neuen Filtertechniken für IPv6. Die grossen Provider, wie GMX, T-Online, usw. sind wohl auf einer Whitelist, die werden bei den Tests ausgenommen. Kein groosser Aufschrei. Die kleinen Provider verwenden nachwievor nur IPv4, betrifft die also auch nicht. Betroffen sind nur echte Spammer, und so kleine Einzelkämpfer mit eigenem vServer bei Hetzner & Co. Und denen geht Google am A... vorbei. [Theorie Ende]
Im Auftrag von J. Fahrner
Am 2019-03-04 21:17, schrieb Uwe Drießen:
Nein das ist nicht die Lösung weil es auch einige gibt die selbst mit dem Workaround keine Mails an google rausbekommen
Noch nicht mal an ihr eigenes Mailkonto bei Google Es sei denn sie Antworten auf eine Mail von sich selber die zuerst über Google gesendet wurde :-)
Nicht mal das hatte bei mir via IPv6 geklappt!
Mit IPv4 auch nicht :-) Den kniff hatte ich gleich als erstes empfohlen und geht auch nicht
Ich kann per IPv6 als auch IPv4 (Hetzner) senden Aus Sicherheitsgründen hab ich das zur Zeit auch auf IPv4 für die Großen festgenagelt + max 1 mail pro minute , nur max 1 Mail in der Connection ....
Mir scheint das eher ein Glücksspiel zu sein, seine Mails bei Google loszuwerden.
Russisch Roulette :-) Irgendwann triffst du :-)
Ich habe da folgende Theorie: Google hat heftigste Probleme mit incoming Spam. Wie Patrick schon
Incomming ? Ich hab den höchsten Anteil an Spam incomming von outgoing google
ausführte, sind Blacklists bei IPv6 nicht anwendbar. Also experimentiert (!) Google an neuen Filtertechniken für IPv6. Die grossen Provider, wie GMX, T-Online, usw. sind wohl auf einer Whitelist, die werden bei den Tests ausgenommen. Kein groosser Aufschrei. Die kleinen Provider verwenden nachwievor nur IPv4, betrifft die also auch nicht. Betroffen sind nur echte Spammer, und so kleine Einzelkämpfer mit eigenem vServer bei Hetzner & Co. Und denen geht Google am A... vorbei. [Theorie Ende]
Das meiste was bei IPv4 hilft (DNS, PTR) hilft auch bei v6 Blacklisten für IPv4 hab ich auch kaum noch welche im Einsatz Der Anteil Spam der hier über v6 reinkommt ist von den Großen :-) und ansonsten zu vernachlässigen (unter 1% über alles)
Dialin usw. mit V6 haben in der Regel keinen PTR sitzen oder einen der schon verrät das es dialin ist Da sag ich dann sorry von dir nüscht :-) kauf dich Mailserver gugg das dein DNS/PTR stimmt dann darfste gerne wiederkommen
KISS Prinzip Nicht das Komplizierte führt immer zum Erfolg manchmal sind es ganz Profane Dinge die man prüfen kann. Funktioniert hier schon ein paar Jahre praktisch unverändert
P.S. soweit ich weiß hab ich weder Dkim noch SPF noch sonstiges (oder ich hab es schon wieder vergessen)
Mit freundlichen Grüßen
Uwe Drießen -- Software & Computer
Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner !
Uwe Drießen Lembergstraße 33 67824 Feilbingert
Tel.: 06708660045
Dann mal pur Technisch und das alle dran Teilhaben
DNS Prüfen
Scheinbar geht Google SEHR tief in die DNS records
Prüfen mit
https://zonemaster.net/domain_check
alle Unstimmigkeiten bereinigen
Soa Records inkl. Gültigkeiten DNS Server mit PTR versehen Nameserver in 2 unterschiedlichen AS liegen (idealerweise) Usw. usw
Wenn da bestimmte Dinge zusammen kommen die nicht stimmen gibt es eins auf die Glocke :-)
Mit freundlichen Grüßen
Uwe Drießen -- Software & Computer
Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner !
Uwe Drießen Lembergstraße 33 67824 Feilbingert
Tel.: 06708660045
Am 2019-03-05 17:15, schrieb Uwe Drießen:
Dann mal pur Technisch und das alle dran Teilhaben
DNS Prüfen
Scheinbar geht Google SEHR tief in die DNS records
Prüfen mit
https://zonemaster.net/domain_check
alle Unstimmigkeiten bereinigen
Das nützt in meinem Fall überhaupt nix. Mit meiner Domain ist alles in Ordnung. Kannst es gerne selber prüfen lassen.
On 05.03.2019 17:44, J. Fahrner wrote:
Am 2019-03-05 17:15, schrieb Uwe Drießen:
Dann mal pur Technisch und das alle dran Teilhaben
DNS Prüfen
Scheinbar geht Google SEHR tief in die DNS records
Prüfen mit
https://zonemaster.net/domain_check
alle Unstimmigkeiten bereinigen
Das nützt in meinem Fall überhaupt nix. Mit meiner Domain ist alles in Ordnung. Kannst es gerne selber prüfen lassen.
verwendest Du mehrere IPv6 Adressen vom zugeordneten /64-Prefix? wenn ja, stellst Du sicher immer von der selben IPv6 aus zu senden? und hat exakt diese IPv6 folgende Eigenschaften:
der rDNS ist ident mit dem der IPv4 Adresse die DNS-Name hat einen A Record mit der IPv4 Adresse und einen mit dieser IPv6 Adresse und beides ist im SPF definiert und im SMTP-HELO/EHLO wird exakt dieser DNS-Name verwendet?
der DNS-Name des MX-Records spielt dabei keine Rolle;
Am 2019-03-05 19:55, schrieb Walter H.:
verwendest Du mehrere IPv6 Adressen vom zugeordneten /64-Prefix?
Nein.
der rDNS ist ident mit dem der IPv4 Adresse
Ja.
die DNS-Name hat einen A Record mit der IPv4 Adresse und einen mit dieser IPv6 Adresse und beides ist im SPF definiert und im SMTP-HELO/EHLO wird exakt dieser DNS-Name verwendet?
Ja.
On 05.03.2019 20:08, J. Fahrner wrote:
Am 2019-03-05 19:55, schrieb Walter H.:
verwendest Du mehrere IPv6 Adressen vom zugeordneten /64-Prefix?
Nein.
gut, damit sind etwaige Probleme gar nicht möglich;
der rDNS ist ident mit dem der IPv4 Adresse
Ja.
die DNS-Name hat einen A Record mit der IPv4 Adresse und einen mit dieser IPv6 Adresse und beides ist im SPF definiert und im SMTP-HELO/EHLO wird exakt dieser DNS-Name verwendet?
Ja.
das ist schon mal gut;
irgendwie hast mich neugierig gemacht; kann ich irgendwie das testen so real wie möglich, sprich, kann ich von meinem vServer eine E-mail absenden, mit einer E-mailadresse als Absender die zu Deiner Domain gehört sprich könntest Du zu Testzwecken in Deinen SPF-Eintrag etwas inkludieren?
ich will jetzt nichts beschwören, aber es gibt auch eine Reputation der Domain selbst ...
ich würde dann eine E-mail mit der E-mailadresse als Absender an eine von Dir genannte Gmail adresse senden und CC an eine E-mailadresse Deiner Domain; wenn diese bei Dir angekommen ist kannst die Ergänzung im SPF-Eintrag wieder entfernen;
bzw. kannst f. den Anfang mal mir eine Testmail senden (von Deiner Domain fahrner.name)? wenn diese geblockt wird dann hast tatsächlich ein techn. Problem;
On 05.03.2019 21:18, Walter H. wrote:
On 05.03.2019 20:08, J. Fahrner wrote:
Am 2019-03-05 19:55, schrieb Walter H.:
verwendest Du mehrere IPv6 Adressen vom zugeordneten /64-Prefix?
Nein.
gut, damit sind etwaige Probleme gar nicht möglich;
der rDNS ist ident mit dem der IPv4 Adresse
Ja.
die DNS-Name hat einen A Record mit der IPv4 Adresse und einen mit dieser IPv6 Adresse und beides ist im SPF definiert und im SMTP-HELO/EHLO wird exakt dieser DNS-Name verwendet?
Ja.
das ist schon mal gut;
irgendwie hast mich neugierig gemacht;
ich vermute das hier im Header bringt das Problem ...
Received: from server.fahrner.name (server.fahrner.name [88.198.89.240]) by myMX (Postfix) with ESMTPS id 7043F63C18 for<My-Email>; Tue, 5 Mar 2019 21:44:36 +0100 (CET) Received: from roundcube.fahrner.name (localhost.localdomain [127.0.0.1]) by server.fahrner.name (Postfix) with ESMTP id E4D5E100531 for<My-Email>; Tue, 5 Mar 2019 21:44:32 +0100 (CET)
der obere Eintrag ist OK, aber im Kombination mit dem unteren Eintrag kann er Gift sein, weil roundcube.fahrner.name löst mit einer echten IP auf (der selben wie server.fahrner.name)
einfach den unteren Eintrag per Header-Check wegfiltern ...
vlt. ist das die Lsg. ... was Google bei IPv6 pfuscht, weiß keiner ...
Am 05.03.19 um 22:24 schrieb Walter H.:
On 05.03.2019 21:18, Walter H. wrote:
On 05.03.2019 20:08, J. Fahrner wrote:
Am 2019-03-05 19:55, schrieb Walter H.:
verwendest Du mehrere IPv6 Adressen vom zugeordneten /64-Prefix?
Nein.
gut, damit sind etwaige Probleme gar nicht möglich;
der rDNS ist ident mit dem der IPv4 Adresse
Ja.
die DNS-Name hat einen A Record mit der IPv4 Adresse und einen mit dieser IPv6 Adresse und beides ist im SPF definiert und im SMTP-HELO/EHLO wird exakt dieser DNS-Name verwendet?
Ja.
das ist schon mal gut;
irgendwie hast mich neugierig gemacht;
ich vermute das hier im Header bringt das Problem ...
Received: from server.fahrner.name (server.fahrner.name [88.198.89.240]) by myMX (Postfix) with ESMTPS id 7043F63C18 for<My-Email>; Tue, 5 Mar 2019 21:44:36 +0100 (CET) Received: from roundcube.fahrner.name (localhost.localdomain [127.0.0.1]) by server.fahrner.name (Postfix) with ESMTP id E4D5E100531 for<My-Email>; Tue, 5 Mar 2019 21:44:32 +0100 (CET)
der obere Eintrag ist OK, aber im Kombination mit dem unteren Eintrag kann er Gift sein, weil roundcube.fahrner.name löst mit einer echten IP auf (der selben wie server.fahrner.name)
einfach den unteren Eintrag per Header-Check wegfiltern ...
vlt. ist das die Lsg. ... was Google bei IPv6 pfuscht, weiß keiner ...
localhost.localdomain kommt nicht gut an...
siehe auch: https://www.abuseat.org/namingproblems.html
Am 2019-03-05 23:36, schrieb Frank Belau:
localhost.localdomain kommt nicht gut an...
siehe auch: https://www.abuseat.org/namingproblems.html
Ist ja nicht im HELO, sondern beim einkippen in Postfix auf dem localhost. Interessant ist immer nur die oberste received-Zeile. Was ich in meinem lokalen Netz mache geht niemand was an.
* J. Fahrner jf@fahrner.name:
Am 2019-03-05 23:36, schrieb Frank Belau:
localhost.localdomain kommt nicht gut an...
siehe auch: https://www.abuseat.org/namingproblems.html
Ist ja nicht im HELO, sondern beim einkippen in Postfix auf dem localhost. Interessant ist immer nur die oberste received-Zeile. Was ich in meinem lokalen Netz mache geht niemand was an.
Analysiert wird es dennoch. Es gibt Mailfilter, die lehnen E-Mail ab wenn Submission kein ESMTSA war, d.h. kein TLS beim Einliefern genutzt wurde. Ein wirklich hirnrissiger Check, der viele Falsch-Positive generiert und doch wird er eingesetzt.
Soll mir recht sein. Auf Diskussionen, wer hier Recht hat, lasse ich mich mit denen nicht mehr ein. smtp_header_checks gaukeln denen eine schöne, heile Welt vor.
p@rick
Am 2019-03-06 08:23, schrieb Patrick Ben Koetter:
Soll mir recht sein. Auf Diskussionen, wer hier Recht hat, lasse ich mich mit denen nicht mehr ein. smtp_header_checks gaukeln denen eine schöne, heile Welt vor.
Wie genau müsste denn die Headerzeile aussehen damit die zufrieden sind? Was fügst du da ein?
Jochen
Hallo Jochen,
Am Mittwoch, 6. März 2019, 09:38:37 CET schrieb J. Fahrner:
Received: from roundcube.fahrner.name (localhost.localdomain [127.0.0.1]) by server.fahrner.name (Postfix) with ESMTP id E4D5E100531 for<My-Email>; Tue, 5 Mar 2019 21:44:32 +0100 (CET)
Wie genau müsste denn die Headerzeile aussehen damit die zufrieden sind? Was fügst du da ein?
Konfigurier Roundcube mal so, daß bei der Einlieferung die öffentliche IP und Authentifizierung genutzt wird.
Gruß, Gregor
Am 05.03.19 um 23:36 schrieb Frank Belau:
Am 05.03.19 um 22:24 schrieb Walter H.:
On 05.03.2019 21:18, Walter H. wrote:
On 05.03.2019 20:08, J. Fahrner wrote:
Am 2019-03-05 19:55, schrieb Walter H.:
verwendest Du mehrere IPv6 Adressen vom zugeordneten /64-Prefix?
Nein.
gut, damit sind etwaige Probleme gar nicht möglich;
der rDNS ist ident mit dem der IPv4 Adresse
Ja.
die DNS-Name hat einen A Record mit der IPv4 Adresse und einen mit dieser IPv6 Adresse und beides ist im SPF definiert und im SMTP-HELO/EHLO wird exakt dieser DNS-Name verwendet?
Ja.
das ist schon mal gut;
irgendwie hast mich neugierig gemacht;
ich vermute das hier im Header bringt das Problem ...
Received: from server.fahrner.name (server.fahrner.name [88.198.89.240]) by myMX (Postfix) with ESMTPS id 7043F63C18 for<My-Email>; Tue, 5 Mar 2019 21:44:36 +0100 (CET) Received: from roundcube.fahrner.name (localhost.localdomain [127.0.0.1]) by server.fahrner.name (Postfix) with ESMTP id E4D5E100531 for<My-Email>; Tue, 5 Mar 2019 21:44:32 +0100 (CET)
der obere Eintrag ist OK, aber im Kombination mit dem unteren Eintrag kann er Gift sein, weil roundcube.fahrner.name löst mit einer echten IP auf (der selben wie server.fahrner.name)
Wo siehst du da ein Problem? Cnames sind doch kein Verbrechen.
einfach den unteren Eintrag per Header-Check wegfiltern ...
vlt. ist das die Lsg. ... was Google bei IPv6 pfuscht, weiß keiner ...
localhost.localdomain kommt nicht gut an...
siehe auch: https://www.abuseat.org/namingproblems.html
Vollkommen in Ordnung in diesem Fall, da RoundCube auf dem selben System läuft wie der MTA. Eine lokale Zustellung macht hier mehr als Sinn und sollte Google nicht tangieren.
On 06.03.2019 07:40, Denny Hanschke wrote:
Am 05.03.19 um 23:36 schrieb Frank Belau:
Am 05.03.19 um 22:24 schrieb Walter H.:
On 05.03.2019 21:18, Walter H. wrote:
On 05.03.2019 20:08, J. Fahrner wrote:
Am 2019-03-05 19:55, schrieb Walter H.:
verwendest Du mehrere IPv6 Adressen vom zugeordneten /64-Prefix?
Nein.
gut, damit sind etwaige Probleme gar nicht möglich;
der rDNS ist ident mit dem der IPv4 Adresse
Ja.
die DNS-Name hat einen A Record mit der IPv4 Adresse und einen mit dieser IPv6 Adresse und beides ist im SPF definiert und im SMTP-HELO/EHLO wird exakt dieser DNS-Name verwendet?
Ja.
das ist schon mal gut;
irgendwie hast mich neugierig gemacht;
ich vermute das hier im Header bringt das Problem ...
Received: from server.fahrner.name (server.fahrner.name [88.198.89.240]) by myMX (Postfix) with ESMTPS id 7043F63C18 for<My-Email>; Tue, 5 Mar 2019 21:44:36 +0100 (CET) Received: from roundcube.fahrner.name (localhost.localdomain [127.0.0.1]) by server.fahrner.name (Postfix) with ESMTP id E4D5E100531 for<My-Email>; Tue, 5 Mar 2019 21:44:32 +0100 (CET)
der obere Eintrag ist OK, aber im Kombination mit dem unteren Eintrag kann er Gift sein, weil roundcube.fahrner.name löst mit einer echten IP auf (der selben wie server.fahrner.name)
Wo siehst du da ein Problem? Cnames sind doch kein Verbrechen.
nein, aber dann sollte dies an Stelle von localhost.localdomain [127.0.0.1] auch so vorkommen;
einfach den unteren Eintrag per Header-Check wegfiltern ...
vlt. ist das die Lsg. ... was Google bei IPv6 pfuscht, weiß keiner ...
localhost.localdomain kommt nicht gut an...
siehe auch: https://www.abuseat.org/namingproblems.html
Vollkommen in Ordnung in diesem Fall, da RoundCube auf dem selben System läuft wie der MTA. Eine lokale Zustellung macht hier mehr als Sinn und sollte Google nicht tangieren.
darum einfach per header_checks wegfiltern ... -> 'was ich nicht weiß, macht mich nicht heiß'
* Uwe Drießen driessen@fblan.de:
Dann mal pur Technisch und das alle dran Teilhaben
DNS Prüfen
Scheinbar geht Google SEHR tief in die DNS records
Prüfen mit
https://zonemaster.net/domain_check
alle Unstimmigkeiten bereinigen
Soa Records inkl. Gültigkeiten DNS Server mit PTR versehen Nameserver in 2 unterschiedlichen AS liegen (idealerweise) Usw. usw
Wenn da bestimmte Dinge zusammen kommen die nicht stimmen gibt es eins auf die Glocke :-)
Danke für die Recherche.
Hmmm, trifft auf sys4.de nicht zu. Da gibt es Dinge, die der Check sogar als "error" vermerkt und wir können dennoch per v6 nach googleland senden.
p@rick
P.S.
Das Problem scheint weitaus tiefer zu liegen
Mit freundlichen Grüßen
Uwe Drießen -- Software & Computer
Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner !
Uwe Drießen Lembergstraße 33 67824 Feilbingert
Tel.: 06708660045
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Im Auftrag von Patrick Ben Koetter
mir war bewusst, dass Dir das nicht gefallen würde und ich habe Deine Antwort erwartet.
Ich bleibe dabei: Niemand darf die Mailingliste dazu nutzen, andere dazu aufzurufen jemandem Schaden zuzufügen. Ob es möglich ist, tatsächlich auch Schaden zu verursachen, ist dabei nicht von Bedeutung.
p@rick
Über Missstände, Benachteiligung, Machtmissbrauch(absichtlich oder Gedankenlos) darf sich ab sofort keiner mehr aufregen
Jep Deswegen darf keiner mehr Streiken , Warnstreiks werden ab sofort verboten. Protest darf ebenfalls nicht mehr stattfinden.
Das schadet ALLES irgendjemandem
Die anderen werden das schon regeln, die anderen werden schon wissen was zu tun ist .... (ganz dunkle Zeit) Immer wegschauen, sich nicht einmischen ? ..
Und übermorgen können wir alle nur noch über die großen Konzerne Kommunizieren..... 1984 lässt grüßen :-)
Sorry alles keine Antwort auf die Fragen der vielen betroffenen Mail Server Betreiber 5 oder sechs der Betroffenen melden sich auf den Mailingslisten, betroffen werden einigen tausend sein, die Dunkelziffer ist da wesentlich höher
Es werden Lösungen gesucht. Es werden Ideen gesucht wie die Betroffenen GEHÖR bekommen oder sich Gehör verschaffen können.
Webseiten Formulare haben BIS DATO KEINEN der Betroffenen auch nur ein Stück der Lösung nähergebracht. (über die hab ich mich schon vor Jahren geärgert) Das Krumm biegen ist KEINE Garant für Erfolg (mindestens 3 kenne ich denen der Erfolg verwehrt wurde ) Dann warten wir mal bis das es auch Dich erwischt (was ich wirklich keinem Wünsche)
Nicht das es passiert ist schlimm , das kommt immer mal wieder vor. - - Das nicht wissen WARUM es passiert - - das NICHTS dagegen TUN können - - den eigenen Kunden KEINE LÖSUNG oder Erklärung geben können Das macht einen Wahnsinnig
Wer da selber mal davon Betroffen war der weiß wovon ich rede.
Wie weit wollen wir noch zuwarten ? Bis das wir bei jedem der Konzerne ein eigenes Mailkonto brauchen wenn wir mit deren Kunden kommunizieren möchten ? Bis das die Freiheit weiter so eingeschränkt wird das wir nur noch das tun was die von uns verlangen ? Bis das auch das Telefon davon betroffen ist und du nicht einfach mehr mit irgendjemandem zu einem beliebigen Zeitpunkt wann es dir gerade passt telefonieren kannst ?
Wer Emotionen auf die Art und weiße weckt darf sich über Außergewöhnliche Reaktionen nicht wundern.
Ja ich habe kein Problem meinem Ärger Luft zu machen und auch mal EINDEUTIG zu schreiben. Ich sehe das so langsam als ein Angriff auf die Möglichkeit der freien Kommunikation und es geht in Richtung Internetzensur wenn sowas passiert. Wenn es keine Informationen darüber gibt dann ist das Willkür.
Mit freundlichen Grüßen
Uwe Drießen - -- Software & Computer
Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner !
Uwe Drießen Lembergstraße 33 67824 Feilbingert
Tel.: 06708660045
On 04.03.2019 15:33, Uwe Drießen wrote:
Google Germany GmbH 040 8 08 17 90 00
meinst wohl Irland oder so, Dtl. hat +49 ...
und was sollte mir der Unfug sagen?
On 01.03.2019 19:24, J. Fahrner wrote:
Am 2019-03-01 18:29, schrieb Patrick Ben Koetter:
Ich denke es ist nicht zulässig von "IPv6 wird bei mir abgelehnt" auf "Mailprovider zu doof (...) IPv6 richtig zu implementieren" zu schliessen.
Sorry, aber als Diplom-Informatiker sehe ich das anders. IPv4 oder IPv6 sind nichts anderes als Transportschichten. Semantisch DARF das keinen Unterschied machen. Wenn es das doch tut, dann ist auf einer Seite was faul. Meine Seite habe ich mittlerweile ausgeschlossen, auch reverse DNS ist sichergestellt.
wieviele IPv6 Adressen des gesamten /64-Prefixes hast Du bei deinem vServer im Einsatz? ein Tipp:
verwende
smtp_bind_address6 = IPv6-Adresse
und genau f. diese IPv6-Adresse gibt es einen rDNS Eintrag, welcher per DNS wieder zu dieser IPv6-Adresse führt ...
und weiters befindet sich im SPF der Domain folgendes: "v=spf1 ip4:IPv4addr ip6:IPv6addr -all" (so habe ich es bei mir)
Am 01.03.19 um 18:29 schrieb Patrick Ben Koetter:
- J. Fahrner jf@fahrner.name:
Am 2019-03-01 09:32, schrieb lst_hoe02@kwsoft.de:
Ist fast schon so lange wie wir IPv6 haben ein Problem. Bei Google werden immer wieder IPv6 Verbindungen abgewiesen wenn sie ein (temporäres) Problem mit der PTR Auflösung haben. Wir haben deshalb schon seit Jahren einen IPv4 Only Transport für diese technischen Leuchten.
Ehrlich gesagt ist mir das zu blöd, mein ganzes Postfix-Setup zu verhunzen, nur weil ein Mailprovider zu doof ist IPv6 richtig zu implementieren. Auch wenn der Google heisst.
doof passt in der Tat nicht, so wie ich das in Erinnerung habe hat Google einfach strengere Antispam Regeln fuer IPv6, und das macht vermutlich aus deren Sicht auch Sinn, seit jeder Pfurz eine Ipv6 Adresse inkl smtp hat, werden die da vermutlich uebelst zugemuellt.
Der Eingriff um das in postfix zu umgehen ist minimal und durchaus vertretbar, da gibts wirklich schlimmeres....
Ich denke es ist nicht zulässig von "IPv6 wird bei mir abgelehnt" auf "Mailprovider zu doof (...) IPv6 richtig zu implementieren" zu schliessen. Bei uns läuft google und IPv6 störungsfrei und ich bin sicher, wir haben keinen Feenstaub über unserem Postfix ausgeschüttet.
Einen oder mehrere workaround-Transporte stellen – meine persönliche Meinung – kein "Verhunzuen" dar. Ich denke es gibt einfach zu viel Spielraum für Interpretation im SMTP-Standard und in E-Mails (MIME...), um von einer einzigen Wahrheit ausgehen zu können.
Ich fahre deshalb den Ansatz, dass ich mich auf mein Ziel "ich will sicher transportieren und mit hoher Wahrscheinlicheit zustellen" konzentriere. Ich könnte auch "Recht haben", aber dann habe ich halt Recht und nichts zugestellt.
Könnte man nicht im unbound irgendwas machen, damit für Google keine AAAA-Records geliefert werden?
Möglicherweise. In Postfix hast Du sehr wahrscheinlich in viel kürzerer Zeit eine Lösung umgesetzt.
My 2ct
p@rick
* J. Fahrner jf@fahrner.name:
Am 2019-02-27 18:56, schrieb Robert Schetterer:
google hat zb mal pauschal etliche Hetzner Ips/Netze gesperrt
Meiner ist bei Hetzner. Das wäre ja ne schöne Sauerei :-(
Das Netz von Hetzner war über lange Zeit hinweg ein Netz von dem viel Abuse ausging. In 2018 hat Hetzner sich aber sehr reingehängt und den Abuse signifikant eingedämmt.
Sicher hat das heute noch Einfluss, aber ich kann mir nur schwer vorstellen, dass dies das einzige Kriterium sein dürfte. Das wäre zu fehleranfällig und ich denke niemand, der heute so große Plattformen betreibt, will sich absichtlich viel Arbeit mit "Falsch Positiven" machen.
p@rick
Am 27.02.19 um 18:56 schrieb Robert Schetterer:
Am 27.02.19 um 12:46 schrieb J. Fahrner:
Hallo Liste, Google blockt in letzter Zeit Mails von meinem Server an Gmail Accounts.
***@gmail.com: host gmail-smtp-in.l.google.com[2a00:1450:400c:c09::1b] said: 550-5.7.1 [2a01:4f8:c17:12f8::2 12] Our system has detected that this 550-5.7.1 message is likely unsolicited mail. To reduce the amount of spam sent 550-5.7.1 to Gmail, this message has been blocked. Please visit 550-5.7.1 https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1 for more information. q9si858297wmf.73 - gsmtp (in reply to end of DATA command)
Hat jemand eine Idee was die da prüfen um zu dem Ergebnis zu kommen?
Jochen
google hat zb mal pauschal etliche Hetzner Ips/Netze gesperrt da musste man eine form ausfuellen...hab ich aber grad nicht parat
Es fällt eben auf das einige Spammer anscheinend bei denen ein zu Hause gefunden haben. Ebenso bei MyLoc... Server und Domain mieten, verbrennen, neue IP, neue Domain, wieder verbrennen und so geht das schon seit einer gefühlten Ewigkeit!
participants (10)
-
Denny Hanschke -
Frank Belau -
Gregor Hermens -
J. Fahrner -
lst_hoe02＠kwsoft.de -
Martin Steigerwald -
Patrick Ben Koetter -
Robert Schetterer -
Uwe Drießen -
Walter H.