Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.mailserver > #5952 > unrolled thread

Wie arbeiten Blacklist

Back to article view | Back to de.comm.software.mailserver

Contents

  Wie arbeiten Blacklist Jan Novak <repcom@gmail.com> - 2018-08-23 09:53 +0200
    Re: Wie arbeiten Blacklist Sven Hartge <sh-188@svenhartge.de> - 2018-08-23 14:24 +0200
      Re: Wie arbeiten Blacklist Jan Novak <repcom@gmail.com> - 2018-08-23 16:27 +0200
    Re: Wie arbeiten Blacklist Arno Welzel <usenet@arnowelzel.de> - 2018-08-23 20:10 +0200
      Re: Wie arbeiten Blacklist Erik Heinz <eh1808-usenet@42net.de> - 2018-08-23 20:55 +0000
        Re: Wie arbeiten Blacklist Sven Hartge <sh-188@svenhartge.de> - 2018-08-24 09:00 +0200
          Re: Wie arbeiten Blacklist Jan Novak <repcom@gmail.com> - 2018-08-24 09:10 +0200
            Re: Wie arbeiten Blacklist Sven Hartge <sh-188@svenhartge.de> - 2018-08-24 09:14 +0200
              Re: Wie arbeiten Blacklist Jan Novak <repcom@gmail.com> - 2018-08-24 12:00 +0200
      Re: Wie arbeiten Blacklist Frank Graf <f.graf@firemail.de> - 2018-08-25 09:49 +0000
        Re: Wie arbeiten Blacklist Arno Welzel <usenet@arnowelzel.de> - 2018-08-26 07:47 +0200
      Re: Wie arbeiten Blacklist "Andreas M. Kirchwitz" <amk@spamfence.net> - 2018-08-25 13:39 +0000
        Re: Wie arbeiten Blacklist Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2018-08-25 16:11 +0000
        Re: Wie arbeiten Blacklist Thomas Gohel <gohel@basicguru.de> - 2018-08-25 20:06 +0200
          Re: Wie arbeiten Blacklist Arno Welzel <usenet@arnowelzel.de> - 2018-08-26 07:48 +0200
            Re: Wie arbeiten Blacklist Thomas Gohel <gohel@basicguru.de> - 2018-08-26 14:20 +0200
              Re: Wie arbeiten Blacklist Arno Welzel <usenet@arnowelzel.de> - 2018-08-27 09:10 +0200
                Re: Wie arbeiten Blacklist Thomas Gohel <gohel@basicguru.de> - 2018-08-27 16:53 +0200
                  Re: Wie arbeiten Blacklist Arno Welzel <usenet@arnowelzel.de> - 2018-08-29 18:30 +0200

#5952 — Wie arbeiten Blacklist

Hallo,

ich suche Informationen darüber, wie Mail Blacklists im Internet (RBL) 
z.B. IP Adressen auf ihre Liste nehmen, wie sie an diese Informationen 
heran kommen und welcher Teil einer Mail dafür genommen wird.

Wir hatten gerade eine Diskussion darüber, das es angeblich nichts mehr 
bringen würde, Mails vom eigenen Mailserver über einen Mailserver beim 
Provider zu senden (relay).

Jan

[toc] | [next] | [standalone]

#5953

Jan Novak <repcom@gmail.com> wrote:

> ich suche Informationen darüber, wie Mail Blacklists im Internet (RBL)
> z.B. IP Adressen auf ihre Liste nehmen, wie sie an diese Informationen
> heran kommen und welcher Teil einer Mail dafür genommen wird.

Das ist höchst variabel.

