Thomas Fankhauser wrote:
smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname, reject_invalid_hostname, permit smtpd_recipient_restrictions = reject_unauth_pipelining, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_rbl_client zombie.dnsbl.sorbs.net, reject_rbl_client list.dsbl.org, reject_rbl_client zen.spamhaus.org, reject_rbl_client dialup.blacklist.jippg.org, reject_unverified_recipient
Die Checks reject_non_fqdn_hostname und reject_invalid_hostname tauchen auch in smtpd_recipient_restrictions auf, deshalb ist es nicht nötig, sie doppelt zu prüfen.
Ich blick nur nicht ganz durch, warum es die smtpd_*_restirctions gibt, wenn alles in einer einzelnen sein kann.
Da muss ich jetzt etwas weiter ausholen für. Ich glaube, ich hatte schon erwähnt, dass Postfix bei normaler Einstellung erst nach dem ersten rcpt to Befehl eine Rückmeldung an den Client gibt. Verantwortlich dafür ist: # postconf -d smtpd_delay_reject smtpd_delay_reject = yes Der Client hat somit schon die gesamten Envelope-Informationen übergeben und Postfix kann diese Daten loggen und anhand dieser Daten entscheiden, ob die Mail angenommen werden soll. Das ist deshalb Default, weil es Teil einer robusten Mailstruktur ist und für Analysen das Log aussagekräftig sein sollte. Da die Mailflut jedoch enorme Ausmaße angenommen hat, möchten stark belastete Mailserver die Verbindung so früh wie möglich abbrechen, sobald sie wissen, dass sie keine Mails von diesem Client annehmen möchten. Wenn du zum Beispiel versuchst, eine Mail direkt von einer dynamischen IP an GMX zu senden, dann wirst du feststellen, dass der Connect nicht bis zum Austausch des Envelopes anhält, sondern allein aufgrund deiner IP-Adresse die Verbindung abgebrochen wird. Bei Postfix würde dies verwirklicht mit folgender Konfiguration: main.cf: smtpd_delay_reject = no smdpd_client_restrictions = permit_mynetworks, check_client_access cbl:/etc/postfix/internal_blacklist, reject_rbl_client zen.spamhaus.org Damit wird direkt die Verbindung abgebrochen, wenn anhand der Client-IP ohnehin keine Mails entgegengenommen werden. Dies macht jedoch nur Sinn für einen stark belasteten Server.
smtpd_sasl_auth_enable = no
Da bei dir smtp auth nicht aktiv ist, könntest du auch permit_sasl_authenticated herausnehmen.
Dies hatte ich drinn, weil ich verstanden habe dass mindestens eine Regel mit 'permit' drinn sein muss. Somit habe ich eine drinn, greifen kann sie aber nie. Als dann permit_mynetworks noch reinkam, hab ichs einfach drinngelassen (greift ja eh nie;-)
Im Gegenteil. Niemand hat verlangt, dass eine Regel mit "permit" verwendet wird. für smtpd_recipient_restrictions reicht es, wenn dort ein "reject/reject_unauch_destination" steht. Der wichtige Punkt ist, dass du nicht zu einem offenen Relay wirst. Ob du auch wirklich die erwünschte Mail bekommst, ist nicht so kritisch. (^-^)
Unknown ist ja wirklich nicht ernstzunehmen, oder?
Unknown bedeutet, dass es keinen reverse DNS Eintrag gibt oder dieser nicht übereinstimmt mit dem DNS-Eintrag.
Aber sorry, wenn es nicht mal einen reverse DNS Eintrag gibt, dann ist doch wohl schon etwas faul. Jeder hinterletzte DialUp Account besitzt einen entsprechenden ptr Eintrag.
Nun, es gibt einige Provider (nicht unbedingt deutsche), die dafür berühmt waren, keine reverse DNS zu vergeben und behaupteten, dass diese auch nicht nötig wären. Viele chinesische Server haben damit zu kämpfen, aber auch die British Telecom war bekannt dafür, und Carlos von der englischen opensuse hatte berichtet, dass es nicht einfach ist, in Spanien eine saubere DNS-Konfiguration zu erhalten.
Leider habe ich genügend Clients, die normale Mails einliefern, aber keinen korrekten reverse DNS-Eintrag. Deshalb kann ich nicht darauf prüfen.
Das sind aber Clients, nicht Server. Die Clients müssten sich in meinem Fall per SMTP-AUTH anmelden. Ist aber momentan noch nicht nötig, da diese direkt auf den Zielserver verbinden. Die Umstellung ist geplant, ich weiss nur noch nicht wann dieser Postfix soweit ist.
Wortklauberei. Client ist in diesem Fall nur der Host, der gerade einliefert. Postfix hat einen smtpd Serverdaemon und einen smtp Clientdaemon. Auch die Parameter sind sauber mit smtpd_* und smtp_* für Server und Client getrennt.
Wenn der Name den der Server im EHLO angibt, nicht mit dem ptr der ip übereinstimmt, würde ich mir aber dennoch überlegen, den Empfang abzulehnen. Meines erachtens ist in dem Fall der Server bzw. DNS nicht fertig installiert. Mit entsprechender Fehlermeldung sollte eigentlich der Kunde letztendlich fähig sein, zu seinem Provider zu gehen und ihm diese Fehlermeldung aufzeigen. Meisst sind es die grossen Provider in Frankreich, die ihre Mailserver anders taufen als der DNS angibt.
Auch Yahoo, Google, Hotmail und 1und1 sind schon unangenehm aufgefallen. Ich habe aber auch sehr viele Server, die sich schlicht mit internen Hostnamen melden, welche extern gar nicht aufgelöst werden können. Wenn du nur eine kleine Site verwaltest mit ein paar hundert oder tausend Mails pro Tag, dann kannst du es dir vielleicht noch leisten, die Postmaster anzuschreiben (wenn diese Adresse nicht direkt nach /dev/null geleitet wird). Wenn du jeden Tag hunderte oder tausende von solchen Servern hast, dann kannst du das rein zeitlich nicht mehr. Nebenbei werden dir die zahlenden Kunden/Anwender innerhalb der Firma im Nacken sitzen, die diese Mails haben wollen. Deshalb findet man dafür andere Methoden, Spam abzulehnen. Greylisting ist ein hervorragendes Mittel, Spamzombies abzuweisen. Von solchen Spamzombies aus dynamischen IP-Bereichen kommt der Großteil des Spams. Inzwischen habe ich diese Spams bis auf einen verschwindend geringen Teil im Griff, jetzt kommt ein guter Teil des durchkommenden Spams von echten Servern, die nicht ganz korrekt eingerichtet sind (Backscatter, keine korrekte Authentifikation etc) oder auch von ausgenutzten Webmailern wie Hotmail, Yahoo und Google. Hier die Liste der letzten Rechner, die bei uns Spam eingeliefert haben. Dabei kann es sein, dass der Reverse-DNS nicht existiert. Mein Script hat das nicht mehr geprüft: IP Reverse DNS 200.121.182.185 client-200.121.182.185.speedy.net.pe 213.4.149.12 mailhost.terra.es 61.136.62.74 unknown 216.20.10.4 mailserv.mecnet.net 85.128.59.110 host-ip110-59.crowley.pl 207.115.20.70 flpi101.sbcis.sbc.com 207.115.36.44 nlpi015.sbcis.sbc.com 213.141.25.61 smtp1.artelecom.pt 83.110.21.200 auh-b13756.alshamil.net.ae 12.19.116.73 unknown 65.54.246.97 bay0-omc1-s25.bay0.hotmail.com 212.47.13.186 paegas.mail-atlas.net 65.54.246.218 bay0-omc3-s18.bay0.hotmail.com 62.193.249.37 wpc4343.amenworld.com 86.63.74.38 student.pwsz.pila.pl 213.191.85.38 mail.daybyday.de. 69.94.32.67 anoopam.anoopam-mission.org 69.94.66.57 server.decktherails.com 167.206.4.197 mta2.srv.hcvlny.cv.net 207.159.120.61 nn7.excitenetwork.com 24.235.238.7 d235-238-7.home1.cgocable.net 193.164.133.199 rbi0045.giga-dns.com 124.147.37.246 web3102.mail.kcd.yahoo.co.jp 216.40.35.67 fr3.webmaillogin.com 212.47.13.186 paegas.mail-atlas.net 202.8.85.179 fuji.hamthai.com 217.146.182.133 web28113.mail.ukl.yahoo.com 202.83.112.198 mail-hub.becom.com.au 81.15.224.238 lebork-exatel-2.leb.vectranet.pl 203.216.249.197 web2912.mail.tnz.yahoo.co.jp 85.214.29.180 globalhostingservice.de 65.54.246.165 bay0-omc2-s29.bay0.hotmail.com 65.54.246.224 bay0-omc3-s24.bay0.hotmail.com 58.88.60.19 p1019-ipbf13imazuka.yamagata.ocn.ne.jp Da ist nicht mehr viel dynamisches dabei. Das einzige, was dagegen jetzt helfen würde, ist ein Pre-Queue-Filter, der erst schaut, ob es Spam ist und erst danach über die Annahme der Mail entscheidet. Das ist aber erheblich weniger robust als ein After-Queue-Filter wie Amavis. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org