Juergen Pabst wrote:
/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?
Ja. Früher, als der Anteil der Müllmails noch nicht so überwältigend war, konnte man das Bouncen von Mails an falsche Adressen noch einigermaßen vertragen. Heute ist jedoch der Anteil an Spam/Viren derart hoch, dass ein bouncender Server schnell auf Blacklists landet. Bei euch wäre es der MX des Providers, der bounced. Aber der ist schließlich auch euer Gateway, nicht wahr? Mit luser_relay muss man sich selbst um die entsprechenden Benachrichtigungen kümmern. Der Name spricht ja schon für sich.
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?
Beides ist sehr brauchbar und bei mir im Einsatz. Mailgraph liefert einen schnellen Überblick über die Last auf dem Server und pflogsumm den Detailblick vom vorigen Tag.
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.
Ich glaube, ich kriege Gänsehaut... -- 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