Die Blockliste der iX von Heise
(https://www.heise.de/ix/NiX-Spam-DNSBL-und-Blacklist-zum-Download-499634.html)
z.B. wird aus deren In-House-Spam-Erkennung befüllt.

Andere basieren auf Honeypots, wiederum andere auf manuellen Berichten
und bei einigen ist nicht öffentlich bekannt, wo die Daten herkommen.

Ich nutze z.B. http://multirbl.valli.org/lookup/ um mir einen Überblick
über die Situation der von mir betreuten Mailsysteme zu verschaffen. Der
Dienst kenn 233 DNS-RBLs, 32 Whitelists und noch diverse andere
DNS-basierte Dienste.

> Wir hatten gerade eine Diskussion darüber, das es angeblich nichts
> mehr bringen würde, Mails vom eigenen Mailserver über einen Mailserver
> beim Provider zu senden (relay).

Aktuell wird es immer schwerer Mails an die großen Mail-Provider
abzusetzen, wenn man nicht durch diverse Reifen hüpft.

Und wenn man einen Server bei einem Hoster wie Hetzner oder Strato hat,
wird man gerne in Sippenhaft für deren kompletten Netzblock genommen, je
nachdem, was die "Nachbarn" so treiben.

Das gleiche Schicksal hat man natürlich, wenn man über einen ISP
relayed. Wenn deren Reputation des Mailrelays schlecht ist, dann hängt
man auch mit drin.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#5954

Am 23.08.18 um 14:24 schrieb Sven Hartge:
> Jan Novak <repcom@gmail.com> wrote:
> 
>> ich suche Informationen darüber, wie Mail Blacklists im Internet (RBL)
>> z.B. IP Adressen auf ihre Liste nehmen, wie sie an diese Informationen
>> heran kommen und welcher Teil einer Mail dafür genommen wird.
> 
> Das ist höchst variabel.
> 
> Die Blockliste der iX von Heise
> (https://www.heise.de/ix/NiX-Spam-DNSBL-und-Blacklist-zum-Download-499634.html)
> z.B. wird aus deren In-House-Spam-Erkennung befüllt.
> 
> Andere basieren auf Honeypots, wiederum andere auf manuellen Berichten
> und bei einigen ist nicht öffentlich bekannt, wo die Daten herkommen.
> 
> Ich nutze z.B. http://multirbl.valli.org/lookup/ um mir einen Überblick
> über die Situation der von mir betreuten Mailsysteme zu verschaffen. Der
> Dienst kenn 233 DNS-RBLs, 32 Whitelists und noch diverse andere
> DNS-basierte Dienste.
> 
>> Wir hatten gerade eine Diskussion darüber, das es angeblich nichts
>> mehr bringen würde, Mails vom eigenen Mailserver über einen Mailserver
>> beim Provider zu senden (relay).
> 
> Aktuell wird es immer schwerer Mails an die großen Mail-Provider
> abzusetzen, wenn man nicht durch diverse Reifen hüpft.
> 
> Und wenn man einen Server bei einem Hoster wie Hetzner oder Strato hat,
> wird man gerne in Sippenhaft für deren kompletten Netzblock genommen, je
> nachdem, was die "Nachbarn" so treiben.
> 
> Das gleiche Schicksal hat man natürlich, wenn man über einen ISP
> relayed. Wenn deren Reputation des Mailrelays schlecht ist, dann hängt
> man auch mit drin.

Hallo Sven,

danke für die Infos!


Jan

[toc] | [prev] | [next] | [standalone]

#5955

Jan Novak:

> Hallo,
> 
> ich suche Informationen darüber, wie Mail Blacklists im Internet (RBL) 
> z.B. IP Adressen auf ihre Liste nehmen, wie sie an diese Informationen 
> heran kommen und welcher Teil einer Mail dafür genommen wird.
> 
> Wir hatten gerade eine Diskussion darüber, das es angeblich nichts mehr 
> bringen würde, Mails vom eigenen Mailserver über einen Mailserver beim 
> Provider zu senden (relay).

Eher umgekehrt - es wird immer schwerer, Mails vom eigenen Server an die
großen Provider loszuwerden. Mindestens wird SPF und DMARC verlangt und
bei GMail ist die Anlieferung über IPv6 eher Glückssache, weshalb ich
explizt dafür per IPv4 ausliefere.


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

[toc] | [prev] | [next] | [standalone]

#5956

* Arno Welzel wrote:
>
> Eher umgekehrt - es wird immer schwerer, Mails vom eigenen Server an die
> großen Provider loszuwerden. Mindestens wird SPF und DMARC verlangt und
> bei GMail ist die Anlieferung über IPv6 eher Glückssache, weshalb ich
> explizt dafür per IPv4 ausliefere.

DMARC habe ich mir erspart. Geht trotzdem stabil. Irgendwie spielen auch
noch Reputations-Geschichten eine Rolle. Bei einem privaten Server kann man
das in den Griff bekommen.

Ein Relay macht es nicht besser. SPF wird schwieriger zu konfigurieren (was
ist, wenn der Provider seinen externen Adressen ändert?) und man wird von
der Reputation des Relayservers abhängig.

Gruß,
Erik

[toc] | [prev] | [next] | [standalone]

#5957

Erik Heinz <eh1808-usenet@42net.de> wrote:

> Ein Relay macht es nicht besser. SPF wird schwieriger zu konfigurieren (was
> ist, wenn der Provider seinen externen Adressen ändert?)

Daher gibt es dann bei SPF "include:example.com", mit dem man dann die
Einträge von "example.com" inkludieren kann.

Idealerweise hat der Relay-Provider etwas wie "_netblocks.example.com"
im DNS, dessen SPF-Record nur die IPs beinhaltet, so dass man dies
dann via include einbinden kann und damit dann automatisch variabel ist.

(Siehe z.B. "host -t txt _netblocks.google.com").

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#5958

Am 24.08.18 um 09:00 schrieb Sven Hartge:
> Erik Heinz <eh1808-usenet@42net.de> wrote:
> 
>> Ein Relay macht es nicht besser. SPF wird schwieriger zu konfigurieren (was
>> ist, wenn der Provider seinen externen Adressen ändert?)
> 
> Daher gibt es dann bei SPF "include:example.com", mit dem man dann die
> Einträge von "example.com" inkludieren kann.
> 
> Idealerweise hat der Relay-Provider etwas wie "_netblocks.example.com"
> im DNS, dessen SPF-Record nur die IPs beinhaltet, so dass man dies
> dann via include einbinden kann und damit dann automatisch variabel ist.
> 
> (Siehe z.B. "host -t txt _netblocks.google.com").

Bevor ich jetzt total verwirrt bin:
Wenn ich Mail unseres hausinternen Servers über den Provider relayen 
will (über ein Login einer 2. Domain), soll ich dann einen SPF Record 
für unsere Domain anlegen oder nicht?


Jan

[toc] | [prev] | [next] | [standalone]

#5959

Jan Novak <repcom@gmail.com> wrote:
> Am 24.08.18 um 09:00 schrieb Sven Hartge:
>> Erik Heinz <eh1808-usenet@42net.de> wrote:
>> 
>>> Ein Relay macht es nicht besser. SPF wird schwieriger zu konfigurieren (was
>>> ist, wenn der Provider seinen externen Adressen ändert?)
>> 
>> Daher gibt es dann bei SPF "include:example.com", mit dem man dann die
>> Einträge von "example.com" inkludieren kann.
>> 
>> Idealerweise hat der Relay-Provider etwas wie "_netblocks.example.com"
>> im DNS, dessen SPF-Record nur die IPs beinhaltet, so dass man dies
>> dann via include einbinden kann und damit dann automatisch variabel ist.
>> 
>> (Siehe z.B. "host -t txt _netblocks.google.com").

> Bevor ich jetzt total verwirrt bin:
> Wenn ich Mail unseres hausinternen Servers über den Provider relayen 
> will (über ein Login einer 2. Domain), soll ich dann einen SPF Record 
> für unsere Domain anlegen oder nicht?

Wenn du das machst, dann musst du wissen, über welche IPs dein
Relay-Provider diese nach außen schickt, weil du diese in den
SPF-Record eintragen musst, damit Mail für dich noch funktioniert.

*Und* du musst den SPF-Record immer an IP-Adress-Änderungen deines
Relay-Providers anpassen.

Um letzteres nicht manuell machen zu müssen, gibt es "include:host.name"
im SPF-Record-Standard, um einen anderen SPF-Record einbinden zu können.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#5960

Am 24.08.18 um 09:14 schrieb Sven Hartge:
> Jan Novak <repcom@gmail.com> wrote:
>> Am 24.08.18 um 09:00 schrieb Sven Hartge:
>>> Erik Heinz <eh1808-usenet@42net.de> wrote:
>>>
>>>> Ein Relay macht es nicht besser. SPF wird schwieriger zu konfigurieren (was
>>>> ist, wenn der Provider seinen externen Adressen ändert?)
>>>
>>> Daher gibt es dann bei SPF "include:example.com", mit dem man dann die
>>> Einträge von "example.com" inkludieren kann.
>>>
>>> Idealerweise hat der Relay-Provider etwas wie "_netblocks.example.com"
>>> im DNS, dessen SPF-Record nur die IPs beinhaltet, so dass man dies
>>> dann via include einbinden kann und damit dann automatisch variabel ist.
>>>
>>> (Siehe z.B. "host -t txt _netblocks.google.com").
> 
>> Bevor ich jetzt total verwirrt bin:
>> Wenn ich Mail unseres hausinternen Servers über den Provider relayen
>> will (über ein Login einer 2. Domain), soll ich dann einen SPF Record
>> für unsere Domain anlegen oder nicht?
> 
> Wenn du das machst, dann musst du wissen, über welche IPs dein
> Relay-Provider diese nach außen schickt, weil du diese in den
> SPF-Record eintragen musst, damit Mail für dich noch funktioniert.
> 
> *Und* du musst den SPF-Record immer an IP-Adress-Änderungen deines
> Relay-Providers anpassen.
> 
> Um letzteres nicht manuell machen zu müssen, gibt es "include:host.name"
> im SPF-Record-Standard, um einen anderen SPF-Record einbinden zu können.


Ahhhhh verstehe ... OK, super, vielen Dank nochmal.

Jan

[toc] | [prev] | [next] | [standalone]

#5961

Am Thu, 23 Aug 2018 20:10:02 +0200 schrieb Arno Welzel:

> Jan Novak:
>> ich suche Informationen darüber, wie Mail Blacklists im Internet (RBL)
>> z.B. IP Adressen auf ihre Liste nehmen, wie sie an diese Informationen
>> heran kommen und welcher Teil einer Mail dafür genommen wird.
>> 
>> Wir hatten gerade eine Diskussion darüber, das es angeblich nichts mehr
>> bringen würde, Mails vom eigenen Mailserver über einen Mailserver beim
>> Provider zu senden (relay).
> 
> Eher umgekehrt - es wird immer schwerer, Mails vom eigenen Server an die
> großen Provider loszuwerden. Mindestens wird SPF und DMARC verlangt und
> bei GMail ist die Anlieferung über IPv6 eher Glückssache, weshalb ich
> explizt dafür per IPv4 ausliefere.

Ich habe keine Schwierigkeiten per IPv6 bei Google abzuliefern. Mails 
werden nicht als SPAM markiert. Ich habe einen billigen Root-Server bei 
OVH. SPF habe ich eingerichtet.

Aus dem Header einer Mail:

Received-SPF: pass (google.com: domain of ......de designates 
2001:41d0:.....:1 as permitted sender) client-ip=2001:41d0:......:1;


Frank

[toc] | [prev] | [next] | [standalone]

#5965

Frank Graf:

> Am Thu, 23 Aug 2018 20:10:02 +0200 schrieb Arno Welzel:
> 
>> Jan Novak:
>>> ich suche Informationen darüber, wie Mail Blacklists im Internet (RBL)
>>> z.B. IP Adressen auf ihre Liste nehmen, wie sie an diese Informationen
>>> heran kommen und welcher Teil einer Mail dafür genommen wird.
>>>
>>> Wir hatten gerade eine Diskussion darüber, das es angeblich nichts mehr
>>> bringen würde, Mails vom eigenen Mailserver über einen Mailserver beim
>>> Provider zu senden (relay).
>>
>> Eher umgekehrt - es wird immer schwerer, Mails vom eigenen Server an die
>> großen Provider loszuwerden. Mindestens wird SPF und DMARC verlangt und
>> bei GMail ist die Anlieferung über IPv6 eher Glückssache, weshalb ich
>> explizt dafür per IPv4 ausliefere.
> 
> Ich habe keine Schwierigkeiten per IPv6 bei Google abzuliefern. Mails 
> werden nicht als SPAM markiert. Ich habe einen billigen Root-Server bei 
> OVH. SPF habe ich eingerichtet.
> 
> Aus dem Header einer Mail:
> 
> Received-SPF: pass (google.com: domain of ......de designates 
> 2001:41d0:.....:1 as permitted sender) client-ip=2001:41d0:......:1;

Und bei mir geht es eben nicht. Die Mails landen sofort im Spamfilter
bei Google, wenn sie über IPv6 kommen. SPF habe ich, ebenso wie DMARC -
hat nichts genützt.

Erst seit ich für Google die Auslieferung über IPv4 vornehme, kommen die
Mails auch an.


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

[toc] | [prev] | [next] | [standalone]

#5962

Arno Welzel <usenet@arnowelzel.de> wrote:

>> Wir hatten gerade eine Diskussion darüber, das es angeblich nichts mehr 
>> bringen würde, Mails vom eigenen Mailserver über einen Mailserver beim 
>> Provider zu senden (relay).
>
> Eher umgekehrt - es wird immer schwerer, Mails vom eigenen Server an die
> großen Provider loszuwerden.

Manchmal habe ich das Gefühl, die großen Mailanbieter sind sich
untereinander allerdings auch nicht immer ganz grün, da hat also
keineswegs jeder bedingungslos jeden anderen in einer Whitelist.

> Mindestens wird SPF und DMARC verlangt und
> bei GMail ist die Anlieferung über IPv6 eher Glückssache, weshalb ich
> explizt dafür per IPv4 ausliefere.

Bisher hat (für mich) SPF gereicht, wobei es vor allem überhaupt
existieren muss, keineswegs muss man besonders restriktiv sein.
DMARC scheint bisher nicht erforderlich zu sein.

Allerdings weiß man bei Google leider nie genau, welcher Einlieferer
welche Hürden zu überwinden hat. Scheint ein Würfelspiel zu sein.

	Grüße, Andreas

[toc] | [prev] | [next] | [standalone]

#5963

On Sat, 25 Aug 2018 15:39:12 Andreas M. Kirchwitz wrote:
> Allerdings weiß man bei Google leider nie genau, welcher Einlieferer
> welche Hürden zu überwinden hat. Scheint ein Würfelspiel zu sein.
 
Am ärgerlichsten finde ich, dass das Ergebnis nicht konstant ist,
man aber beim Einliefern genau gar keinen Hinweis darauf bekommt, ob
die Mail akeztpiert, als Spam einsortiert oder gleich komplett
verworfen wird.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Professionell? Professioneller als Stefan!? Zweifel unerwünscht!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#5964

Hallo Andreas,

> Manchmal habe ich das Gefühl, die großen Mailanbieter sind sich
> untereinander allerdings auch nicht immer ganz grün, da hat also
> keineswegs jeder bedingungslos jeden anderen in einer Whitelist.

Das liegt auch daran, dass die Honks der großen Anbieter ständig
ihre genutzten Mailserver in ihrem IP-Bereich hin und her schieben
oder ständig andere verwenden. Da hilft auch kein Whitelisting
mehr ...

Den Vogel hat aber letztens Domainfactory abgeschossen, als bei der
Kündigung diverser Domains der gesetzte SPF-Record nicht einmal mit
dem Absender übereinstimmte.


Tschau,

  --------------
   / h o m a s
-- 
Der neue Internet Trend:  Abstossende Postings!  Verfasse  die Mail in
HTML,  niemals mit Realnamen,  haenge immer das  Original-Posting  als
Fullquote an die Antwort, signiere alles konsequent mit einer Visiten-
karte und Du wirst reichlich die diversen Filter begluecken. :-)))))))

