Mails kommen nicht bei Gmail an

[Rudolf Harras]

Es ist zum verzweifeln... Ich habe ja schon vor einiger Zeit berichtet:

Mails von meinem Mail-Provider (kleinere Firma) landen Bei Gmail
Adressen regelmäßig im Spam. Und die ganze Welt verwendet Gmail, selbst
manchmal im Hintergrund - so dass das einfach funktionieren muss.

Ich habe dann auf den SMTP-Server meines Internet-Providers umgestellt
und mit dem kommen die Mails bei Google an.

Leider habe ich keine Ahnung was man hier machen kann, die Spam-Tester
sagen nämlich genau gegenteiliges und sind somit wertlos. Keine Ahnung
wie man noch rausfinden kann warum Google blockt.


Mein Mail-Provider (landet bei Google im Spam):

isnotspam.com
X-Spam-Status: Yes, hits=3.7 required=-20.0 tests=BAYES_99,BAYES_999,
RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no
version=3.4.1

mail-tester.com
Wow! Perfekt, Sie können diese Email senden!
Score: 9/10

1 Punkt abzug für: Ihre Nachricht ist nicht durch DKIM signiert



Mein Internet-Provider (kommt bei Google durch):

Isnotspam.com
X-Spam-Status: Yes, hits=4.4 required=-20.0 tests=BAYES_99,BAYES_999,
RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL,URIBL_BLOCKED autolearn=no
autolearn_force=no
version=3.4.1

mail-tester.com
Ihre Email wird nie einen Posteingang von innen sehen
Score: 0.5/10

Punkteabzüge:
-1 SPF: sender does not match SPF record (softfail)
-3 [SPF] xxx.xx gestattet Ihrem Server xxx nicht, x...@xxx.xx zu nutzen
-3 [Sender ID] xxx.xx gestattet Ihrem Server xxx nicht, x...@xxx.xx zu nutzen
-1 kein DKIM
-1.5 Sie werden in 2 Blacklists geführt (in Backscatterer und Lashback)

[Rudolf Harras]

Kai Bojens schrieb:
> Vorwärts- und Rückwärtsauflösung sind korrekt? SPF Eintrag ist vorhanden
> und korrekt? Die IP ist hier in keiner wesentliche Liste enthalten?
>
> -> http://multirbl.valli.org/

Danke für den Tipp - ich habe mal beide Mailserver verglichen.

Generell hat gerade der Mailserver, der bei GMail geblockt ist, bessere
werte, ist auf weniger Blacklists usw.

Aber folgende eventuell relevanten Unterschiede gibt es zu dem Server,
der problemlos funktioniert:

Mailserver 2 ist
- nicht auf der Whiteliste nszones.com (die ohnehin nur ein DNSBL-Fake ist)
- auf folgenden Blacklists: dnsblchile.org und rbl.rbldns.ru
- Zusätzlicher Fail auf KISA-RBL (spamlist.or.kr - DNS request failed:
The name server was unable to process this query due to a problem with
the name server.)



Dann nochmal im Detail:

Funktionierender Mailserver:
Not listed / Blacklisted / Brownlisted / Yellowlisted / Whitelisted
/Neutralistet / Failed
212/6/0/0/0/0/9
8/0/1/1/0/1/0
27/0/0/0/3/0/1
4/0/0/0/0/12/0

Mailserver 2 - der mit Gmail nicht mag:
215/2/0/0/0/0/10
8/0/0/0/2/1/0
28/0/0/0/2/0/1
4/0/0/0/0/12/0


Hmm... Vielleicht eine der beiden Blacklists?

[Juergen P. Meier]

Rudolf Harras <rudolf...@mailinator.com>:
["besserer" Mailserver wird von Google geblockt]

Hast du mal ein neues Googlemail-Konto eingerichtet
(default-einstellung, insb. bei Kundenspezifischen Spam-Filtern) und
damit getestet?

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

[Rudolf Harras]

Juergen P. Meier schrieb:

> Rudolf Harras <rudolf...@mailinator.com>:
> ["besserer" Mailserver wird von Google geblockt]
>
> Hast du mal ein neues Googlemail-Konto eingerichtet
> (default-einstellung, insb. bei Kundenspezifischen Spam-Filtern) und
> damit getestet?

