Weiterleitung von E-Mails an externe Adressen

Weiterleitung von E-Mails an externe Adressen

Warum eine Weiterleitung von E-Mails an externe E-Mail Adressen nicht mehr zeitgemäß ist.
Warum es bessere Möglichkeiten gibt diese Aufgabe zu lösen wenn es denn unbedingt sein muss.
Weshalb eine eigene E-Mail Domain sowieso besser ist.

Viele Kunden leiten, aus verschiedensten Gründen, ihre E-Mails zu Diensten wie gmx.de, gmail.com, outlook.com, t-online.de oder ähnlichen weiter. Dies führt jedoch immer häufiger zu diversen Problemen in der Zustellbarkeit von E-Mails und kann häufig die Domains als „Spamschleuder“ kennzeichnen. Warum das passiert und wie man es besser machen kann.
Im folgenden erklären wir das. Thema an Emil, einen fiktiven Kunden. Viele werden sich in Emil wiedererkennen.

Am Anfang

Am Anfang war da nur Emil, sein Computer und sein T-Online Anschluss. Emil benutzte das Internet häufig und verwendete auch seine EMail Adresse emil.lime@t-online.de. Alles war gut. Emil hatte eine Geschäftsidee und bestellte bei uns ein Webhosting Paket mit der Domain emil.tld. Weil er sein E-Mail Programm schon lange so benutzte stellte er einfach eine Weiterleitung ein und alle E-Mails von info@emil.tld wurden zu seinem t-online.de Konto weiter gesendet.

Das Spam Problem beim Weiterleiten

Einige Zeit klappte das recht gut mit den E-Mails von Emil. Da aber in den letzten Jahren die Spam E-Mails immer häufiger wurden rüsteten alle Provider mit Abwehrtechniken auf. Auch t-online.de. Nun vermisste Emil immer öfters einige seiner E-Mails. Durch seine Weiterleitung leitet Emil auch die E-Mails weiter welche als Spam auf seiner info@ E-Mail Adresse ankommen. Die Spamversender und Emil kennen sich nicht, das müssen sie auch garnicht. Die bösen Spammer benutzen einfach eine Liste mit Internet Domainnamen und senden einfach so auf Verdacht an die info@ Adressen ihren Müll. So erwischte es auch immer öfters Emil. Diese Mails fängt nun an der T-Online Spamschutz zu blockieren. Um das Problem zu verstehen waren die Meldungen seines Mail Programmes Emil leider ein wenig zu technisch:

This is the mail system at host emil.be-webspace.net.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
                   The mail system

<emil.lime@t-online.de>: host mx00.t-online.de[194.25.134.8] said:
    550-5.7.0 Message considered as spam or virus, rejected 550-5.7.0 Your IP:
    93.186.200.78 550-5.7.0 Mailhost: mailin84.aul.t-online.de 550-5.7.0
    Timestamp: 2020-04-08T07:16:30Z 550-5.7.0 Expurgate-ID:
    149288::1586330190-00001049-56F794CA/10/32140550877 550-5.7.0
    Authenticator: 9C6018273308F578B2C07B62525DCCC0351B1BCDF5FCCA940EA8EEC616B7FD63D7CECB68
    550-5.7.0  550-5.7.0 Your message has been rejected due to spam or virus
    classification. 550-5.7.0 If you feel this is inapplicable, please report
    the above error codes 550-5.7.0 back to FPR@RX.T-ONLINE.DE to help us fix
    possible misclassification. 550-5.7.0 We apologize for any inconvenience
    and thank you for your assistance! 550-5.7.0  550-5.7.0 Die Annahme Ihrer
    Nachricht wurde abgelehnt, da sie als Spam oder 550-5.7.0 Virus eingestuft
    wurde. Sollten Sie dies als unzutreffend ansehen, 550-5.7.0 senden Sie
    bitte obige Fehlercodes an FPR@RX.T-ONLINE.DE, damit wir 550-5.7.0 die
    Klassifizierung untersuchen koennen. Wir entschuldigen uns fuer 550 5.7.0
    etwaige Unannehmlichkeiten und bedanken uns fuer Ihre Unterstuetzung! (in
    reply to end of DATA command)

Das passierte immer häufiger, bis eine bestimmte Anzahl an Vorfällen den T-Online Mailserver erreichte und dieser anfing die E-Mails von Emil dauerhaft zu blockieren. Unschuldig rief Emil die Hotline an um sich bei uns zu beschweren.

Das Problem vervielfältigt sich

Wie an diesem Beispiel zu erkennen ist kann eine einfache Weiterleitung von E-Mails bereits zu einem kleinen Problem führen. Zumindest wenn man nur an die Mails von Kunde Emil denkt.

