<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hallo Winfried,<div class=""><br class=""></div><div class="">da kommt jetzt ja ganz schön viel beisammen… und das ist auch alles nicht ganz einfach. Aber mal so zum wesentlichen…</div><div class=""><br class=""></div><div class="">Deine User solltest Du auf Port 587 (Submission) verschieben. Dort lässt Du nur sasl_authenticated zu und hast dann eigentlich Ruhe.</div><div class=""><br class=""></div><div class="">Auf Port 25 sollten nur noch andere Mailserver reinkommen und somit nur Mails an Deine Domain einliefern dürfen. Viele Spammer fliegen raus.</div><div class=""><br class=""></div><div class="">Je nach Postfix-Version würde ich postscreen empfehlen, welches RBL filtern und auch sonst den verbundenen Client prüfen kann. Google hilft weiter.</div><div class=""><br class=""></div><div class="">Bei den RBL-Listen gibt es vieles was sich kombinieren ließe. Ich habe inzwischen Postscreen mit diversen RBL-Listen und dahinter den Amavis mit ClamAV und Spamassassin. Für Deutschland haben sich manitu und <a href="http://inps.de" class="">inps.de</a> als gut herausgestellt. Postscreen kann aber Listen unterschiedlich bewerten und das kombinierte Ergebnis dann zur Entscheidung verwenden.</div><div class=""><br class=""></div><div class="">Für beide Clam und SA gibt’s auch Spam-Listen. Für SA gibts eine vom Heinlein-Support und von <a href="http://zmi.at" class="">zmi.at</a>. Da sind zB falsche Telekom- und Amazon-Rechnungen gelistet. Für Clam schau mal nach clamav-unofficial-sigs auf Github. Das Script aktualisiert autom. von einer ganzen Reihe an Portalen. Lässt sich ganz frei konfigurieren.</div><div class=""><br class=""></div><div class="">2-3 Emails pro Woche kommen da noch durch. Da bin ich noch am optimieren…</div><div class=""><br class=""></div><div class="">Achso… Spam ablehnen und nicht markieren. Auch hierzu hat Heinlein was veröffentlicht… <a href="https://www.heinlein-support.de/vortrag/spam-quarantaene-und-tagging-der-grosse-irrtum" class="">Mehr</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Philon</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">Am 01.05.2016 um 12:04 schrieb Winfried Ritsch <<a href="mailto:ritsch@algo.mur.at" class="">ritsch@algo.mur.at</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hallo,<br class=""><br class="">Habe Kolab-16 auf Centos7 aufgesetzt und versucht möglichst alle empfohlenen <br class="">Sicherheiststufen beizubehalten (da ich kein postfix spezialist bin und denke <br class="">Kolab hat gute vorgaben).<br class=""><br class="">Allerdings bekam ich die Meldung das ein user aus einen fremden Netz nicht <br class="">über meinen outgoing mail-server (relay) an eine externe email addresse senden <br class="">darf:<br class=""><br class=""> <a href="mailto:user@myhost.xx" class="">user@myhost.xx</a> -> <a href="mailto:somwhere@gmail.xx" class="">somwhere@gmail.xx</a> via mail,myhost.xx über TLS <br class="">authentifiziert.<br class=""><br class="">Da dieser seine privaten emails nicht über den Firma outgoing senden will, <br class="">habe ich meine policy verändert und erlaube dies indem ich zu<br class=""><br class=""> /etc/postfix/main.cf: <br class=""><br class=""> smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_pipelining, <br class="">reject_rbl_client <a href="http://zen.spamhaus.org" class="">zen.spamhaus.org</a>, reject_non_fqdn_recipient, <br class="">reject_invalid_helo_hostname, reject_unknown_recipient_domain, <br class="">reject_unauth_destination, check_policy_service <br class="">unix:private/recipient_policy_incoming, permi<br class=""><br class=""> permit_sasl_authenticated hinzugefügt habe.<br class=""><br class="">Begründung: wenn sich jemand authentifizieren kann lass ich ihn auch senden, da <br class="">ich alle meine User kenne.<br class=""><br class="">Nun konnte ein User trotzdem nicht senden, da reject_rbl_client <br class=""><a href="http://zen.spamhaus.org" class="">zen.spamhaus.org</a> ein reject lieferte, da sein Provider in der RBL Liste war. <br class="">Meine Vermutung, damit ja jeder die email outgoing und damit nur zugelassen <br class="">den account des providers verwenden kann.<br class=""><br class="">Ich habe nun "reject_rbl_client <a href="http://zen.spamhaus.org" class="">zen.spamhaus.org</a>" entfernt bin mir aber <br class="">unsicher ob dies wirklich gut ist oder ich was übersehen habe.<br class=""><br class="">Folgende Fragen:<br class=""><br class="">a) habe ich dabei was falsch gemacht, speziell bei permit_sasl_authenticated <br class="">?<br class=""><br class="">b) Gibt es eine Grund warum Kolab rbl liste von spamhaus verwendet, bzw. habe <br class="">ich jetzt ein relevant erhöhtes Sicherheitsrisiko ?<br class=""><br class="">Falls jemand damit auskennt, wäre ich um eine Meinung dankbar .<br class=""><br class="">mfG <br class=""> Winfried Ritsch<br class=""><br class="">-- <br class="">---- Atelier Algorythmics ----<br class="">Winfried Ritsch<br class="">Leitnergasse 7a, <br class="">A-8010 Graz<br class="">Austria<br class="">mobil: ++43 664 2439369<br class=""><a href="http://algo.mur.at/" class="">http://algo.mur.at/</a><br class="">--------------------------------------<br class="">_______________________________________________<br class="">users-de mailing list<br class="">users-de@lists.kolab.org<br class="">https://lists.kolab.org/mailman/listinfo/users-de<br class=""></div></div></blockquote></div><br class=""></div></body></html>