Ja. Landet dort auch im Spam.

Mittlerweile sogar bei MSN:

host mx4.hotmail.com[65.54.188.94] said: 550
SC-001 (BAY004-MC2F28) Unfortunately, messages from 178.33.76.18
weren't sent. Please contact your Internet service provider since part
of their network is on our block list. You can also refer your provider
to http://mail.live.com/mail/troubleshooting.aspx#errors. (in reply to
MAIL FROM command)

Der check bei sämtlichen hier empfohlenen oder sonstwo gefundenen
Test-Seiten ergibt nichts außergewöhnliches bzw. sogar bessere Werte als
beim SMTP-Server von inode.at, wo aber die Mails problemlos ankommen.

[Sven Hartge]

Ich habe das AS (Autonome System) des ISPs, welches für die IP
178.33.76.18 das AS16276 (Provider ist OVH SAS) ist, mal gegen die
interne AS-Spam-Datenbank von $arbeitgeber geworfen und dabei eine
"Spamizität" von 62% oder 9 von 15 Punkten (gerechnet über die letzten
90 Tage) erhalten.

Das würde auch obige Meldung erklären. Der Server selbst ist nicht
gelistet, steht aber halt in sehr schlechter Nachbarschaft, über 60% der
Mails von diesem Provider sind $hier SPAM.

Grüße,
Sven.

--
Sigmentation fault. Core dumped.

[Rudolf Harras]

Sven Hartge schrieb:

> Ich habe das AS (Autonome System) des ISPs, welches für die IP
> 178.33.76.18 das AS16276 (Provider ist OVH SAS) ist, mal gegen die
> interne AS-Spam-Datenbank von $arbeitgeber geworfen und dabei eine
> "Spamizität" von 62% oder 9 von 15 Punkten (gerechnet über die letzten
> 90 Tage) erhalten.
>
> Das würde auch obige Meldung erklären. Der Server selbst ist nicht
> gelistet, steht aber halt in sehr schlechter Nachbarschaft, über 60% der
> Mails von diesem Provider sind $hier SPAM.

Danke.

Ich fürchte das erklärt das Problem. Der Provider selbst ist in Ordnung,
aber wird durch "schlechte Nachbarschaft" überall unschuldig geblockt.

Auch die Whitelist hat von "Low Trust" auf "No Trust" zurückgesstuft,
auf meine Anfrage warum das passiert ist habe ich Fragmente von einer
Diskussion über schlechte Nachbarschaft und ob das sinnvoll ist erhalten.

Da stellt sich die Frage: Was bedeutet diese "schlechte Nachbarschaft"
und was kann man dagegen machen?

[Sven Hartge]

Rudolf Harras <rudolf...@mailinator.com> wrote:
> Sven Hartge schrieb:

>> Ich habe das AS (Autonome System) des ISPs, welches für die IP
>> 178.33.76.18 das AS16276 (Provider ist OVH SAS) ist, mal gegen die
>> interne AS-Spam-Datenbank von $arbeitgeber geworfen und dabei eine
>> "Spamizität" von 62% oder 9 von 15 Punkten (gerechnet über die letzten
>> 90 Tage) erhalten.
>>
>> Das würde auch obige Meldung erklären. Der Server selbst ist nicht
>> gelistet, steht aber halt in sehr schlechter Nachbarschaft, über 60% der
>> Mails von diesem Provider sind $hier SPAM.

> Danke.

> Ich fürchte das erklärt das Problem. Der Provider selbst ist in
> Ordnung, aber wird durch "schlechte Nachbarschaft" überall unschuldig
> geblockt.

Nein, der Host für den Server, OVH, hat einen bekannt schlechten Ruf.

> Auch die Whitelist hat von "Low Trust" auf "No Trust" zurückgesstuft,
> auf meine Anfrage warum das passiert ist habe ich Fragmente von einer
> Diskussion über schlechte Nachbarschaft und ob das sinnvoll ist
> erhalten.

> Da stellt sich die Frage: Was bedeutet diese "schlechte Nachbarschaft"
> und was kann man dagegen machen?