Das Problem vervielfältigt sich aber durch die technische Umsetzung im Hintergrund. Um einen eigenen Mailserver zu haben müsste Emil einen eigenen Server oder zumindest eine eigene IP-Adresse haben. Da ihm das zu teuer ist benutzt er auf unserem Webhosting System einen großen Mailserver, dieser ist aber auch für viele andere Kunden zuständig. Ganz zufällig benutzen auch Karin, Klaus und Kurt eine Weiterleitung zu ihrer t-online.de Adresse. Und auch diese E-Mails, da sie vom selben Mailserver (IP) stammen, werden nun vom Telekom Antispam System geblockt.
Emil sorgt somit auch bei anderen unserer Kunden zu Problemen, davon ahnt er noch nichts. Mit den geblockten EMails von Emil, Karin, Klaus und Kurt nimmt das Volumen geblockter Mails weiter zu, nun geht der Antispam bei T-Online in die nächste Runde. Das Spamschutz System klassiert die IP-Adresse als Spamschleuder und gibt sie an weitere E-Mail Blacklist Dienste weiter. Jetzt werden auch weitere E-Mail Server beginnen E-Mails von diesem Mailserver abzulehnen.

Von uns zu Fremden

Bisher hatte Emil nur Probleme bei E-Mails die er weiterleitet. Plötzlich geht das Problem in die nächste Runde, denn neben Emil haben auch Bernd und Boris Probleme. Diese nutzen aber gar kein T-Online. Bernd ist Benutzer von GMX: Boris nutzt gar keinen E-Mail Dienstleister sondern möchte alle E-Mails nur über seine Domain versenden und empfangen. Da diese aber eventuell die gleichen DNS Blacklist Anbieter benutzen ist auch der Mailverkehr zu diesen blockiert. Aus ein paar wenigen unerwünschten E-Mails an Emil wird ein globales Problem durch welches bei be-webspace.de plötzlich hunderte Kunden betroffen sind. Genug? Noch lange nicht. In der nächsten Stufe der Antispam Massnahmen wird nicht nur eine einzelne IP-Adresse blockiert, sondern ein ganzer Netzwerk Block, Ist dieser voll belegt werden im schlimmen Fall über 200 Server blockiert, tausende Kunden sind betroffen und das Problem ist längst nicht mehr auf t-online, gmx oder gmail begrenzt. Und auch das versenden von eigenen E-Mails ist bei Emil nun ein Problem.
Wenn wir dieses Problem nun analysieren müssen finden wir sehr schnell, in unseren Logfiles, den Verursacher. Wir müssen aufräumen. Insofern möglich müssen wir bei diversen DNS Blacklisten für eine Entsperrung sorgen. Bei den Postmastern von T-Online oder GMX müssen wit ggf noch weitere Erklärungen abgeben damit E-Mails wieder wie gewünscht transportiert werden.

Wie macht man es richtig

Wenn es wirklich unbedingt sein muss das man Googlemail, T-Online, GMX, Outlook oder ähnliche als seinen primären E-Mail Service benutzen möchte dann schickt man E-Mails nicht einfach weiter.
Diese Anbieter haben in der Regel alle einen Service bei dem sie die E-Mails über POP3 von euerer Domain abholen. Bei dieser Art und Weise werden die Mails nicht via SMTP übertragen sondern gelangen auf direktem Weg, ohne DNS Blacklist oder andere Dienste in das Postfach beim E-Mail Hoster. Natürlich gelangen auch Spam Emails dann weiter zu GMX und Co. Was diese im Endeffekt mit dem Spam machen liegt in deren Vorgehen begründet. Emil zum Beispiel muss dann den Spamfilter bei t-online entsprechend konfigurieren.
Der Vorteil für Emil: Es kommen sicher alle E-Mails da an wo er sie haben möchte.
Der Vorteil für andere: Emil kann mit dieser Art und Weise nicht auslösen das auch viele andere Probleme mt ihrer E-Mail Zustellbarkeit bekommen.

Möglichst automatisch keine E-Mails extern weiterleiten

Wir könnten hier nun einen simplen Schater umlegen und was weiterleiten von Mails an externe Adressen komplett unterbinden. Das wäre in Sekunden erledigt. Wir wissen aber auch das es Anwendungsfälle gibt bei denen das vielleicht auch Sinn macht und notwendig ist. Mit dieser geblockten Variante wären nur interne Weiterleitungen möglich, zum Beispiel wenn mehrere Mitarbeiter in der Firma eine Art Verteiler erhalten sollen. Der Weg nach extern und dss Spamproblem wären gelöst.
Wir wissen das viele Anwender aber nach wie vor Weiterleitungen zu Gmail, GMX oder T-Online verwenden, diese einfach blockieren ist für uns auch keine Variante.

