[Postfix] Probleme mit Mailalias

Computer: Software & Programmierung Server-Software
#1

Hallo,

Unter Suse 9.1, CyrusIMAP & Postfix habe ich einen Verteiler über Mailalias eingerichtet.

Nehmen wir an das der Mailalias „test“ heisst und alle Mails an „[email protected]“ an x-beliebige externe Mailempfänger senden soll. Z.B.

[email protected]
[email protected]
[email protected]
usw.

Das funktioniert auch. Die Empfänger bekommen ihre Mails.
Hier die erste Frage: Gibt es noch eine andere (bessere) Möglichkeit solch einen Verteiler anzulegen und zu verwalten?

Zu meinem eigentlichen Problem:
Ich hätte gern, dass der Ansender umgeschrieben wird. So wie es jetzt ist, schickt z.B. der Versender „[email protected]“ eine Mail an den Verteiler „[email protected]“. Als Abesender steht praktisch immer der letzte Versendende drin.

Wenn man jetzt die Mail ‚beantworten‘ möchte, wird der Versender als Empfänger eingetragen, nämlich „[email protected]“.
Im Header müssten dann sowas wie
Replay to: [email protected]
stehen oder sowas.

Ich hoffe ich habe das halbwegs verständlich beschreiben können.
Danke für eure Hilfe.

Viele Grüße, olli

[anbei mal ein Header von einem Verteiler der das macht was ich möchte]


Return-Path:
Received: from h4567.serverkompetenz.net ([81.169.169.31] verified)
by mail-fe-02.mail01.ish.de (CommuniGate Pro SMTP 4.1.8)
with ESMTP id 24442834 for [email protected]; Sun, 21 Nov 2004 02:35:05 +0100
Received: by h4567.serverkompetenz.net (Postfix Linux (i386) [Linuxsupport: www.klehr.de/michael])
id 844B9854003; Sun, 21 Nov 2004 02:35:05 +0100 (CET)
Delivered-To: [email protected]
Received: from localhost (localhost [127.0.0.1])
by h4567.serverkompetenz.net (Postfix Linux (i386) [Linuxsupport: www.klehr.de/michael]) with ESMTP id 64CB9854001
for ; Sun, 21 Nov 2004 02:35:05 +0100 (CET)
Received: from h4567.serverkompetenz.net ([127.0.0.1])
by localhost (h4567 [127.0.0.1]) (amavisd-new, port 10024) with LMTP
id 26004-01 for ; Sun, 21 Nov 2004 02:35:05 +0100 (CET)
Received: from icculus.org (icculus.org [69.55.227.54])
by h4567.serverkompetenz.net (Postfix Linux (i386) [Linuxsupport: www.klehr.de/michael]) with ESMTP id 564F445C00D
for ; Sun, 21 Nov 2004 02:35:04 +0100 (CET)
Received: (qmail 20229 invoked by alias); 20 Nov 2004 20:35:18 -0500
Mailing-List: contact [email protected]; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Post:
List-Help:
List-Unsubscribe:
List-Subscribe:
Reply-To: [email protected]
Delivered-To: mailing list [email protected]
Received: (qmail 20221 invoked by uid 305); 20 Nov 2004 20:35:18 -0500
From: „James Landi“
To:
Date: Sat, 20 Nov 2004 20:34:51 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To:
Thread-Index: AcTPQVY+H3SHBRHLRDGv/ZFzzV+ryAAKN/Qg
Message-Id:
Subject: RE: [mohaa] MOHPA definative map list / game types

#2

Hallo,

Hi,

Unter Suse 9.1, CyrusIMAP & Postfix habe ich einen Verteiler
über Mailalias eingerichtet.

Aeh… naja.

Hier die erste Frage: Gibt es noch eine andere (bessere)
Möglichkeit solch einen Verteiler anzulegen und zu verwalten?

Eine Mailinglisten-Software. Damit kriegt man dann jede Menge Kontrolle ueber sowas: Moderation, beschraenkte Mailgroesse, posts nur von subscribed members, Archiv, mail2news, etc. Hier tut mailman ganz gut.

Replay to: [email protected]
stehen oder sowas.

Mailman kann konfiguriert werden, vorhandene Reply-To:-header zu entfernen oder nur beim Fehlen desselbigen einen eigenen zu setzen.

In Deinem konkreten Fall kam uebrigens…

Mailing-List: contact [email protected]; run by ezmlm
das zum Einsatz. Eine andere Mailinglisten-Software, kenn ich nicht, soll aber auch gut sein. Beide sollten bei SuSE mit dabei sein.