"schlechte Nachbarschaft" meint, das andere Server bei diesem Provider
falsch konfiguriert sind und daher für den SPAM-Versand mißbraucht
werden oder aktiv von SPAMmern angemietet und für eben diese Zwecke
genutzt werden und der Hoster nichts dagegen unternimmt, weil ihm das
Geld der unfähigen und "kriminellen" Kunden wichtiger ist, wie seine
Reputation.

Die einzige Lösung, um das Problem zu lösen ist, den Server zu einem
anderen Hoster umzuziehen oder, falls es sich nicht um seinen Server
sondern einen Server einer Firma handelt, deren Dienste du nutzt (ich
habe den Thread jetzt nicht ganz gelesen), eben eine andere Firma zu
verwenden, die ihre Server eben nicht bei einem Hoster mit schlechter
Reputation hostet.

[Sven Hartge]

Rudolf Harras <rudolf...@mailinator.com> wrote:
> Sven Hartge schrieb:

>> Ich habe das AS (Autonome System) des ISPs, welches für die IP
>> 178.33.76.18 das AS16276 (Provider ist OVH SAS) ist, mal gegen die
>> interne AS-Spam-Datenbank von $arbeitgeber geworfen und dabei eine
>> "Spamizität" von 62% oder 9 von 15 Punkten (gerechnet über die letzten
>> 90 Tage) erhalten.
>>
>> Das würde auch obige Meldung erklären. Der Server selbst ist nicht
>> gelistet, steht aber halt in sehr schlechter Nachbarschaft, über 60% der
>> Mails von diesem Provider sind $hier SPAM.

> Danke.

> Ich fürchte das erklärt das Problem. Der Provider selbst ist in
> Ordnung, aber wird durch "schlechte Nachbarschaft" überall unschuldig
> geblockt.

Nein, der Host für den Server, OVH, hat einen bekannt schlechten Ruf.

> Auch die Whitelist hat von "Low Trust" auf "No Trust" zurückgesstuft,
> auf meine Anfrage warum das passiert ist habe ich Fragmente von einer
> Diskussion über schlechte Nachbarschaft und ob das sinnvoll ist
> erhalten.

> Da stellt sich die Frage: Was bedeutet diese "schlechte Nachbarschaft"
> und was kann man dagegen machen?

"schlechte Nachbarschaft" meint, das andere Server bei diesem Hoster

falsch konfiguriert sind und daher für den SPAM-Versand mißbraucht
werden oder aktiv von SPAMmern angemietet und für eben diese Zwecke
genutzt werden und der Hoster nichts dagegen unternimmt, weil ihm das
Geld der unfähigen und "kriminellen" Kunden wichtiger ist, wie seine
Reputation.

Die einzige Lösung, um das Problem zu lösen ist, den Server zu einem
anderen Hoster umzuziehen oder, falls es sich nicht um seinen Server
sondern einen Server einer Firma handelt, deren Dienste du nutzt (ich
habe den Thread jetzt nicht ganz gelesen), eben eine andere Firma zu
verwenden, die ihre Server eben nicht bei einem Hoster mit schlechter
Reputation hostet.

[Ulli Horlacher]

Sven Hartge <sh-...@svenhartge.de> wrote:

> Ich habe das AS (Autonome System) des ISPs, welches für die IP
> 178.33.76.18 das AS16276 (Provider ist OVH SAS) ist

OVH ist ein UEBLER Spammerprovider.
Von denen nehm ich grundsaetzlich nichts an.


--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum IZUS/TIK E-Mail: horl...@tik.uni-stuttgart.de
Universitaet Stuttgart Tel: ++49-711-68565868
Allmandring 30a Fax: ++49-711-682357
70550 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

[Sven Hartge]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Sven Hartge <sh-...@svenhartge.de> wrote:

>> Ich habe das AS (Autonome System) des ISPs, welches für die IP
>> 178.33.76.18 das AS16276 (Provider ist OVH SAS) ist

> OVH ist ein UEBLER Spammerprovider. Von denen nehm ich grundsaetzlich
> nichts an.

Ja.

Wenn hier (17.000 Benutzer an einer Hochschule) schon 60% der gescannten
Mails (nicht alle User haben den Spam-Erkenner angeschaltet, warum auch
immer) aus dem AS von OVH SPAM sind, wie mag das erst bei einem
lohnenderen Ziel wie Gmail oder Hotmail aussehen? Da ist die Quote
vermutlich deutlich schlechter.