Was wir aber in naher Zukunft nicht mehr zulassen können ist die Tatsache das verbrannte Domains oder E-Mail Adressen solch ein Volumen an Mails und Spam Inhalten weiterleiten das oben beschriebenes Szenario war wird. Dann schaden diese E-Mail Adressen nicht nur dem Anwender selbst sondern auch vielen anderen Kunden die den selben Mailserver auf dieser IP Adresse benutzen. Im Sinne aller Kunden müssen wir dann tätig werden und die Weiterleitungen unterbinden.

Benutzt die eigene Domain für eure E-Mails

Wer auch immer eine Webseite betreibt dem empfehlen wir auch diese Domain für die E-Mails zu verwenden. Nicht nur weil die einfach viel professionellerer aussieht als wenn Business EMails von Gmail oder GMX Adressen kommen. Zudem hat das auch andere Vorteile. Das Spamvolumen bei den großen Mail Dienstleistern kann durchaus sogar größer sein wenn man seine Postfächer sauber hält. Und auch Anbieter wie T-Online, GMX oder auch web.de landen mal auf Blacklist Sperrlisten.
Des weiteren lassen sich E-Mails auf unserer Hosting Plattform mit DKIM klar signieren, im Falle von Problemen lassen sich Logfiles entsprechend auswerten uvm.
Ein wichtiges Argument ist auch das Thema Datenschutz. Nicht nur das die Werbung wie auf den Portalen von GMail oder GMX entfällt, die Inhalte der Mails werden auch nicht von Dritten, aus welchen Gründen auch immer, mitgelesen. Und es ist jederzeit möglich ein Backup der Postfächer zu erstellen, herunterzuladen und zu archivieren. Mit IMAP ist zudem ein perfektes Arbeiten auch mit mehreren Geräten oder Personen möglich. Wer Webmail benötigt kann zwischen Roundcube und Horde wählen.

SSL für eure Mailserver

SSL für eure Mailserver

Plesk 18 ist hier. Alle Webhosting Systeme haben wir bereits umgestellt. Die größte Neuerung, mit der neuen Version Plesk Obsidian, für Webhosting Kunden, ist die Unterstützung eines eigenen Zertifikates für die Mailserver, sowie die autmatische Einrichtung von Thunderbird oder Outlook .

E-Mail mit SSL

Mit dem SNI Support für Mailserver gehören Zertifikatswarnungen bei Outlook oder Thunderbird der Vergangenheit an. Wenn ihr eure Domain mit einem SSL Zertifikat gesichert habt (kostenlos mit Letsencrypt oder andere eigene Zertifikate), so könnt ihr diese absofort auch für euren Mailserver setzen lassen.
Dazu geht in Plesk bei eurer Domain zu den E-Mail Einstellungen und wählt das entsprechende Zertifikat bei SSL/TLS Zertifikat für E-Mail aus.
Als Mailserver für SMTP, POP3 oder IMAP konfiguriert ihr nur eure Domain.

Autodiscover

Eine weitere Verbesserung bringt die Einführung von Autodiscover für E-Mail Einstellungen mit sich. Zur Zeit wird Thunderbird und Outlook unterstützt.
Aktivierung: E-Mail Einstellungen – Enable mail autodiscover aktivieren.

Damit genügt die Angabe der E-Mail Adresse und des Passwortes für die korrekte Einrichtung der Software. Outlook oder Thunderbird können nun die richtigen Einstellungen von selbst ermitteln. Unterstützungen für weitere Programme wie Applemail folgen in Zukunft.

Benötigt ihr Hilfe beim einrichten? Meldet euch beim Support.

DKIM

Wir unterstützen auch DKIM für eure E-mails / Domains! Wenn ihr DKIM aktivieren möchtet so müssen wir die DNS Konfiguration eurer Domains überprüfen, öffnet hierfür in jedem Fall ein Support Ticket!

Zusatzinformationen

Plesk: Access your Mailbox

WordPress Caching ohne Plugin

WordPress Caching ohne Plugin

Wir haben lange überlegt ob wir unsere WordPress Optimierungsmethode veröffentlichen oder nicht. Wir werden es nicht tun. Aber das darf unsere Kunden nicht stören, ihr kommt in jedem Fall in den Genuss echter Performance mit WordPress.

