Sandy Drobic schrieb:
[...luser_relay...]
Aber der Haken an der Sache ist doch, dass Mails an z-B. versehentlich falsch geschriebene Empfänger quasi nach /dev/null gehen, ohne, dass der Absender etwas davon erfährt. Oder sehe ich das falsch?
Ja, Mails werden in mehreren Schritten übertragen. In der Phase vor der Übertragung der eigentlichen Mail, der DATA-Phase, muss der Server bereits wissen, ob die Mail zustellbar ist und er sie annehmen soll.
Bei einer falsch geschriebenen Empfängeradresse wird die Annahme abgewiesen und der sendende Server schickt die Mail zum Empfänger zurück. Der Absender bekommt also eine Nachricht, dass die Mail nicht zugestellt werden konnte.
/dev/null wäre, wenn die Mail angenommen würde, dann aber nicht zugestellt wird, weil die Adresse falsch ist und der Absender ebenfalls nicht existiert, der Server die Mail also nicht an den Absender zurückschicken kann. Dann geht sie im besten fall noch an die doublebounce-Adresse, normalerweise den Postmaster.
Wenn der jetzt auch nicht erreichbar ist... (^-°)
/dev/null war nicht ganz glücklich gewählt von mir. Es ging ja um den Parameter luser_relay. Wenn ich diesen nun aktiviere, ich interpretiere das als catch-all-Funktion, gehen alle Mails, die keinem Empfänger zuzuordnen sind, an diese konfigurierte Adresse. Absender, die nun versehentlich an z.B. schultz@domain.tld statt an schulz@domail.tld schreiben, erfahren nicht mehr, dass ihre Mail nicht angekommen ist. Ist das denn im Sinne des Erfinders?
Ich habe am Donnerstag/Freitag den Spamassassin mal einer "Generalüberholung" unterzogen, u.a. diverse Plugins installiert. Bisher sieht es ganz gut aus. Nun suche ich noch nach einer Möglichkeit, eine Statistik darüber zu erstellen, die auch dem Management eine gewisse Aussagekraft hat. mailgraph wäre da mein Ansatzpunkt? Oder gibt es da bessere Alternativen?
Amavisd-new kann auch nach SQL loggen. Dann kannst du mit ein paar Abfragen schnell die notwendigen Werte herausziehen.
Wenn das nicht in Frage kommt, geht es auch meistens mit ein paar Scripten, welche die entsprechenden Werte herausfischen. Was genau für Statistiken brauchst du denn?
SQL wäre eine Variante, denn MySQL läuft bereits für Webmail. In Sachen Statistik dachte ich da an regelmäßige Reports, die Aufschluss über Mailvolumen insgesamt (Anzahl bzw. Größe) und den darin enthalten Spam geben. Zusätzlich noch solche Geschichten, wie Anzahl Mails an nicht existierende Empfänger u.ä. http://www.bieli.de/main/node14.html scheint mir auf den ersten Blick dafür ein brauchbarer Ansatz oder wie siehst du das?
Wenn ihr immer noch eine statische IP habt, dann sollte euer Provider zumindest reject_unverified_recipient (Postfix) oder ein Pendant benutzen können. Sprich, sein Relay fragt vor der Annahme erst bei eurem Server nach, ob dieser die Empfängeradresse kennt.
Wieso statische IP? Der Relay-Server kennt unseren Mailserver doch bzw. dessen interne IP-Adresse. Aber bezüglich dieser Möglichkeit der Benutzerverifizierung werde ich den Provider mal kontaktieren.
interne IP? der Relayserver eures Providers kennt doch nicht die interne IP eures Servers?!?
Doch, der Mailserver hat nur noch eine interne (192.168.*.*) Adresse. Der Provider stellt ja gleichzeitig die Infrastruktur für den Internetzugang bzw. das VPN zur Verfügung. Er bietet so eine Art Intranet mit Proxy-Schnittstellen ins Internet über seinen eigenen MLPS-Backbone. Wenn dich technische Einzelheiten interessieren, könnte ich dir entsprechende Links zukommen lassen. -- 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