S°

[Ulli Horlacher]

Sven Hartge <sh-...@svenhartge.de> wrote:

> > OVH ist ein UEBLER Spammerprovider. Von denen nehm ich grundsaetzlich
> > nichts an.
>

> Wenn hier (17.000 Benutzer an einer Hochschule) schon 60% der gescannten
> Mails (nicht alle User haben den Spam-Erkenner angeschaltet, warum auch
> immer) aus dem AS von OVH SPAM sind, wie mag das erst bei einem
> lohnenderen Ziel wie Gmail oder Hotmail aussehen? Da ist die Quote
> vermutlich deutlich schlechter.

Das schlimme daran ist nicht mal die Spamquote, sondern dass OVH absolut
NICHT auf Beschwerden reagiert! Die lassen ihren Kunde froehlich
weiterspammen! Sie verdienen ja gut daran.

[Sven Hartge]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Sven Hartge <sh-...@svenhartge.de> wrote:

>>> OVH ist ein UEBLER Spammerprovider. Von denen nehm ich
>>> grundsaetzlich nichts an.

>> Wenn hier (17.000 Benutzer an einer Hochschule) schon 60% der
>> gescannten Mails (nicht alle User haben den Spam-Erkenner
>> angeschaltet, warum auch immer) aus dem AS von OVH SPAM sind, wie mag
>> das erst bei einem lohnenderen Ziel wie Gmail oder Hotmail aussehen?
>> Da ist die Quote vermutlich deutlich schlechter.

> Das schlimme daran ist nicht mal die Spamquote, sondern dass OVH
> absolut NICHT auf Beschwerden reagiert! Die lassen ihren Kunde
> froehlich weiterspammen! Sie verdienen ja gut daran.

Naja, klassicher rogue oder black-hat ISP halt.

Die SPAM-Quote ist dann das Ergebnis des Ganzen. Würden sie etwas gegen
den Abschaum im eigenen Netz machen, dann hätte man zwar ab und zu mal
ein offenes Relay oder ein exploitbares PHP-Script, das kommt halt vor,
und nicht die Menge an schon seit Jahren spammenden IPs.

[Rudolf Harras]

Sven Hartge schrieb:

> Die SPAM-Quote ist dann das Ergebnis des Ganzen. Würden sie etwas gegen
> den Abschaum im eigenen Netz machen, dann hätte man zwar ab und zu mal
> ein offenes Relay oder ein exploitbares PHP-Script, das kommt halt vor,
> und nicht die Menge an schon seit Jahren spammenden IPs.

Also laut Provider folgende Auskunft:
Angeblich hat doch OVH einen Scanner, der aber einer gewissen Anzahl an
ausgehen Spams die IP sperrt (ca. 200).
Und: Problem sind auch die Mail-Weiterleitungen. Leitet jemand, der viel
Spam bekommt, seine Mails auf seine Google-Adresse weiter, dann bekommt
Google den Spam vom Mailprovider weitergeschickt und hält ihn vielleicht
für den direkten Spam-Sender.

Was meint ihr dazu?

[Paul Muster]

On 20.09.2015 00:50, Rudolf Harras wrote:
> Sven Hartge schrieb:

>> Die SPAM-Quote ist dann das Ergebnis des Ganzen. Würden sie etwas gegen
>> den Abschaum im eigenen Netz machen, dann hätte man zwar ab und zu mal
>> ein offenes Relay oder ein exploitbares PHP-Script, das kommt halt vor,
>> und nicht die Menge an schon seit Jahren spammenden IPs.
>
> Also laut Provider folgende Auskunft:
> Angeblich hat doch OVH einen Scanner, der aber einer gewissen Anzahl an
> ausgehen Spams die IP sperrt (ca. 200).

Aha. Wie soll das gehen angesichts heutiger Technologie
(TLS-verschlüsselte Verbindung zum MX)?

> Und: Problem sind auch die Mail-Weiterleitungen. Leitet jemand, der viel
> Spam bekommt, seine Mails auf seine Google-Adresse weiter, dann bekommt
> Google den Spam vom Mailprovider weitergeschickt und hält ihn vielleicht
> für den direkten Spam-Sender.

Ja, passiert.

> Was meint ihr dazu?