Auslöser war eine Diskussion in einem Internet Forum zum Thema WordPress Optimierung. Seit Jahren sehen es immer noch viele Anwender als äußerst wichtig an ein Caching Plugin zu benutzen. Sicherlich die erste Wahl für viele Anwender um die Performance zu steigern. Doch es ist nicht mehr unbedingt die Beste. In den letzten Jahren haben wir mit nginx und nginx serverbasiertem Caching eine mächtige Hilfe bekommen. Und dies gilt es umzusetzen. Unsere Meinung das man mittlerweile ein echtes Caching Plugin für WP nicht mehr benötigt und sich diesen Overhead sparen kann wurde leider nicht gern geteilt. Praktisch wollten einige WordPress Gurus davon nichts wissen uns weiter verfahren wie bisher. Sollen sie. Die Experten sind sich längst einig das die Plattform viel wichtiger ist auf der WP läuft.

In den letzten Monaten haben wir viel erledigt und unsere Hosting Plattform auf Vordermann gebracht. Zu dem neuen Betriebssystem Debian 9 ist auch der SSD Boost hinzugekommen. Alle Webhosting Systeme sind neu konfiguriert. Somit unterstützen wir die wichtigsten Punkte für ein schnelles WordPress Hosting:

  • HTTP/2 Protokoll
  • GZIP Kompression
  • Browser Caching / Expires Caching
  • Serverbasiertes nginx Caching
  • php 7.3 FPM mit opcache

Wir haben bei unseren WordPress Instanzen nach den Testphasen die Caching Plugins komplett entfernt. Wir setzen auf die neuen Techniken die vor allem damit auskommen den Apache als Webserver in die ewigen Jagdgründe zu verfrachten und dafür auf nginx zu setzen. Dies wird belohnt! Für die restlichen Dinge die dann an WP noch zu optmieren sind: JavaScript, Minify, HTML Cleanup etc, gibt es einfachere Methoden, ohne die Last eines Caching Plugin mitzuschleppen.

Unsere Hosting Umgebung ist vorbereitet und steht unseren Kunden zur Verfügung. Da das ganze aber nicht ohne etwas Optimierung in WordPress auskommt reicht alleine die Hosting Plattform für den Speed Boost nicht aus. Einige kleine Dinge sind in WordPress notwendig. Vor allem das „Caching Plugin“ muss verschwinden. Um Code Optimierungen an HTML, JS, etc. zu machen gibt es andere Lösungen.
Wenn ihr Kunde bei uns seid und auch euere WordPress Seite schneller werden soll so wendet euch an unseren Support.

Warum ohne Caching Plugin

Webserver, im besonderen nginx, können mit Caching besser und vor allem schneller umgehen als php oder WordPress. Mit nginx Caching werden fertige Seiten im Cache des Webservers abgelegt und abgerufen wenn jemand die Seite benötigt. Ganz ohne den WordPress und php Overhead überhaupt anfassen zu müssen. Ein Caching Plugin in WP macht das zwar ähnlich, aber hier erfolgt das ausliefern der zwischengespeicherten Version viel später, hier muss noch nach der Cache Version als Datei etc. gesucht werden, geprüft werden ob diese noch gültig ist etc.
Wenn kein Cache Dokument existiert muss die Seite neu in WordPress generiert werden, so oder so. Ohne Caching Plugin wird auch hier der Caching Part in WP eingespart.

PageSpeed

Ja, es ist möglich mit dieser Variante eine Seite auf PageSpeed = A zu optimieren. Sogar äußerst einfach. Nach der Optimierung sind die meisten Seiten zumindes auf PageSpeed Grade B. Oft hindern dann nur noch zu große oder unoptimierte Bilder das A Rating. Oder Plugins die zu unbedacht mit Javascript oder anderen Komponenten umgehen haben einen Einfluss auf eine bessere Bewertung. Das ist aber dann meist auch lösbar. Am Ende aber wird die Seite merklich schneller funktionieren für den Besucher, und das ist worauf es ankommt.
Wir hätte, wie andere das auch machen, schnell mal eben eine WordPress Demo Seite aufsetzen können die mit PageSpeed A bewertet wird. Das halten wir aber für unsinnig, niemand stellt eine eigene Demo Seite ins Netz sondern will seine „echte“ Webseite präsentieren. Und bei Seiten mit echten Inhalten ist es eben oft schwerer eine Optimierung zu A zu machen als mit Demo Seiten.
Trotzdem, hier findet ihr ein Beispiel für eine optimierte Seite nach oben beschriebener Methode: https://powie.de

Neues Service Portal

Neues Service Portal