[toc] | [prev] | [next] | [standalone]

#5966

Thomas Gohel:

> 
> Hallo Andreas,
> 
>> Manchmal habe ich das Gefühl, die großen Mailanbieter sind sich
>> untereinander allerdings auch nicht immer ganz grün, da hat also
>> keineswegs jeder bedingungslos jeden anderen in einer Whitelist.
> 
> Das liegt auch daran, dass die Honks der großen Anbieter ständig
> ihre genutzten Mailserver in ihrem IP-Bereich hin und her schieben
> oder ständig andere verwenden. Da hilft auch kein Whitelisting
> mehr ...
> 
> Den Vogel hat aber letztens Domainfactory abgeschossen, als bei der
> Kündigung diverser Domains der gesetzte SPF-Record nicht einmal mit
> dem Absender übereinstimmte.

Bei Domainfactory will man sowieso nichts mehr nutzen:

<https://www.heise.de/newsticker/meldung/Datenleck-bei-Domainfactory-Kunden-sollen-Passwoerter-aendern-4104495.html>


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

[toc] | [prev] | [next] | [standalone]

#5967

Hallo Arno,

>> Den Vogel hat aber letztens Domainfactory abgeschossen, als bei der
>> Kündigung diverser Domains der gesetzte SPF-Record nicht einmal mit
>> dem Absender übereinstimmte.
> Bei Domainfactory will man sowieso nichts mehr nutzen:
>
> <https://www.heise.de/newsticker/meldung/Datenleck-bei-Domainfactory-