Provider wechseln. Hatte man dir das nicht bereits vor Tagen empfohlen?


mfG Paul

[Ulli Horlacher]

Rudolf Harras <rudolf...@mailinator.com> wrote:

(OVH)

> Also laut Provider folgende Auskunft:
>

> Was meint ihr dazu?

OVH ist ein Spammer-Provider, der auf Beschwerden NICHT reagiert.
Der wird zu recht boykotiert.

Spam funktioniert nur, weil es solche Provider wie OVH gibt. Die sind DAS
zentrale Problem.

Die deutsche Telekom hatte sich frueher aehnlich verhalten. Bis sie auf
schwarze Listen gelandet sind. Das hat dann schnell deren Einstellung
veraendert :-)

Nur massiver Druck bewirkt hier was. Von alleine loest sich das Problem
nicht.

[Michael Ströder]

Paul Muster wrote:
> On 20.09.2015 00:50, Rudolf Harras wrote:
>> Also laut Provider folgende Auskunft:
>> Angeblich hat doch OVH einen Scanner, der aber einer gewissen Anzahl an
>> ausgehen Spams die IP sperrt (ca. 200).
>
> Aha. Wie soll das gehen angesichts heutiger Technologie
> (TLS-verschlüsselte Verbindung zum MX)?

1. Nur sehr wenige MTAs benutzen SMTP mit STARTTLS.

2. STARTTLS wird ja nur opportunistic benutzt. Der Scanner könnte also
durchaus STARTTLS einfach wegknipsen.

Ciao, Michael.

[Thomas Gohel]

Hallo Michael,

>> Aha. Wie soll das gehen angesichts heutiger Technologie
>> (TLS-verschlüsselte Verbindung zum MX)?
> 1. Nur sehr wenige MTAs benutzen SMTP mit STARTTLS.

In meinem Umfeld nutzen sämtliche STARTTLS-fähige Clients auch STARTTLS
und soweit ich das auch übersehe, wird STARTTLS auch von den meisten
Clients in der Zwischenzeit als Default bei der Einrichtung gesetzt.

> 2. STARTTLS wird ja nur opportunistic benutzt. Der Scanner könnte
> also durchaus STARTTLS einfach wegknipsen.

Ein Provider der aus obigen Gründen einfach mal im laufenden Betrieb
STARTTLS ausschaltet, sollte umgehend an den Pranger gestellt werden.

Tschau,

--------------
/ h o m a s
--
email : sup...@gohel.de / go...@basicguru.de (PGP-Key available)
www : http://www.gohel.de / http://www.pbhq.de (PowerBASIC)
filter: html-postings, fullquotes, no realnames & no valid adresses

[Sven Hartge]

Michael Ströder <mic...@stroeder.com> wrote:

> 2. STARTTLS wird ja nur opportunistic benutzt. Der Scanner könnte also
> durchaus STARTTLS einfach wegknipsen.

So ein Provider gehört umgehend gemieden und öffentlich denunziert.

[Andreas Kohlbach]

Ulli Horlacher wrote on 20. September 2015:
>
> Rudolf Harras <rudolf...@mailinator.com> wrote:
>
> (OVH)
>> Also laut Provider folgende Auskunft:
>>
>> Was meint ihr dazu?
>
> OVH ist ein Spammer-Provider, der auf Beschwerden NICHT reagiert.
> Der wird zu recht boykotiert.

Wird er aber leider nicht.

> Spam funktioniert nur, weil es solche Provider wie OVH gibt. Die sind DAS
> zentrale Problem.

IMO ist das Problem, dass nicht genug Blacklist-Betreiber (z.B. Spamhaus)
"have the balls" (ich weiß gerade nicht, wie man das am besten auf
Deutsch sagen würde ;-), um OVH und Co. so lange zu listen, bis die einen
funktionierenden Abuse-Desk haben, oder verhungert sind.

> Die deutsche Telekom hatte sich frueher aehnlich verhalten. Bis sie auf
> schwarze Listen gelandet sind. Das hat dann schnell deren Einstellung
> veraendert :-)
>
> Nur massiver Druck bewirkt hier was. Von alleine loest sich das Problem
> nicht.

Eben. Aber nicht von Privatleuten, die die Zusammenhänge nicht
sehen. Sonst den Listenbetreibern.