Wir haben unser Service Portal erneuert. Im besonderen ist die Kunden Informations Plattform jetzt auch Responsive und für Smartphones optimiert.
Da wir elektronische Rechnungen als PDF versenden sind wir verpflichtet auch ältere Rechnungen zum Download bereitzustellen, diese können sie im Servicebereich herunterladen. Zudem finden sie hier alle Informationen zu Speicherplätzen und Domains.

Login: https://service.be-webspace.de

 

WordPress auf nginx

WordPress auf nginx

Eine häufige Anfrage an unseren Support: Wie kann ich mit meiner WordPress Installation Apache deaktivieren und den Betrieb über nginx alleine bewerkstelligen. Der Vorteil ist oft die bessere Performance mit php-fpm und dem nginx Caching etc.
Ihr solltet aber wissen: Teilweise können vor allem Caching Plugins wie SP Super Cache nicht mit nginx funktionieren. Bei der Umkonfiguration landet eure Seite ggf. auf einem HTTP 500 Fehler. Wer sich bzgl. seiner Plugins also unsicher ist aktiviert vor Umstellung den WP Debug Modus.
Die Anleitung ist passend für Kunden mit be-webspace Webhosting Paketen mit Plesk und der WordPress Toolbox.

WP Debug Mode aktivieren

Das geht ganz einfach mit einer Zeile in der wp-config.php:

define( 'WP_DEBUG', true );

In unserer WordPress Toolbox könnt ihr das Debugging ganz simpel aktivieren über den Schalter in der Konfiguration der WordPress Instanz:

wp-debug

PHP FPM aktivieren

Geht auf die Konfiguration eurer Domain und wählt den Punkt PHP-Einstellungen aus.

1.  Umstellen auf php-fpm mit nginx. Wählt php 7.x. aus und stellt zum ausführen ein: FPM-Anwendung von nginx bedient.

php-fpm mit nginx

Apache deaktivieren

Geht zu euer Domain uns wählt den Punkt Einstellungen für Apache & nginx. Hier deaktivieren wir den Proxy Modus!. Das schaltet den Indianer aus.

plesk-proxy-nginx-off

Permalink Support

In der Regel benutzt ihr Permalinks auf eurer WP Installation, da .htaccess bei nginx nicht funktioniert müssen wir die Permalinks für nginx konfigurieren. Dies geht auf der Seite der Apache & nginx Einstellungen am Ende unter dem Punkt Zusätzliche nginx Anweisungen. Hier fügt ihr den folgenden Code ein:

# !!! WordPress Permalinks
if (!-e $request_filename) {
rewrite ^(.*)$ /index.php?q=$1 last;
}

Ergebnis:

plesk nginx wordpress permalinks

Nun sollte eure WP Seite rein über nginx gehostet sein. Ihr könnt das unter anderem unter dem Prunkt Protokolle sehen. Sollten Probleme auftreten oder die Seite Fehler produzieren so müsst ihr euch mit dem Debugging beschäftigen und in der Regel das inkompatible Plugin herausfinden.

Finale

Wenn alles funktioniert vergesst nicht den Debug Modus wieder zu deaktivieren!

define( 'WP_DEBUG', false );

IPv6 und DNS Einstellungen

IPv6 und DNS Einstellungen

Wir führen im Dezember und Januar auch für Kunden die schon länger auf unseren Systemen ihre Domains beheimatet haben einige technische Änderungen durch. Dies gilt es zu beachten:

DNS Einstellungen

Es erfolgt ein Wechsel des Nameservers der Domains. DNS Konfigurationen lassen sich ab diesem Zeitpunkt im Plesk Controlpanel unter dem Punkt DNS Einstellungen selbst vornehmen.

Mit dem Wechsel des Nameserver existieren für den Mailserver der Domain nur noch der Hostname mail.domain.tld. Wer smtp. oder pop3. benutzt wird über diesen Name keinen Zugang zu seinen Mailservern mehr haben. Es gilt das ggf. in der Software oder App umzustellen.
Wir empfehlen aber generell für Mail Dienste den globalen Hostname des Plesk Systems zu benutzen, zum Bsp.: brutus.be-webspace.net, da für diesen Hostname das SSL Zertifikat korrekt eingerichtet ist und so ohne Zertifikatswarnungen auch der Mailverkehr gesichert erfolgen kann.

IPv6

Auf allen Domains die bisher noch nicht mit IPv6 Adressen ausgestattet waren sind ab dem Zeitpunkt der Umstellung auch komplett IPv6 Adressen eingerichtet.

php 5

php Versionen kleiner 5.6 werden von den Servern entfernt, minimal steht php 5.6.x zur Verfügung. Die erfolgt ohne Rücksicht auf die Kompatibilität alter php Anwendungen auf php 5.6 da wir keine Informationen haben über ihre verwendete Software.