Die haben ganz andere und auch viel größere Probleme als das Datenleck,
glaube mir ...


Tschau,

  --------------
   / h o m a s
-- 
Permanent Online Filter fuer: User ohne Realnamen im From:-Feld, Full-
quotes (zitieren  des originalen  Postings unter der eigenen Antwort),
Visitenkarten, HTML-Postings, Invalid- und ungueltige Email-Adressen

[toc] | [prev] | [next] | [standalone]

#5968

Thomas Gohel:

> 
> Hallo Arno,
> 
>>> Den Vogel hat aber letztens Domainfactory abgeschossen, als bei der
>>> Kündigung diverser Domains der gesetzte SPF-Record nicht einmal mit
>>> dem Absender übereinstimmte.
>> Bei Domainfactory will man sowieso nichts mehr nutzen:
>>
>> <https://www.heise.de/newsticker/meldung/Datenleck-bei-Domainfactory-
> 
> Die haben ganz andere und auch viel größere Probleme als das Datenleck,
> glaube mir ...

Was ist denn aus Kundensicht noch schlimmer, als die Preisgabe von
Kundendaten inkl. Adressen, Bankdaten und Schufaauskünftige?


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

[toc] | [prev] | [next] | [standalone]

#5969

Arno Welzel meinte zum Thema "Re: Wie arbeiten Blacklist"