Ich verstehe nicht, warum das gegen die Deutsche Telekom und IIRC auch
1&1 genau so funktionierte, aber gegen OVH nun niemand mal etwas
Handfestes in die Wege leitet.

X'post + F'up2 de.admin.net-abuse.mail
--
Andreas

I use a Unix based operating system, which means I get laid almost as often
as I have to reboot my computer.

[Juergen P. Meier]

begin 1 followup to Michael Ströder <mic...@stroeder.com>:

> Paul Muster wrote:
>> On 20.09.2015 00:50, Rudolf Harras wrote:
>>> Also laut Provider folgende Auskunft:
>>> Angeblich hat doch OVH einen Scanner, der aber einer gewissen Anzahl an
>>> ausgehen Spams die IP sperrt (ca. 200).
>>
>> Aha. Wie soll das gehen angesichts heutiger Technologie
>> (TLS-verschlüsselte Verbindung zum MX)?
>
> 1. Nur sehr wenige MTAs benutzen SMTP mit STARTTLS.

Also ich wuerde das genaue Gegenteil behaupten, wenn ich mir meine
MTA-Logs so anschaue. Allerdigns gilt hier natuerlich: YMMV.

Oder meinst du "Spamversendesprogramme"? Ja, da koenntest du recht
ahben. Die wenigsten davon benutzen wohl STARTTLS.

> 2. STARTTLS wird ja nur opportunistic benutzt. Der Scanner könnte also
> durchaus STARTTLS einfach wegknipsen.

Das ist korrekt. Entsprechened kann man seine Mailsoftware daran
hindern, ohne STARTTLS die Zustellung zu versuchen.

[Sven Hartge]

Andreas Kohlbach <sept15....@spamgourmet.net> wrote:

> Paul Muster wrote on 20. September 2015:
>>
>> On 20.09.2015 00:50, Rudolf Harras wrote:
>>> Sven Hartge schrieb:
>>
>>>> Die SPAM-Quote ist dann das Ergebnis des Ganzen. Würden sie etwas gegen
>>>> den Abschaum im eigenen Netz machen, dann hätte man zwar ab und zu mal
>>>> ein offenes Relay oder ein exploitbares PHP-Script, das kommt halt vor,
>>>> und nicht die Menge an schon seit Jahren spammenden IPs.
>>>
>>> Also laut Provider folgende Auskunft:
>>> Angeblich hat doch OVH einen Scanner, der aber einer gewissen Anzahl an
>>> ausgehen Spams die IP sperrt (ca. 200).
>>
>> Aha. Wie soll das gehen angesichts heutiger Technologie
>> (TLS-verschlüsselte Verbindung zum MX)?

> Es wird einfach die Anzahl der versendeten Mails per IP geprüft, und dann
> ggf. für eine Zeit abgelehnt. Im Log (von z.B. Postfix) kann dann etwas wie

> | status=deferred (host smtp.irgendwas.tld[1.2.3.4] refused to talk to
> | me: 421 Connection limit reached for your IP address)

> In diesem Fall war die Verbindung allerdings nicht verschlüsselt.

Das setzt aber voraus, das man auch das Mailrelay vom Provider nutzt.
Das dürfte im Bereich der Root-Server eher selten bis gar nicht der Fall
sein.

[David Seppi]

Ulli Horlacher schrieb:

> Das schlimme daran ist nicht mal die Spamquote, sondern dass OVH absolut
> NICHT auf Beschwerden reagiert! Die lassen ihren Kunde froehlich
> weiterspammen!

Nicht nur spammen. Ich werde von dort immer wieder mit
ssh/smtp-auth/imap-Loginversuchen bombardiert.
Beschwerden zwecklos.

--
David Seppi
1220 Wien

[Ulli Horlacher]

Deshalb:

logreject 5.39.0.0/17
logreject 5.135.0.0/16
logreject 37.59.0.0/16
logreject 37.187.0.0/16
logreject 46.105.0.0/16
logreject 87.98.128.0/17
logreject 91.121.0.0/16
logreject 94.23.0.0/16
logreject 176.31.0.0/16
logreject 178.32.0.0/15
logreject 188.165.0.0/16
logreject 192.95.0.0/18
logreject 192.99.0.0/16
logreject 213.251.128.0/18