HTH,
Gruss vom Frank.

#3

Hallo,

Eine Mailinglisten-Software.

ACK.

Damit kriegt man dann jede Menge
Kontrolle ueber sowas: Moderation, beschraenkte Mailgroesse,
posts nur von subscribed members, Archiv, mail2news, etc.
Hier tut mailman ganz gut.

Mailman saugt IMvHO, das Web-Interface ist eine echte Beleidigung, der rest ist deutlich gebessert. Oder bin ich auf längst veraltetem Stand?

ezmlm

Eine andere Mailinglisten-Software, kenn ich
nicht, soll aber auch gut sein.

ezmlm ist meiner Meinung nach das beste, was es an Mailinglisten Software gibt. Wenn es mit Porfix gehen sollte, ist wohl eher schwer einzurichten: das Ding passt nahtlos zu qmail.

Beide sollten bei SuSE mit
dabei sein.

… was ich bei ezmlm bezweifele (nein, ich habe nicht nachgesehen).

Gruß,

Sebastian

1 Like
#4

Mailman saugt IMvHO, das Web-Interface ist eine echte
Beleidigung, der rest ist deutlich gebessert. Oder bin ich auf
längst veraltetem Stand?

Ich weiss nicht, kenn nur das, und mailman ploetzlich durch ezmlm zu ersetzen duerfte etwas Ueberzeugungsarbeit verlangen…

Wenn es mit Porfix gehen sollte, ist wohl eher schwer
einzurichten: das Ding passt nahtlos zu qmail.

… erst recht, wenn ich dafuer den MTA wechseln muesste. SA3, greylisting, ClamAV et al. mal eben so auf qmail umkonfigurieren… aehm.

Was extrem saugt ist, dass die gesamte Konfiguration vom mailman als binaere Datenbank ablegt wird, Editieren mit $EDITOR ist nicht. Ist bei ezmlm anders, oder?

Gruss vom Frank.

#5

Hallo,

Mailman saugt IMvHO, das Web-Interface ist eine echte
Beleidigung, der rest ist deutlich gebessert. Oder bin ich auf

längst veraltetem Stand?

Ich weiss nicht, kenn nur das, und mailman ploetzlich durch
ezmlm zu ersetzen duerfte etwas Ueberzeugungsarbeit
verlangen…

Ja, ich bin auch schon mal daran gescheitert :smile: An der Überzeugungsarbeit.

Wenn es mit Porfix gehen sollte, ist wohl eher schwer
einzurichten: das Ding passt nahtlos zu qmail.

… erst recht, wenn ich dafuer den MTA wechseln muesste.
SA3, greylisting, ClamAV et al. mal eben so auf qmail
umkonfigurieren… aehm.

Ja, das ist nicht ohne. Aber wenn man unbedingt will, kann man qmail auf dem Rechner zusätzlich zu Postfix laufen lassen.

Was extrem saugt ist, dass die gesamte Konfiguration vom
mailman als binaere Datenbank ablegt wird, Editieren mit
$EDITOR ist nicht. Ist bei ezmlm anders, oder?

Die User-Daten sind auch in einer binären Datenbank, die übrige Konfiguration nicht; sie ist dem vimacs zugänglich. Gewisse ähnlichkeiten mit der qmail-Konfiguration sind nicht zu leugnen …

Die User-Daten lassen sich simpel in- und exportieren, sodaß ich das binäre Format nicht als Nachteil empfinde.

Gruß,

Sebastian

#6

OffTopic greylisting

… erst recht, wenn ich dafuer den MTA wechseln muesste.
SA3, greylisting, ClamAV et al. mal eben so auf qmail
umkonfigurieren… aehm.

Das Thema greylisting bin ich vor kurzem, allerdings ganz halbherzig, angegangen. Halbherzig deshalb, weil ich derzeit keinen konkreten Bedarf dafür habe.

Aber was nicht ist, kann ja noch werden, daher habe ich ein paar Fragen an dich: Wie gross ist der Aufwand, greylisting in postfix (Debian Woody) zu integrieren? In welchem Umfeld setzt du deinen mta ein? Welche Erfolge konntest du mit greylisting erzielen? Kennst du Fälle, in denen legitime Mails aufgrund mangelhaft konfigurierter Server abgewiesen wurde? Wenn ja, wie hast du davon erfahren, kannst du deren Zahl abschätzen? Wie hoch ist der laufende Verwaltungsaufwand im Vergleich zum Erfolg abzuschätzen?