Hallo Arno,

>>> Bei Domainfactory will man sowieso nichts mehr nutzen:
>> Die haben ganz andere und auch viel größere Probleme als das
>> Datenleck, glaube mir ...
> Was ist denn aus Kundensicht noch schlimmer, als die Preisgabe von
> Kundendaten inkl. Adressen, Bankdaten und Schufaauskünftige?

Da liegt mir der seit Frühjahr 2018 ausgelagerte Admin- & Support-
Zugriff auf die komplette DomainFactory-Infrastruktur an über 50 Sub-
Unternehmen aus einem nicht europäischen Land im Magen, in dem zudem
gerade Bürgerkrieg herrscht. Damit wird die DSGVO und die bestehenden
ADVs bei DF als absurdum geführt.

ADV bei DF interesssieren mich aber schon eine geraume Zeit nicht mehr,
denn nach dem Umzug des Rechenzentrums nach Frankreich (zu dem Zeitpunkt
herrschte dort Ausnahmezustand und besondere polizeiliche Zugriffsrechte
auf die IT-Infrastruktur) hatte sich das Hosting jeder Art bei DF bereits
sowieso erledigt.

Momentan ziehen die reinen Domains um, denn beim reinen DNS-Hosting hat
sich seit gefühlt 10 Jahren auch nicht mehr getan -> kein IPv6, keine
neuen Records der letzten 10 Jahre und ein Eigenleben des DNS-Servers,
der bestimmte Sub-Domains trotz gesetztem Wildcard-A-Record auf die
Infrastruktur von DF umbiegt. Letzters Eigenleben führt halt immer
wieder zu falschen automatischen Einrichtungen und/oder Fehlermeldungen
(SSL-Cert-Errors) bei TB & K-9.