[Rudolf Harras]

Michael Ströder schrieb:

Moment... Wenn ich mit SSL/STARTTLS zu meinem Mailserver verbinde, der
auf einem OVH-Server läuft, dann ist zwar die Verbindung von mir zum
Mail-Server verschlüsselt.

Aber was dann der Mailserver aus dem OVH-Netzwerk rausschickt, ist das
denn noch immer verschlüsselt?

[Juergen P. Meier]

Rudolf Harras <rudolf...@mailinator.com>:

> Michael Ströder schrieb:
>> Paul Muster wrote:
>>> On 20.09.2015 00:50, Rudolf Harras wrote:
>>>> Also laut Provider folgende Auskunft:
>>>> Angeblich hat doch OVH einen Scanner, der aber einer gewissen Anzahl an
>>>> ausgehen Spams die IP sperrt (ca. 200).
>>>
>>> Aha. Wie soll das gehen angesichts heutiger Technologie
>>> (TLS-verschlüsselte Verbindung zum MX)?
>>
>> 1. Nur sehr wenige MTAs benutzen SMTP mit STARTTLS.

Es ist mittlerweile erfreulich haeufig.

>> 2. STARTTLS wird ja nur opportunistic benutzt. Der Scanner könnte also
>> durchaus STARTTLS einfach wegknipsen.

Oder den Handshake auf eine ihm genehme Cipher reduzieren.
Die wenigsten Clients und Server erzwingen TLSv1.2 mit starken
Ciphers. Die wenigsten (komerziellen) Implementierungen *koennen* das
ueberhaupt.

> Moment... Wenn ich mit SSL/STARTTLS zu meinem Mailserver verbinde, der
> auf einem OVH-Server läuft, dann ist zwar die Verbindung von mir zum
> Mail-Server verschlüsselt.

Ja, aber. Ggf. mit RC4 mit export-grade Schluesseln und MD5 Hash.
Oder gleich der beliebte NULL Cipheralgorithmus.

> Aber was dann der Mailserver aus dem OVH-Netzwerk rausschickt, ist das
> denn noch immer verschlüsselt?

Das Kommt Darauf An. Genauer: Ob der Zielsever STARTTLS anbietet und
der OHV-Mailserver das auch nutzt und ob das Aushandeln klappt u.v.m.

PS: Zertifikate werden bei SMTP/STARTTLS im Mailverkehr zwischen
Sender-Relays und MXen in der Praxis garnicht verifiziert.
(bis auf jeweils haendisch konfiguierte Ausnahmen)

[Arno Welzel]

Nö - nicht zwangsläufig. Wieso auch?

Wenn Du deine Mails durchgängig verschlüsselt haben willst, hilft nur
Verschlüsselung der Mails selbst mit PGP oder S/MIME. Nur ein
verschlüsselter Transportweg auf einer Teilstrecke des gesamten Weges
hilft da natürlich nicht.


--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

[Rudolf Harras]

Arno Welzel schrieb:

Naja, dann könnte OVH ja auch alle ausgehenden Mails nach Spam durchsuchen.
Weil hier gesagt wurde, es wäre nicht möglich.

[Arno Welzel]

Ja - sofern das vertraglich mit dem Kunden so vereinbart ist. Sonst nicht.

> Weil hier gesagt wurde, es wäre nicht möglich.

Warum soll das nicht möglich sein? TLS auf dem Transportweg bedeutet ja
nicht, dass die Mail auf dem Server verschlüsselt vorliegen würde,
sondern nur, dass die Verbindung vom Client zum Server verschlüsselt
wird. Genau deswegen gibt es ja PGP und S/MIME.

[Rudolf Harras]

Arno Welzel schrieb:

> Warum soll das nicht möglich sein?

Eben, das habe ich ja gemeint. ;)

> Genau deswegen gibt es ja PGP und S/MIME.

Das 0,003% der Leute nutzen und das in 0,5 von 20 Mail-Clients
komfortabel machbar ist. ;)

[Arno Welzel]

S/MIME ist in fast jedem aktuellen Client von Haus aus drin und für PGP
gibt es Enigmail für Thunderbird und mindestens eine kommerzielle Lösung
für Outlook, die durchaus benutzbar ist.