From: "Sandy Drobic"
Die Mailkommunikation läuft in verschiedenen Stadien ab. In jedem Stadium können eigene Tests ablaufen, um den weiteren Kontakt zu erlauben oder abzubrechen.
Stadium 1: Ip-Adresse Ganz am Anfang kommt ein Kontakt-Versuch herein. Zu diesem Zeitpunkt kennt dein System nur die IP-Adresse des Clients, der versucht, eine Mail einzuliefern.
Checks an diesem Punkt können gemacht werden über die IP-Adresse und den Reverse-DNS-Namen der IP-Adresse. So lehnen etwa T-online und einige andere große Maildomains generell Ip-Adressen aus dynamisch vergebenen Bereichen ab. Ziemlich brutal, aber leider stammt ein Großteil des Spams von infizierten Privatrechnern.
Stadium 2: HELO-Checks Dann sollte der sendende Server sich vorstellen. Dazu dient der SMTP-Befehl helo (oder der neue erweiterte Befehl ehlo). Du kannst auch vorschreiben, dass HELO/EHLO obligatorisch ist. Relativ gefahrlos, da nur Spammer kein HELO senden. FQDN ist schon etwas kritischer, da auch einige legitime aber schlampig konfigurierte Server nicht den vollständigen Servernamen mit Domain nennen.
Hier laufen Checks ab, ob der Name, mit dem sich der Server vorstellt, in Ordnung ist, den RFCs folgt etc. So kann etwa per Reverse-DNS oder MX-Abfrage nachgesehen werden, ob der Server wirklich zur Domain hotmail.com, microsoft.com oder Yahoo oder eben der eigenen Domain gehört.
Stadium 3: SMTP-Envelope Hier sind die beiden Angaben "mail from: " und rcpt to: " für Absender und Empfänger zu finden. Die "mail from: " Angaben fallen auch noch in den HELO-Bereich. Viele Viren etwa werden von mir schon direkt abgewehrt, da versuchen, als Absender admin@mydomain zu setzen und ich dies von extern nicht zulasse. Sämtliche HELO-Angaben sind vom Sender frei gesetzt und können beliebig gefälscht werden!!
"rcpt to: " hier kommt zum ersten mal das eigene System ins Spiel, wo nachgefragt werden kann, ob der Empfänger überhaupt existiert und ob zusätzliche Restriktionen gesetzt wurden. Z.B. verwende ich extra für die Emaillisten eine eigene Emailadresse und habe auf diese die Beschränkung gesetzt, dass nur der Suse-Listserver an diese Adresse Emails schicken darf. Das blockt sowohl Spammer und Viren, die diese Liste nach Emailadressen abgeklaubt haben als auch fehlkonfigurierte Server, die Bounces an die Schreiber der Liste zurückschicken. Zeitweise kamen Dutzende von Bounces herumgeschossen. Deshalb auch mein Footer.
Diese Angaben tauchen nicht im Mail-Header auf, das sind Felder, die im Datenteil gesetzt werden!! Wenn etwa als Empfänger in der Mail steht: "Undisclosed Recipients", dann wurde im Datenteil kein Empfänger angegeben.
Stadium 4: SMTP-DATA Der SMTP-Befehl DATA leitet den Empfang der Daten ein. Hier kommt dann der komplette Mailheader mit den Received-Zeilen, Subject:, to:, from:, etc. Hier laufen Checks auf Headerzeilen wie gefälschte Received-Zeilen, Subjects etc.
Nach einer Leerzeile folgt dann der eigentliche Inhalt der Mail.
Auch die Größe der Mail oder bestimmte Anhänge können eine Ablehnung auslösen.
Erst wenn der Sender das Kommando EndofData schickt und der Emfpänger mit 250 Mail accepted antwortet, ist die Mail an den Empfänger übergeben. Von jetzt an ist es SEINE Mail und er ist verantwortlich.
Du siehst, es gibt sehr viele Möglichkeiten, Restriktionen und Tests zu setzen. Das richtet sich aber ganz nach den eigenen Gegebenheiten.
hast Du dazu evtl. ein Howtos, od. Quellen wo ich das nachlesen kann? Daniel