Mir fehlt ansonsten jegliche Innovationen bei DF, man wird ständig
vertröstet (an Technik gegeben) und die ganze Menüstruktur riecht
Sicherheitstechnisch m.E. auch nach Steinkohle. Gefühlt wurde DF in
den letzten Jahren nur als Masse ständig von einer anderen Heuschrecke
geschluckt und verwertet.

Ansonsten is DF seit dem Datenleck komplett abgetaucht. Selbst die c't
scheint da nicht mehr durch zu kommen. Letztlich wird da auch nichts
mehr passieren. DF ist an die Host-Europe-Group verkauft worden und nun
komplett mit HEG bei GoDaddy gelandet. Zu GoDaddy will man auch nicht
wirklich und somit wird sich mein Weg nach bald knapp 15 Jahren, von dem
in der Zwischenzeit ausbluteten Unternehmen namens DF, trennen.

Wie gesagt, das Datenleck ist für mich nur ein leichtes Knirschen im
Gebälk von DF.

Schade, war doch DomainFactory früher sehr innovativ und spezialisiert,
aber da wurden sie ja noch von den Gründern geführt, naja.


Tschau,

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

[toc] | [prev] | [next] | [standalone]

#5970

Thomas Gohel:

> Arno Welzel meinte zum Thema "Re: Wie arbeiten Blacklist"
> 
> Hallo Arno,
> 
>>>> Bei Domainfactory will man sowieso nichts mehr nutzen:
>>> Die haben ganz andere und auch viel größere Probleme als das
>>> Datenleck, glaube mir ...
>> Was ist denn aus Kundensicht noch schlimmer, als die Preisgabe von
>> Kundendaten inkl. Adressen, Bankdaten und Schufaauskünftige?
> 
> Da liegt mir der seit Frühjahr 2018 ausgelagerte Admin- & Support-
> Zugriff auf die komplette DomainFactory-Infrastruktur an über 50 Sub-
> Unternehmen aus einem nicht europäischen Land im Magen, in dem zudem
> gerade Bürgerkrieg herrscht. Damit wird die DSGVO und die bestehenden
> ADVs bei DF als absurdum geführt.

Das ist ja nur die Ursache dieser Probleme. Die Folge sind dann eben
solche Vorfälle, wie bei heise berichtet wurde.

[...]
> Schade, war doch DomainFactory früher sehr innovativ und spezialisiert,
> aber da wurden sie ja noch von den Gründern geführt, naja.

In dem Moment, wo die Steigerung von finanziellem Gewinn um jeden Preis
wichtiger wird, als ein nachhaltiger Geschäftsbetrieb, entwickelt sich
jede Firma so. Besonders hellhörig sollte man immer werden, wenn eine
Firma verkauft wird. Entweder ist der Laden dann schon in extremer
Schieflage oder die Inhaber haben sich durch Investorengeld blenden lassen.

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

[toc] | [prev] | [standalone]

Back to top | Article view | de.comm.software.mailserver

csiph-web