Natürlich erwarte ich nicht, dass du mir einen detaillierten Bericht anfertigst, wäre aber nett, wenn du Links zu Erfahrungsberichten hättest, oder mir zu dem einem oder anderen Subthema ein paar Anregungen geben könntest.

Gruss
Schorsch

#7

Das Thema greylisting bin ich vor kurzem, allerdings ganz
halbherzig, angegangen. Halbherzig deshalb, weil ich derzeit
keinen konkreten Bedarf dafür habe.

Bei uns war der Bedarf da, vor allem da wir teilweise Nutzer haben, deren spam:ham ungefaehr bei 200:1 liegt. Das hat zwar der SA auch alles abgefangen, mit greylisting wird er aber erheblich entlastet, so dass unter theoretischer mail-Durchsatz damit enorm vergroessert wird.

Wie gross ist der Aufwand, greylisting in postfix (Debian Woody)
zu integrieren?

Wie das genau im Woody aussieht, weiss ich nicht. Hier laeuft der uebliche Kompromiss zwischen woody und sarge. Ausgehend von [1] und dem Debian-Paket postgrey wuerde ich den Zeitaufwand grosszuegig auf einen Tag schaetzen. Was wichtig ist und wir hier zuerst vergessen haben: jeder backup-MX muss auch greylisten.

In welchem Umfeld setzt du deinen mta ein?

Im mittleren: zweistellige Nutzerzahl, ich schaetze um die 20000 mails pro Monat, weiss ich jetzt nicht genau. Teilweise sind die mail-Adressen aber in den entsprechenden Datenbanken sehr bekannt. Groesseres Umfeld ist die ansaessige TU.

Welche Erfolge konntest du mit greylisting erzielen?

Das Ergebnis war sehr gut. Das hat sich zwar weniger in den inboxes bemerkbar gemacht (da war vorher auch schon nichts), aber sehr wohl in der Anzahl der mails, die ueberhaupt durch die Filter gepruegelt werden muessen. Der Einschaltzeitpunkt war im mailgraph als deutliche Zacke zu sehen. Die TU hat dazu einen kurzen Abschnitt [2].

Kennst du Fälle, in denen legitime Mails aufgrund mangelhaft
konfigurierter Server abgewiesen wurde?

Nein. Ein paar domains, fuer die greylisting offensichtlich nicht funktioniert, kommen im Debianpaket postgrey als whitelist mit. Wiederrum muss ich da auf die TU verweisen. Die HTW Mittweida gleich um die Ecke spielt wohl nicht so richtig mit. Dies wurde relativ schnell bemerkt (der Informationswege der TU zu den Studenten ist recht kurz, ueber solche Aenderungen wir sehr gut kommuniziert), die mails von dort wurden dann ungehindert durchgelassen, ob inzwischen der mailserver der HTW gefixt wurde, weiss ich nicht.

Wie hoch ist der laufende Verwaltungsaufwand im Vergleich zum
Erfolg abzuschätzen?

Greylisting laeuft relativ selbstaendig, der technische Verwaltungsaufwand ist nahezu null. Wir haben in der Vergangenheit gelegentlich den backup MX gewechselt, da braucht es immer etwas Zeit, den anderen root zu ueberzeugen, dass greylisting eine feine Sache ist und es ggf. auf seinem Rechner einzurichten.

Aus Nutzersicht hat die Sache nur einen Haken: wenn Dir jemand ueber ein synchrones Medium mitteilt, dass er Dir dies oder jenes mal eben schnell per mail schickt, kann es schon mal sein, dass es 15min dauert, bis die mail tatsaechlich da ist. Einige Nutzer scheinen verdraengt zu haben, dass es sich bei email eigentlich um ein asynchrones Kommunikationsmittel handelt. Die wundern sich dann immer, warum sie nicht direkt die Bestaetigung fuer den newsletter, eine Anmeldung, subscription, etc. erhalten.

Gruss vom Frank.
===footnotes===
[1] http://greylisting.org/implementations/postfix.shtml
[2] http://www.tu-chemnitz.de/urz/mail/filter/greylist.html

1 Like
#8

Hallo Frank,

vielen Dank für diese ausführliche und hoch informative Antwort.

Bei uns war der Bedarf da, vor allem da wir teilweise Nutzer
haben, deren spam:ham ungefaehr bei 200:1 liegt. Das hat zwar
der SA auch alles abgefangen, mit greylisting wird er aber
erheblich entlastet, so dass unter theoretischer
mail-Durchsatz damit enorm vergroessert wird.

