https://futurezone.at/digital-life/k…uropa/401169037
eines ist sicher, wenn es wirklich mal zu einem gröberen Blackout kommt,
dann in der kalten Jahreszeit;
https://futurezone.at/digital-life/k…uropa/401169037
eines ist sicher, wenn es wirklich mal zu einem gröberen Blackout kommt,
dann in der kalten Jahreszeit;
hat man bald keine Kunden mehr.
die verliert man auch so;![]()
wer die whitelist von UCEPROTECT sehen will, hab sie ausgewertet
Naja, du lieferst keinen wirklichen Ansatz, wie man Spam-Traps und anderen Unfug beim Double-Opt-In automatisiert erkennen kann.
wer sagt denn dass dies automatisiert gehen muss;
und technisch betrachtet sind alle E-mailadressen gültig, welche nach RFC irgendwas korrekt sind; nur genau darum geht es nicht;
es geht viel mehr darum, dass man hier eine sorgfältige Pflege macht;
Mailadressen mit Domains der großen Mailanbieter wie z.B. GMX, Yahoo, Gmail, MSN, ... sollte man grundsätzlich kritisch betrachten;
und in Bezug auf das vor dem @, ist bei manchem auch Vorsicht angebracht;
wenn jemand als Namen Fritz angibt aber bei der E-mail franz@ dann würd ich das schon mal verwerfen;
sind hier Zahlen wie z.B. max2019, dann suggeriert das eine Wegwerfadresse, welche ich ebenso verwerfen würde;
ein max1963, ist hier nicht unbedingt besser; mag sein, dass das sein Geburtsjahr ist, kann aber einfach nur die Tatsache,
dass es sich ebenfalls um eine Wegwerfadresse handelt ein wenig verschleiern;
wie gesagt das geht halt nicht vollautomatisch; und der Aufwand, wenn man damit verhindert auf einer Blacklist zu landen, muss einem das Wert sein;
und eine andere Sache: ich hatte vor x Jahren mal bei den Verkehrsbetrieben hier im Kuhdorf Fahrgastinfos per SMS 'bestellt', die gabs kostenlos und sind es auch heute noch; und einmal im Jahr kommt ein SMS, bei der man aufgefordert wird, mit "Ja" zu antworten, wenn man diesen Dienst weiter haben will;
analoges gilt auch f. Newsletter; einmal die E-mailadresse bestätigt, ist kein Freibrief an diese bis zum St. Nimmerleinstag den Newsletter zu versenden;
einfach regelmäßig mit einem neutralem Mail - dafür genügt ein text/plain-Mail - fragen,
ob man den Newsletter weiter haben will, dies aber so gestalten, dass man tätig werden muss, wenn man diesen weiter haben will;
wer nicht binnen einer sehr kurzen Frist - max. 48-72 Stunden - reagiert, automatisch aus dem Mailverteiler entfernen;
die Gestaltung von Newslettern an sich, ist eine 2schneidige Geschichte;
- ein reines text/plain-Mail -> super
- ein HTML-Mail, welches noch halbwegs normal formatiert ist, keine Resourcen einbindet -> nicht ganz so gut, aber geht
- ... da gibts noch ein paar Abstufungen; ...
- ein HTML-Mail, welches ohne Resourcen von Dritter Stelle gar nicht lesbar ist -> kompletter Pfusch
alternativ zu einem HTML-Mail, einfach ein Text-Mail, mit einem Link auf eine Website, die den Newsletter darstellt;
so kann man Newsletter nachlesen;
zum Austrragen von Mailadressen durch den Adressaten selbst; muss dieser einen Link klicken, dann wird im Browser bereits angezeigt
z.B. "ihre Adresse wurde aus dem Verteiler entfernt", und hier braucht es echt keine Bestätigung dafür per E-mail ...
gibt noch mehr was man machen kann, um seine Reputation zu verbessern;
ein Reply-To mit noreply@domain.tld ist ein absolutes NoGo
etwas zur Technik: die Adressaten im BCC und To-Feld die selbe Mail-Adresse wie im From ist zwar ein gangbarer Weg, aber optimal ist hier es persönlicher zu gestalten; jedem seinen Newsletter mit dem Adressaten im To Feld;
Nachtrag: man liest hier Argumente, welche eigentlich das Vorgehen von UCEPROTECT rechtfertigen;
manche stoßen sich halt an dem nicht vorhanden Impressum; das ist aber vollkommen unerheblich;
Fakt ist: es muss etwas geschehen, dass unerwünschte E-mails¹ eingedämmt werden;
¹ dazu zählen f. mich unerwünschte "Newsletter" genauso wie Mails mit kriminellen Hintergedanken, wie z.B. Phishing, Verbreitung von Malware, ...;
nur weil man am Server (der empfangende Server) Mittel und Wege gefunden hat, dies deutlich zu reduzieren möglicherweise sogar komplett abzustellen,
es ist dennoch ein leider immer größer werdendes Problem;
wenn ich mich an einen Shop mal erinnere, lange bevor es die DSGVO gab, da fragt man sich dann auch;
bevor ich noch die Bestellung tatsächlich im System hatte, wurde mein Postkasten mit mehr als 3(!) Mails beglückt;
- Bestätigen sie ihr neu angelegtes Kundenkonto
- Danke, dass sie ein Kundenkonto angelegt haben; mit einem überflüssigem Gutschein in Beilage
- Ihre Zugangsdaten zum Konto
- Ein Newsletter: zudem niemand explizit zugestimmt hatte
da immer mehr Angebote, z.B. Online-Zeitungen nur noch Teile kostenlos dem Publikum zur Ansicht zur Verfügung stellen,
und den Rest verbergen und nur gegen Entgelt - meist im Abo - anbieten, würde es mich ehrlich gesagt nicht überraschen,
auf einmal f. das Versenden von E-mails eine Art Porto bezahlen zu müssen;
deren E-Mails
sollten dann auch deren E-mailadressen haben, hatten sie aber nicht, sonst wären sie ja angekommen![]()
ist eine Frage der Erwartungshaltung;
wenn ich einen Brief von X erwarte dann darf sich X nicht wundern wenn sein Brief mit Absender Y ungeöffnet im Papierkorb landet, oder?
so ist das auch bei E-mails ...
worauf du dieses als "Ursache allen Übels" bezeichnet hast?
darum hier:
das Double-Opt in ist nicht die Narrenfreiheit des Serverbetreibers, ungeschaut jeden Quark ungesehen rausgehen zu lassen ...
nun klar?
julian-w das war ja klar; wenn man nur die Hälfte liest und dann was anderes meint sind immer die anderen schuld;
Was schlägst du denn als Lösung vor?
zuerst einmal sicher nicht viollautomatisch ohne vorher gesehen zu haben wo die E-mails so hingehen;
tab hats vorgeschlagen; Double Opt-In ...
wo mich die ganzen Pfuscher so richtig erschreckt haben ..., bei einem Covid-19 Test hier in unserem Kuhdorf,
man gibt hier f. das Testergebnis natürlich E-mail und Tel-Nr. an, und wer versendet die Mail?
falsch: nicht die Stadt selbst, sondern man bedient sich einem Dienstleister a la Mailjet, der zu doof ist,
die Mail auch korrekt abzusenden¹ zum einem und zum anderen so freizügig sensible Daten wegzugeben;
¹ knallten natürlich retour, weil dass ich Mails mit Absender mailjet.com erwarte halte ich f. ein Gerücht ...![]()
Es gibt nun einmal Nutzer, die Newsletter, Benachrichtigungen oder auch Passwort-vergessen-Mails erhalten wollen.
verstehe ich, und hier mal etwas unterscheiden;
wer schaut denn wenn er einen Newsletter versendet, ob da Mails retour kommen, welche hindeuten, dass da die eine od. ander E-mailadresse den Newsletter sicher nicht empfangen hat, und somit aus der Liste unverzüglich gestrichen werden MUSS ...
und 'Passwort-vergessen'-Mails dürfen ohnehin nur an eine zuvor validierte E-mailadresse gehen; selbiges f. Benachrichtigungen; ansonsten hast hier schon einen gröberen Designfehler;
..., wird automatisch eine E-Mail zur Verifizierung der Adresse gesendet.
dass das die Ursache allen Übels ist ..., sollte einem auch klar sein;![]()
da man spamtrap adressen sicher nicht einfach maschinell erkennen kann
das nicht, aber hier prallen halt 2 Welten aufeinander:
E-mailadressen, die den Anschein haben, dass es sich um Wegwerfadressen handle zum einem
und die Geschichte mit Privatsphäre und so ...
ne spamtrap email steht die jemand wundervoll missbrauchen kann um andere auf die Liste zu schicken
oder aber wie bescheuert jemand sein muss, dass er es immer noch nicht schnallt, dass er sich seinen Quark von Newsletter sparen kann,
wenn er zu doof ist, seine Adressen-Liste sorgfältig zu pflegen;
Aber leider kann man so auch nicht gucken ob man die in seiner (ansonsten legitimen) Newsletter-Adressliste hat und wie sie da reingekommen sind. :-/
da gibts ein einfach sehr effektives und primitives Mittel;
einfach alle paar Monate die Adressliste entleeren, wer den Newsletter nicht bekommt, obwohl er ihn wollte trägt sich bestimmt wieder ein;
der Rest war nicht wirklich interessiert;
in die Spamfallen eingeliefert
welche IPs/Hosts sind denn diese sogenannten SPAM-Fallen?
Zuallermindest wenn die Website (auch) in der dortigen Landessprache angeboten wird
das sagt nichts aus;
es geht sogar soweit, dass obwohl die Website in Dt. Sprache ist, dich ein Laden auf die intl. Seite in Englisch verweisen darf;
dass man damit potentielle Kunden womöglich verschreckt ist ein anderes Kapitel, aber genau das macht(e) ein Laden,
wie ich bei was bestimmten angefragt habe; dort ist die Website in Deutsch (.de) echt nur f. Kunden in Deutschland;
f. in Österreich/Schweiz ansässige Kunden, wurde man allen Ernstes auf die intl. Seite (.com) in Englisch mit überteuerten sachlich nicht nachvollziehbaren Preisen verwiesen, nebenbei waren die Preisangaben in US$;
ich habs sein lassen ...
Wenn er auf dem deutschen Markt Waren oder Dienstleistungen anbietet, dann muss er sich an das deutsche Wettbewerbsrecht halten, weil er im Wettbewerb zu deutschen Anbietern steht. Dazu zählt u.a. auch die Impressumspflicht.
das kann so nicht stimmen; weil sobald ein Online-Shop den Versand nach Dtl. nicht explizit ausschließt, ..., müsste f. ihn demnach Dt. Recht gelten, obwohl vlt. sogar außerhalb der EU ansässig ...
Edit: Gut, die Firma sitzt nicht in DE. Dann halt eine Abuse-Mitteilung an den entsprechenden Hoster. Dieser sitzt nämlich in DE.
wenn des dann auch solche Dumpfbacken sind, wie hinter abuse@t-online.de od. so, dann kannst Dir des gleich sparen;
Super "moderne" Webseite ohne Impressum
daran stossen sich anscheinend einige; nur diese Impressumspflicht ist in Dt. Recht verankert;
und der Urheber einer Seite kann auch Staatsbürger eines anderen Landes sein, und unterliegt somit NICHT Dt. Recht;
wo der Server steht ist dabei unerheblich - genau das sagen die auch;
nicht UCEPROTECT muss beweisen nicht der Impressumspflicht zu unterliegen,
sondern die Gegenseite, die sich daran stößt, dass ...;
darum viel Spaß mit der Abmahnindustrie, welche es nebenbei bemerkt auch nur in Dtl. gibt;
es ist in vielen Köpfen noch nicht manifestiert, dass es im Internet keine nationalen Grenzen gibt;
aber dennoch kein rechtsfreier Raum ist;
aber ganze Netze aufgrund weniger Meldungen für mindestens eine Woche zu sperren, verursacht fast immer großen Kollateralschaden.
wie heisst es so schön: "mitgehangen, mitgefangen" ![]()
(ich blockier auch ganze .TLDs¹, weils f. mich keinen Sinn ergibt, ich muss nicht jeden Quark annehmen)
¹ sagen wir es so, ein paar TLDs gehen durch der Rest wird rejected;
da du ja im Log https://cp.meinedomain.com/... hast,
ist das da ganz unten https://letsencrypt.org/de/docs/challenge-types/ eine Hilfe?
Was auch noch wichtig ist, ist die alte MAC-Adresse des VPS durch die neue MAC-Adresse des RS zu ersetzen,
da ansonsten aus Sicherheitsgründen nach außen hin zum Internet keine Verbindung zugelassen wird.
je nach Linux Distri, sollte man sich nicht wundern, wenn man das erste mal dann neu startet evtl. ein eth1 an Stelle des gewohnten eth0 vorzufinden;
das liegt daran, dass die MAC-Adresse vom VPS noch mit eth0 verbunden ist,
dieses Device aber nicht vorgefunden wird,
hingegen das vorgefundene Device mit einer neuen MAC-Adresse als weiteres NIC-Interface ins System hinzugefügt wird/wurde;
dies kann man aber rückgängig machen;
z.B. bei CentOS gibts hier /etc/udev/rules.d/70-persistent-net.rules
die Möglichkeit dies zu korrigieren;
Achtung: nicht automatisiert alles einfach ersetzen; man könnte damit evtl. doppelte Einträge verursachen;
ich mach das bei mir so:
ich gehe ins Verz /etc und lass mir folgenden Ausgaben machen
grep ipaddr * -r
grep ipv6prefix * -r
grep macaddr * -r
und sehe mir die ausgeworfenen Files an und ändere diese manuell;
zur Kontrolle wiederholt man diese Ausgaben einfach;
ist ein postfix am Laufen, dann scheinen die Files auch hier auf,
manche braucht man nur mittels postmap ... neu generieren,
dies aber erst nachdem mit den neuen MAC-/IP[6]-Adressen alles läuft;
Am besten vorher die TTL der DNS-Einträge auf einen möglichst kleinen Wert setzen (z.B. 60 Sekunden). Dann geht der Schwenk auch was flotter.
Achtung: aber auch das braucht mind. 48 h bis es überall bekannt ist; soll heißen, dass man dies rechtzeitig, bevor man derartiges vorhat macht;
vom Zeitpunkt des Übersiedelns aus betrachtet bringt das nichts mehr;
am einfachsten gehts mit Offline Snapshot, diesen exportieren beim alten VPS und dann am neuen RS diesen Export als Image neu einspielen;
und die neuen IP(v6) Adressen überall wo die halt vorkommen austauschen; im CCP die DNS-Einträge ändern, den alten VPS noch mitlaufen lassen (max 48 h, so lange dauerts bis die DNS-Einträge überall bekannt;
und die SSL-Zertifikate sind die selben, weil ja die selbe Domain;