Hallo Zusammen, ich betreibe einen Mailserver auf SuSE 8.2 Basis mit den Paketen: sendmail-8.12.7-77 amavisd-sendmail-20020531-195 spamassassin-2.64-5 antivir-2.0.6-18 Leider kommt immer noch wahnsinnig viel Spam an, obwohl ich täglich 100-300 Mails an spamassasin verfüttere. sa-learn --spam --mbox /var/spool/mail/spamlearn Was mache ich falsch, warum kommt noch so viel Schrott an? Wie kann ich das ändern? Außerdem hat mich mein Provider angehauen weil ich permanent einen ipwhois.rfc-ignorant.org abfrage der wohl schon seit langen außer Betrieb ist, aber auch hier weiß ich nicht wo ich das einstellen kann. Danke Daniel
Daniel Bauer wrote:
ich betreibe einen Mailserver auf SuSE 8.2 Basis mit den Paketen: sendmail-8.12.7-77 amavisd-sendmail-20020531-195 spamassassin-2.64-5 antivir-2.0.6-18
Nicht mehr ganz das neueste, aber es sollte trotzdem möglich sein, Spam auf ein erträgliches Maß herunterzubekommen. Dafür musst du natürlich erst feststellen, was für Spam durchkommt und warum die Einstellungen nicht greifen. Leider schreibst du nichts dazu, welche Servereinstellungen du gesetzt hast, um unerwünschte Mails abzulehnen. Wichtig ist, dass der Server, bevor er die Mails an Amavis übergibt, einen möglichst großen Teil der Spams direkt per reject ablehnt. - ablehnen aller Mails an ungültige Adressen, local wie relay - HELO-Checks auf offenkundige Viren/Spams wie helo auf IP von Empfangsserver - abfragen von sinnvollen Blacklists vor Annahme der Mails
Leider kommt immer noch wahnsinnig viel Spam an, obwohl ich täglich 100-300 Mails an spamassasin verfüttere.
sa-learn --spam --mbox /var/spool/mail/spamlearn
Was mache ich falsch, warum kommt noch so viel Schrott an? Wie kann ich das ändern?
Der Bayes-Filter allein lehnt nie eine Mail ab. BAYES99 hat IMHO 3,49 Punkte. In /etc/amavisd.conf können viele Einstellungen getroffen werden. Lese dir mal dazu die Doku durch.
Außerdem hat mich mein Provider angehauen weil ich permanent einen ipwhois.rfc-ignorant.org abfrage der wohl schon seit langen außer Betrieb ist, aber auch hier weiß ich nicht wo ich das einstellen kann.
Entweder dein Sendmail fragt den Server ab, oder Amavis. Ich habe leider weder Sendmail noch so ein altes Amavis laufen, deshalb kann ich die Frage nicht präzise beantworten. Prüfe erst einmal, ob Sendmail in seiner Konfiguration Blacklists abfragt. Notfalls einfach mal ein "grep -ri 'ipwhois.rfc-ignorant.org' /etc" laufen lassen, um zu sehen, wo der Begriff überhaupt auftaucht. Wichtigste Aufgabe ist erst einmal, festzustellen, welche Regeln von SA von Spams ausgelöst werden, welche nicht ausgelöst werden, und welchen Punktestand die nicht als Spam erkannten Mails erhalten haben. Diese Angaben solltest du im Header der Spams finden. Dort kannst du auch sehen, welche HELO-Checks sinnvoll sind. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply (@) japantest (.) homelinux (.) com
Hi Sandy, Sandy Drobic wrote on Friday, July 15, 2005 10:51 AM:
Daniel Bauer wrote:
ich betreibe einen Mailserver auf SuSE 8.2 Basis mit den Paketen: sendmail-8.12.7-77 amavisd-sendmail-20020531-195 spamassassin-2.64-5 antivir-2.0.6-18
Nicht mehr ganz das neueste, aber es sollte trotzdem möglich sein, Spam auf ein erträgliches Maß herunterzubekommen. Dafür musst du natürlich erst feststellen, was für Spam durchkommt und warum die Einstellungen nicht greifen. Leider schreibst du nichts dazu, welche Servereinstellungen du gesetzt hast, um unerwünschte Mails abzulehnen.
ich habe hierzu nichts gemacht außer das was SuSE standardmäßig bietet. sendmail habe ich manuell auf Authetifizierung umgestellt, dazu ist noch amavisd und spamd gestartet. Wenn Viren ankommen, werden sie gelöscht und bei Spam werden sie in eine separate Mailbox verschoben.
Wichtig ist, dass der Server, bevor er die Mails an Amavis übergibt, einen möglichst großen Teil der Spams direkt per reject ablehnt.
- ablehnen aller Mails an ungültige Adressen, local wie relay - HELO-Checks auf offenkundige Viren/Spams wie helo auf IP von Empfangsserver - abfragen von sinnvollen Blacklists vor Annahme der Mails
da bin ich leider etwas überfordert. Ich dachte das spamassassin das übernimmt.
Leider kommt immer noch wahnsinnig viel Spam an, obwohl ich täglich 100-300 Mails an spamassasin verfüttere.
sa-learn --spam --mbox /var/spool/mail/spamlearn
Was mache ich falsch, warum kommt noch so viel Schrott an? Wie kann ich das ändern?
Der Bayes-Filter allein lehnt nie eine Mail ab. BAYES99 hat IMHO 3,49
es ist nicht wichtig das er sie ablehnt, ein leises "löschen" / verschieben reicht mir schon.
Punkte. In /etc/amavisd.conf können viele Einstellungen getroffen werden. Lese dir mal dazu die Doku durch.
ich habe dazu nicht bzgl. spamassasin gefunden.
Außerdem hat mich mein Provider angehauen weil ich permanent einen ipwhois.rfc-ignorant.org abfrage der wohl schon seit langen außer Betrieb ist, aber auch hier weiß ich nicht wo ich das einstellen kann.
Entweder dein Sendmail fragt den Server ab, oder Amavis. Ich habe leider weder Sendmail noch so ein altes Amavis laufen, deshalb kann ich die Frage nicht präzise beantworten.
Prüfe erst einmal, ob Sendmail in seiner Konfiguration Blacklists abfragt. Notfalls einfach mal ein "grep -ri 'ipwhois.rfc-ignorant.org' /etc" laufen lassen, um zu sehen, wo der Begriff überhaupt auftaucht.
tja leider ohne Treffer, das hatte ich auch schonmal gesucht.
Wichtigste Aufgabe ist erst einmal, festzustellen, welche Regeln von SA von Spams ausgelöst werden, welche nicht ausgelöst werden, und welchen Punktestand die nicht als Spam erkannten Mails erhalten haben. Diese Angaben solltest du im Header der Spams finden.
X-Spam-Status: No, hits=3.3 required=5.0 tests=ALL_NATURAL,BAYES_00,CUM_SHOT, FROM_ENDS_IN_NUMS,MONEY_BACK autolearn=no version=2.64
Dort kannst du auch sehen, welche HELO-Checks sinnvoll sind.
was ist das genau? Danke + Gruß Daniel
Daniel Bauer wrote:
Leider schreibst du nichts dazu, welche Servereinstellungen du gesetzt hast, um unerwünschte Mails abzulehnen.
ich habe hierzu nichts gemacht außer das was SuSE standardmäßig bietet. sendmail habe ich manuell auf Authetifizierung umgestellt, dazu ist noch amavisd und spamd gestartet. Wenn Viren ankommen, werden sie gelöscht und bei Spam werden sie in eine separate Mailbox verschoben.
Ah, dann lässt sich da ohne viel Aufwand einiges verbessern. (^-^)
Wichtig ist, dass der Server, bevor er die Mails an Amavis übergibt, einen möglichst großen Teil der Spams direkt per reject ablehnt.
- ablehnen aller Mails an ungültige Adressen, local wie relay - HELO-Checks auf offenkundige Viren/Spams wie helo auf IP von Empfangsserver - abfragen von sinnvollen Blacklists vor Annahme der Mails
da bin ich leider etwas überfordert. Ich dachte das spamassassin das übernimmt.
Das sind Tests, die noch vor SA laufen sollten. SA etwa kennt nicht die
gültigen Adressen, die kennt nur der Mailserver, zumindest sollte er sie
kennen. (^-^)
Dann werden Emails abgelehnt, die an ungültige Adressen geschickt werden.
Beispiel:
Jul 15 14:29:25 katgar postfix/smtpd[9611]: NOQUEUE: reject: RCPT from
test.example.com[10.4.1.16]: 550
Leider kommt immer noch wahnsinnig viel Spam an, obwohl ich täglich 100-300 Mails an spamassasin verfüttere.
sa-learn --spam --mbox /var/spool/mail/spamlearn
Was mache ich falsch, warum kommt noch so viel Schrott an? Wie kann ich das ändern?
Der Bayes-Filter allein lehnt nie eine Mail ab. BAYES99 hat IMHO 3,49
es ist nicht wichtig das er sie ablehnt, ein leises "löschen" / verschieben reicht mir schon.
Ich meine damit, dass nur der Bayesfilter allein nicht hoch genug bewertet wird, um eine Mail als Spam einzuordnen.
Punkte. In /etc/amavisd.conf können viele Einstellungen getroffen werden. Lese dir mal dazu die Doku durch.
ich habe dazu nicht bzgl. spamassasin gefunden.
$sa_local_tests_only = 0; Setze mal diese Einstellung, dann sollte SA auch die DNS-Blacklists abfragen für seine Bewertung.
Wichtigste Aufgabe ist erst einmal, festzustellen, welche Regeln von SA von Spams ausgelöst werden, welche nicht ausgelöst werden, und welchen Punktestand die nicht als Spam erkannten Mails erhalten haben. Diese Angaben solltest du im Header der Spams finden.
X-Spam-Status: No, hits=3.3 required=5.0 tests=ALL_NATURAL,BAYES_00,CUM_SHOT, FROM_ENDS_IN_NUMS,MONEY_BACK autolearn=no version=2.64
Kläglich, vor allem keine DNS-Abfragen drin. Siehe die SA-Einstellung oben So sieht eine erfolgreiche Abfrage aus: X-Spam-Status: Yes, hits=29.404 tagged_above=-20 required=5.5 tests=ALL_NATURAL, BAYES_99, DATE_IN_PAST_12_24, GAPPY_SUBJECT, HDR_ORDER_TRIMRS, HELO_DYNAMIC_IPADDR, IMPOTENCE, RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL, URIBL_AB_SURBL, URIBL_JP_SURBL, URIBL_OB_SURBL, URIBL_SBL, URIBL_SC_SURBL, URIBL_WS_SURBL X-Spam-Level: ***************************** X-Spam-Flag: YES Achte mal auf die Einträge mit BL.
Dort kannst du auch sehen, welche HELO-Checks sinnvoll sind.
was ist das genau?
Ein anderes Posting, die Arbeit ruft. (^-^) Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply (@) japantest (.) homelinux (.) com
Sandy Drobic wrote on Friday, July 15, 2005 2:56 PM:
Blacklists sind Listen von Rechnern, die Als Spamschleudern bekannt sind.
ist mir klar, aber ich dachte das die durch spamassassin gehandelt werden, sonst muß ich ja jedesmal die sendmail Config ändern und woher weiß ich welche Listen ich abfragen soll?
HELO-Checks sind Tests, die während des Verbindungsaufbaus prüfen, ob der Name, mit dem der sendende Rechner sich meldet, akzeptabel ist. Viele Spammer und Viren etwa melden sich mit der IP-Adresse des Servers, den sie gerade kontaktieren, nicht etwa ihrer eigenen.
verstanden, werde ich versuchen in sendmail zu implementieren.
Punkte. In /etc/amavisd.conf können viele Einstellungen getroffen werden. Lese dir mal dazu die Doku durch.
ich habe dazu nicht bzgl. spamassasin gefunden.
$sa_local_tests_only = 0;
Setze mal diese Einstellung, dann sollte SA auch die DNS-Blacklists abfragen für seine Bewertung.
habe ich jetzt gemacht, konnte aber dann gar keine Mail mehr versenden, aber woher hast Du diese Info, wo kann ich sowas nachlesen?
X-Spam-Status: No, hits=3.3 required=5.0 tests=ALL_NATURAL,BAYES_00,CUM_SHOT, FROM_ENDS_IN_NUMS,MONEY_BACK autolearn=no version=2.64
Kläglich, vor allem keine DNS-Abfragen drin. Siehe die SA-Einstellung oben So sieht eine erfolgreiche Abfrage aus:
X-Spam-Status: Yes, hits=29.404 tagged_above=-20 required=5.5 tests=ALL_NATURAL, BAYES_99, DATE_IN_PAST_12_24, GAPPY_SUBJECT, HDR_ORDER_TRIMRS, HELO_DYNAMIC_IPADDR, IMPOTENCE, RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL, URIBL_AB_SURBL, URIBL_JP_SURBL, URIBL_OB_SURBL, URIBL_SBL, URIBL_SC_SURBL, URIBL_WS_SURBL X-Spam-Level: ***************************** X-Spam-Flag: YES
Achte mal auf die Einträge mit BL.
Ich dachte das sind Blacklist Abfragen, hier das Log eines erfolgreich erkannten Spams: Content analysis details: (5.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.1 HTML_MESSAGE BODY: HTML included in message 0.3 MIME_HTML_ONLY BODY: Message only has text/html MIME parts -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 1.5 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see http://www.spamcop.net/bl.shtml?147.10.110.48] 4.9 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL [147.10.110.48 listed in sbl-xbl.spamhaus.org] 1.7 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP [147.10.110.48 listed in combined.njabl.org] 1.6 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't
Dort kannst du auch sehen, welche HELO-Checks sinnvoll sind.
was ist das genau?
Ein anderes Posting, die Arbeit ruft. (^-^)
sorry und danke für die Hilfe Daniel
Daniel Bauer wrote:
Blacklists sind Listen von Rechnern, die Als Spamschleudern bekannt sind.
ist mir klar, aber ich dachte das die durch spamassassin gehandelt werden, sonst muß ich ja jedesmal die sendmail Config ändern und woher weiß ich welche Listen ich abfragen soll?
Gute Frage, das richtet sich viel nach den einzelnen Bedürfnissen. Da hilft nur, nachsehen, welche Listen mit den eigenen Wünschen übereinstimmen. Beispiele: relays.ordb.org: enthält nur überprüfte Open Relays list.dsbl.org: enthält nur überprüfte Open Relays sbl-xbl.spamhaus.org: sbl: IP-Netze von Spammern xbl: IP-Adressen von Spamzombies bl.spamcop.net: riskanter, nimmt Reports von Spam entgegen und setzt entsprechende Einträge
HELO-Checks sind Tests, die während des Verbindungsaufbaus prüfen, ob der Name, mit dem der sendende Rechner sich meldet, akzeptabel ist. Viele Spammer und Viren etwa melden sich mit der IP-Adresse des Servers, den sie gerade kontaktieren, nicht etwa ihrer eigenen.
verstanden, werde ich versuchen in sendmail zu implementieren.
Bei mir werden etwa 20-30% der eingehenden Spams direkt vom HELO-Check abgewehrt, da sie entweder mit ungültigen HELO anmelden wie ss oder localhost(kein FQDN), IP-Adresse meines Servers verwenden oder sich als meine Domain anmelden. Wichtig ist nur, dass diese Prüfung in der richtigen Reihenfolge stattfindet, sonst sperrt man sich plötzlich selbst aus. (^-^)
Punkte. In /etc/amavisd.conf können viele Einstellungen getroffen werden. Lese dir mal dazu die Doku durch.
ich habe dazu nicht bzgl. spamassasin gefunden.
Suche mal unter amavis: /usr/share/doc/packages/amavisd-new/README_FILES
X-Spam-Status: Yes, hits=29.404 tagged_above=-20 required=5.5 tests=ALL_NATURAL, BAYES_99, DATE_IN_PAST_12_24, GAPPY_SUBJECT, HDR_ORDER_TRIMRS, HELO_DYNAMIC_IPADDR, IMPOTENCE, RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL, URIBL_AB_SURBL, URIBL_JP_SURBL, URIBL_OB_SURBL, URIBL_SBL, URIBL_SC_SURBL, URIBL_WS_SURBL X-Spam-Level: ***************************** X-Spam-Flag: YES
Achte mal auf die Einträge mit BL.
Ich dachte das sind Blacklist Abfragen, hier das Log eines erfolgreich erkannten Spams:
Wenn man über Amavis erlaubt, dass Spamassassin ins Internet gehen kann, dann fragt SA in der Tat die DNS-Blacklists ab. Dort kannst du auch sehen, dass Spamcop nicht so hoch eingeht wie etwa die spamhaus.org
Dort kannst du auch sehen, welche HELO-Checks sinnvoll sind.
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. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply (@) japantest (.) homelinux (.) com
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
Daniel Bauer wrote:
Die Mailkommunikation läuft in verschiedenen Stadien ab. In jedem Stadium können eigene Tests ablaufen, um den weiteren Kontakt zu erlauben oder abzubrechen.
[Schnipp]
hast Du dazu evtl. ein Howtos, od. Quellen wo ich das nachlesen kann?
Was ich geschrieben habe ist nur eine grobe Zusammenfassung, die jedoch zum Grundwissen jedes Mailadministrators gehören sollte. Der Standard, nach dem sich eine Mailinplementation richten sollte, sind die RFCs 821,822 bzw. die neueren RFCs 2821,2822, welche die alten RFCs 821,822 ersetzen. Diese sind eigentlich recht verständlich, wenn auch etwas trocken geschrieben. Insbesondere die alten RFCs 821,822 kommen noch aus einer Zeit, da man an das Gute im Menschen und den Rechnern im Internet geglaubt hat. Anders kann man sich Source-Routing und Open-Relays nicht erklären. (^-^) Grundsätzlich findet alles im ASCII-Bereich statt, du kannst also die gesamte Mailkommunikation auch per Telnet manuell mit dem Server durchspielen. (^-^) Zum Lernen und Prüfen würde ich das sogar empfehlen. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply (@) japantest (.) homelinux (.) com
participants (2)
-
Daniel Bauer
-
Sandy Drobic