Nach meinen Hochrechnungen habe ich derzeit eine Auslastung von im Mittel ca. 7% der verfügbaren Kapazität. Was nicht viel heisst, da Spams nicht unbedingt gleichmässig über die Zeit verteilt ankommen. Allerdings zeigen die von dir gelinkten Mailgraphen wie auch die sehr ähnlichen Mailgraphen der Uni Würzburg (greylisting-Report in der aktuellen iX) eine Kurve, die offenbar mit einigen Monaten Verspätung auch bei uns (mittelständischer Industriebetrieb) ankommt.

[…] jeder backup-MX muss auch greylisten.

Hier scheitert’s bei mir im Moment, da mein Backup-MX beim Provider steht (gut) und ich keinen direkten Zugriff darauf habe (schlecht). Das kann sich aber evtl. schnell ändern, da ich in den letzten Tagen mehrere andere unangenehme Effekte hatte, die auf diese Kombination zurückzuführen sind. Insbesondere scheint Spamassassin Mails, die über den per SPF authorisierten Backup-MX (der nicht spamfiltert) laufen, eine Gutschrift zu geben - so dass ca 1% der Spams, die an sich geblockt werden würden, durchkommen.

Kennst du Fälle, in denen legitime Mails aufgrund mangelhaft
konfigurierter Server abgewiesen wurde?

Nein. Ein paar domains, fuer die greylisting offensichtlich
nicht funktioniert, kommen im Debianpaket postgrey als
whitelist mit. […]

Das ist halt der Punkt, an dem ich mir Sorgen mache. Unsere Kunden sitzen zum weit überwiegenden Teil im Ausland, ein sehr grosser Teil im nichteuropäischen Ausland. Und die Mailserver in Indien, in Argentinien, Pakistan und Indonesien…, verdammt viele von denen sind unter aller Sau gewartet. Hat mir schon einige whitelist-Einträge abverlangt.

Ich werde das Thema auf jeden Fall im Auge behalten und hoffe, dass, wenn der Zeitpunkt kommen sollte, an dem ich greylisting einsetzen muss, nicht bereits eingetreten ist, was Dr. Roland Völker im iX-Artikel als Ausblick prognostiziert: Greylisting funktioniert nicht zuletzt deshalb so gut, weil es noch selten zum Einsatz kommt. Mit zunehmender Verbreitung des Verfahrens ist zu befürchten, dass Spammer sich darauf einstellen. […] Im ewigen Hase-und-Igel-Spiel […] ist mit dem Greylisting also nicht das Ende der Fahnenstange erreicht.

Nochmals vielen Dank für deinen Beitrag,
Schorsch

#9

Nach meinen Hochrechnungen habe ich derzeit eine Auslastung
von im Mittel ca. 7% der verfügbaren Kapazität.

Bei uns kann es halt schnell mal passieren, dass sich unsere email-Durchsatz pro Monat mal eben potenziert. Fuer sowas wollten wir gewappnet sein.

[Dr. Roland Völker im iX-Artikel]
Greylisting funktioniert nicht zuletzt deshalb so gut, weil
es noch selten zum Einsatz kommt. Mit zunehmender Verbreitung
des Verfahrens ist zu befürchten, dass Spammer sich darauf
einstellen. […] Im ewigen Hase-und-Igel-Spiel […] ist mit
dem Greylisting also nicht das Ende der Fahnenstange
erreicht.

Herr Voelkner mag damit grundsaetzlich recht haben, vielleicht sollte er sich aber dennoch nochmal ueber die Vorgehensweise eines spammers informieren. Dieser sitzt AFAIK naemlich meistens an einem normalen dial-up-Rechner. Schickt er jetzt ploetzlich eine ungewoehnlich hohe Menge an emails raus stellt sein provider das meist durchaus schon fest und kappt ihm relativ schnell die Leitung (meist innerhalb der ersten 5min). Das (und nicht, dass spammer keine mailqueue implementieren koenne/wollen) ist meines Wissens die Basis, auf die greylisting faellt: der gemeine spammer hat keine Zeit, mails zweimal abzuschicken. Es gibt durchaus Methoden auch greylisting zu ueberlisten (z.~B. indem man die mail ueber einen offenen mailhost relayt, der kein greylisting betreibt, aber eine mailqueue hat, womit er aber trotzdem das Problem vieler mails/min hat), aber mit der Verbreitung hat das wenig zu tun. Der gewoehnliche Wald-und-Wiesen-spammer wird damit zuverlaessig ausgesperrt.

Gruss vom Frank.