Wie lange dauert es, bis eine E-Mail zugestellt wird?
Diese Frage kann eigentlich nur jemand stellen,
der bisher ausschließlich Erfahrungen mit einem Massenprovider
à la T-Online, AOL oder Compuserve gesammelt hat.
Dort passiert es immer wieder,
daß E-Mails 2 Stunden oder länger unterwegs sind,
bis sie dem Empfänger endlich zugestellt werden.
Der Grund liegt in den dort stets überlasteten Mailservern,
wobei jede ankommende Mail zwar sofort entgegengenommen und bestätigt wird,
dann aber gnadenlos in die Warteschlange zur Zustellung eingereiht wird.
Für kurze E-Mails gilt bei uns -
wie übrigens bei allen anderen normalen Providern auch -
eine typische Übertragungszeit von unter 10 Sekunden.
In seltenen Fällen kann es z.B. wegen eines Mailserver-Timeouts
auch mal eine Minute dauern...
Wenn Sie allerdings ein 100 MByte großes Attachment mitschicken,
dann müssen Sie auch bei uns etwa zehn Minuten Laufzeit einkalkulieren.
Da die Kodierung bei Mail-Attachments sehr ineffizient ist,
bleibt auch eine 2 Mbps-Anbindung
noch deutlich als Nadelöhr wahrnehmbar...
Nach oben
Wie funktioniert das mit dem Mailserver? -
Kann ich den auch selbst betreiben?
Selbstverständlich können Sie das.
Allerdings bitten wir zu beachten, daß wir es nicht dulden werden,
wenn Ihr Mailserver von Ihnen selbst oder von anderen als Spam-Relay
mißbraucht wird.
Es könnte sonst passieren,
daß wir bzw. unsere IP-Nummern auf einer Blacklist erscheinen,
und damit die von unserem IP-Nummernkreis ausgehenden E-Mails
von vielen Mailservern des Internets nicht mehr angenommen werden.
Dies trifft uns, Sie, und natürlich auch alle unsere anderen Kunden.
Schwachstelle SMTP -
SMTP (Simple Mail Transfer Protocol) hat seine Wurzeln in Multi-User-Umgebungen,
in denen sich Benutzer per Namen und Paßwort identifizieren mußten,
bevor sie E-Mail-Dienste verwenden konnten.
SMPT selbst kennt keine Client-Authentifizierung,
da es nur für den Mail-Verkehr zwischen Servern verantwortlich ist.
Eine detaillierte Beschreibung des Protokolls finden Sie im Dokument
RFC821.
Sendmail richtig konfigurieren -
Sendmail ist bis zum heutigen Zeitpunkt der populärste MTA
(Message Transport Agent)
und die Schwachstelle vieler falsch konfigurierter SMTP-Server,
die Spammern als Relay dienen.
Ergo ist die grundsätzliche Maßnahme gegen Spam,
genau zu kontrollieren, wer Ihren MTA als Relay verwenden darf.
Leider sind ältere Versionen von Sendmail (8.8.x)
als offene Relais vorkonfiguriert und müssen mit den
check_* Rulesets
gegen unauthorisiertes Relaying geschützt werden.
Definieren Sie sorgfältig alle lokalen Hosts,
denen Relaying erlaubt sein soll und stellen Sie außerdem
eine Empfängerliste aller Hosts zusammen,
für die Ihr MTA die Mail-Auslieferung übernimmt.
Alle Mails eines fremden Hosts, die an eine Adresse gehen,
die nicht als möglicher Empfänger definiert ist,
sollten abgewiesen werden.
Eine Implementierung des oben genannten Konzepts beschreibt ein
Dokument der Uni-Würzburg.
Umfassende Anti-Spam Maßnahmen für Sendmail 8.8.x
finden Sie auch auf der
Anti-Spam-Seite von Claus Assmann.
Besseren Schutz gegen UBE (Unsolicited Bulk E-Mail) bieten
aktuellere Sendmails ab 8.9.3 (verfügbar auf dem deutschen
Sendmail-Mirror),
auf das Sie unbedingt upgraden sollten.
Die Voreinstellung als offenes Relay ist nicht mehr vorhanden
und Maßnahmen gegen
Spam wurden den neuen Standard-Regelsets hinzugefügt.
Die neuen Regelsets bieten verbesserte Sender-Verifikation
über den Mail from: Parameter
und die Möglichkeit,
Zeilen des Mail-Headers ebenfalls per Regelsets zu überprüfen.
Eine allgemeine Zugangsliste kann in der neuen Version
einfach über FEATURE(access_db) aktiviert werden.
Eine genaue Dokumentation der neuen Funktionen
von Sendmail 8.9.x bis 8.12.7 bietet
sendmail.org.
Hervorragende allgemeine Übersichten zu Anti-Spam Maßnahmen
gibt es beim
IMC und in den
FAQs
von de.admin.net-abuse.mail.
Nach oben
Wie konfiguriere ich meinen Mailserver für Roaming?
Erst POP / IMAP - dann SMTP -
SMPT-Server, die nicht mehr relayfähig sind,
lassen sich leider auch nicht mehr für legitimes Roaming nutzen.
User, die eine Verbindung zu ihrem Mail-Server über andere ISPs herstellen,
können ihre Mails mit POP3 oder IMAP abrufen und lesen.
Sobald sie aber Post an Empfänger außerhalb des lokalen Hosts
schicken möchten, stellt sich der SMTP-Server taub.
Die Lösung für dieses Problem bietet
»POP-before-SMTP«.
Sendmail erkennt lediglich den Host-Namen und die IP-Nummer des Clients
und kann rechmäßige User nicht von Spammern unterscheiden.
Der POP-Server kann das sehr wohl und kennt ebenfalls die IP des Clients.
Diese Information läßt sich mit einem Daemon
aus den Logdateien des POP-Servers sammeln
und zu einer temporären Zugangsliste für Sendmail kompilieren.
Sobald sich User über ihr POP-Password identifiziert haben,
wird ihre IP-Adresse als autorisierter Sender vom SMTP-Server erkannt
und ihre Mails akzeptiert.
Nach einem angemessenen Zeitraum werden die IP-Nummern
aus der Zugangsliste gelöscht
und der User muß erneut eine POP-Verbindung zum Host herstellen,
bevor er Mails verschicken kann.
Quelltexte und Dokumentation für die Implementierung von
»POP-before-SMTP«
in Sendmail gibt es bei
sendmail.org und
abuse.net.
Nach oben
Wie teste ich meinen Mailserver auf offenes Relaying?
Sie öffnen eine Shell auf Ihrem Mailserver
und geben dort ein:
telnet relay-test.mail-abuse.org
Es startet dann eine Sequenz von etwa 20 Tests,
die Sie live mitverfolgen können.
Abschliessend erscheint das Ergebnis:
System appeared to reject relay attempts
Nach oben
Wie nutze ich die Secondary Mailserver von muenchner-freiheit.net?
Was ist zu tun? - Falls
muenchner-freiheit.net die Primary DNS-Server
Ihrer Domains betreibt,
dann werden die MX-Records gleich mit eingerichtet.
Dann brauchen Sie überhaupt nichts zu tun - es funktioniert automatisch.
Falls Sie Ihre DNS-Server selbst betreiben,
dann tragen Sie bitte für jeden genutzten Secondary Mailserver
einen MX-Record in die Konfigurationen Ihrer Domains ein.
Die niedrigste Zahl gehört zu Ihrem
meist hausinternen Primary Mailserver,
die Priorität der Secondary Mailserver
sinkt mit steigendem Zahlenwert.
; *************************************
; MX Records
MX 10 mail.ihredomain.de.
MX 20 ms2.muenchner-freiheit.net.
MX 30 ms3.muenchner-freiheit.net.
Da unser ms3 nicht in unserem Münchner Netz steht,
sondern in Freiburg im Breisgau,
und ausserdem - als hochzuverlässiges, plattenloses System -
nur über wenige 100 MB Pufferspeicher verfügt,
sollte diesem Secondary die niedrigste Priorität zugewiesen werden.
Beim ms2 gibt es keine derartigen Restriktionen.
Wie funktioniert's? - Alle unsere Secondary Mailserver
fordern routinemäßig
beim Eintreffen einer E-Mail per DNS-Anfrage
sämtliche MX-Records der Ziel-Domain an.
Findet sich unser Secondary
unter den MX-Records der Zieldomain gelistet,
dann wird die E-Mail angenommen und quittiert.
Wenn möglich erfolgt die Zustellung unverzüglich,
ansonsten wird alle halbe Stunde ein neuer Zustellversuch gestartet.
Ist keine direkte Zustellung möglich, dann wird zumindest versucht,
liegengebliebene Mails
zum nächsthöheren Mailserver weiter zu reichen.
Falls innerhalb von 120 Stunden (=5 Tage)
keine Zustellung möglich war,
dann wird die E-Mail verworfen und der Absender benachrichtigt.
Findet sich unser Mailserver nicht
bei den MX-Records der Zieldomain
aufgelistet, dann verweigert er die Annahme mit
»reject=550 ... Relaying denied«
Nach oben
SpamVerdampfer und VirenEinfrierer -
wie kann ich diese Services als Stammkunde einrichten?
Das Prinzip ist schnell erklärt:
anstatt dass Ihre Mails direkt
auf Ihrem bisherigen Mailserver aufschlagen,
werden sie durch unsere Secondary Mailserver geschleust.
Dort installierte Spam- und Virenscanner
analysieren Ihre Mail in Sekundenschnelle,
bringen gegebenenfalls im Betreff
und an anderen Stellen Spam-Ratings an,
und schneiden virenverseuchte Attachments heraus.
Durch manipulierte MX-Records (oder auch durch Firewall-Maßnahmen)
wird Ihr bisheriger Mailserver vor der Öffentlichkeit versteckt,
so dass alle hereinkommenden Mails
zwangsweise zunächst auf einem unserer Secondaries aufschlagen.
Da aus den manipulierten öffentlichen MX-Records
der Weg zum eigentlichen Mailserver nicht mehr hervorgeht,
müssen auf unseren Secondaries private Mailrouten
zum bisherigen Primary gesetzt werden,
auf denen die zwischengepufferten Mails
dann endgültig durchgereicht und zugestellt werden.
Was ist zu tun? - Falls
muenchner-freiheit.net die Primary DNS- und Mailserver
Ihrer Domains betreibt,
dann werden wir Ihre Konfiguration entsprechend modifizieren.
Dann brauchen Sie überhaupt nichts zu tun -
es funktioniert automatisch, sobald Sie dieses Feature abonnieren.
Falls Sie Ihre DNS- und Mailserver selbst betreiben,
dann tragen Sie bitte für jeden unserer Secondary Mailserver
einen MX-Record in die Konfigurationen Ihrer Domains ein.
Die niedrigste Zahl gehört zu Ihrem
meist hausinternen Primary Mailserver,
die Priorität der Secondary Mailserver
sinkt mit steigendem Zahlenwert.
; *************************************
; MX Records
MX 10 mail.meinedomain.de.
MX 20 ms2.muenchner-freiheit.net.
MX 30 ms3.muenchner-freiheit.net.
Jetzt wird durch uns
auf unseren beiden Secondaries ms2 und ms3
Ihre Domain *meinedomain.de (nebst allen Subdomains)
für RELAY freigeschaltet,
und von jedem Server aus eine dedizierte, private Mailroute
zu Ihrem mail.meinedomain.de gesetzt.
Bitte testen Sie dies, indem Sie zwei E-Mails an sich selbst verschicken.
Sie schicken diese Testmails aber nicht wie sonst an
mich@meinedomain.de
sondern an die beiden folgenden, gerouteten Mailadressen:
mich%meinedomain.de@ms2.muenchner-freiheit.net
mich%meinedomain.de@ms3.muenchner-freiheit.net
Sehen Sie sich die Header der beiden ankommenden E-Mails genau an.
Hat alles korrekt funktioniert,
dann finden sich je einer unserer beiden Mailserver
in den ankommenden Headern.
Jetzt kommt der entscheidende Schritt:
Sie löschen im Nameserver den Eintrag,
der auf Ihren Primary zeigt, oder kommentieren ihn aus.
; *************************************
; MX Records
; MX 10 mail.ihredomain.de. <- Primary auskommentiert
MX 20 ms2.muenchner-freiheit.net.
MX 30 ms3.muenchner-freiheit.net.
Starten Sie nun Ihren Name-Server neu und testen Sie die MX-Records.
Schicken Sie nochmals selbst eine E-Mail, diesmal wieder wie gewohnt an
mich@meinedomain.de
Sehen Sie sich den Header der ankommenden E-Mails wiederum genau an.
Sofern alles korrekt funktioniert,
findet sich dort einer unserer beiden Mailserver.
Falls Sie dort keinen unserer Mailserver finden,
dann haben sich die geänderten MX-Records
möglicherweise noch nicht bis zu Ihrem Arbeitsplatzrechner durchgesetzt.
Oder Sie testen vom Primary Mailserver aus -
der weiss natürlich von alledem nichts
und stellt nach wie vor lokal zu.
Innerhalb der folgenden Stunden werden Sie beobachten,
dass nach und nach immer mehr Mails den Umweg über die Secondaries nehmen.
Nach 1-2 Tagen wird in den DNS-Puffern des Internets
auch die letzt Spur zur Hintertür Ihres Mailservers getilgt sein.
Übrigens: Sie können jederzeit,
z.B. zu Test- oder Vergleichszwecken,
die Hintertür einen Spalt aufmachen,
ohne dass Sie sich dazu mit uns abstimmen bräuchten.
Dazu annoncieren Sie einfach Ihren Primary MX-Record wieder öffentlich.
Hinweis:
Nach mehrmonatigem Betrieb konnten wir folgenden Effekt beobachten:
Computerviren fragen oft die MX-Records gar nicht mehr ab,
sondern schicken ihren Dreck direkt an mail.meinedomain.de.
Falls Ihr versteckter Mailserver also zufällig
mail.meinedomain.de heisst,
und Sie diesen Namen intern beibehalten wollen,
dann sollten Sie den Zugang von außen
über eine Firewall-Regel sperren.
Weshalb schlägt Spam meist beim Secondary-Mailserver auf?
Dies ist ein beliebter Spammer-Trick,
der ihm gleich mehrere "Vorteile" bietet:
trotz gefälschter Zieladresse wird eine
erfolgreiche Zustellung vorgetäuscht
der Spammer erspart sich lästige Mail-Bounces
Oft stehen Secondaries draussen beim Provider.
Aus Datenschutzgründen sind deren Logfiles
für den Sysop des Empfängers unerreichbar,
und können daher nicht für Ermittlungszwecke genutzt werden
Secondaries werden nicht lückenlos überwacht
und sind meist ungepflegt
Was passiert genau? -
Eine nicht existierende Zieladresse würde der Primary
noch während der geöffneten Verbindung abweisen.
Der Secondary dagegen sagt erst mal
»Message accepted for delivery«
und trennt dann die Verbindung zum Spammer.
Normalerweise gilt eine Mail damit
als ordnungsgemäß zugestellt.
Anschließend baut der Secondary eine Verbindung zum Primary auf,
um die Mail endgültig zuzustellen.
Die nicht existierende Zieladresse wird dort jedoch abgewiesen,
daher versucht der Secondary nun,
eine neue Verbindung zum Spammer aufzubauen,
um das Zustellproblem zu melden.
Wegen der vom Spammer gefälschten Absenderangabe
schlägt diese Meldung nun entweder bei einem unschuldigen Dritten auf,
oder wird ihrerseits wegen Nichtexistenz zurückgewiesen
(»double bounce«),
oder wird wegen einer eigens hierfür eingerichteten Sperre
vom Provider abgewiesen..
Mit diesem Trick entledigt sich der Spammer der lästigen Bounces.
Nach oben
Mit Spamfiltern: brauche ich dann eigentlich noch Secondary-Mailserver?
Nein - alle unsere im Internet verteilten Spam- und Virenfilter-Mailserver
sind vollwertige, untereinander redundante Secondaries,
die allesamt Ihrem Primary zuarbeiten.
Sollte Ihr Primary verübergehend nicht erreichbar sein,
dann werden für Sie eingehende E-Mails auf unseren Filterservern gepuffert,
um 5 Tage lang alle 15 Minuten einen Zustellversuch zu starten.
Nach oben
