* Jan L�hr <[EMAIL PROTECTED]> [20041226 17:46]: > ja hallo erstmal,... > > Am Sonntag, 26. Dezember 2004 16:28 schrieb Felix M. Palmen: > > * Michelle Konzack <[EMAIL PROTECTED]> [20041226 13:59]: > > > Wenn Du fetchmail+procmail verwendest, kannste nicht bouncen. > > > Da gibt es nur /dev/null. > > > > > > Bouncen geht nur auf SMTP-Level, also von courier-mta, exim > > > oder postfix aus. Dann kannste spamassassin einbinden. > > > > Das genaue Gegenteil ist der Fall. > > Nein. Jeder SMTP-Server kann bouncen, wenn er die Nachricht nicht weiter > zustellen kann.
Ja. Ersetze SMTP-Server mit MTA, dann wird es logischer. Ich w�rde das jedenfalls nicht als "SMTP-Level" bezeichnen. Auf SMTP-Level wird rejected, der andere beteiligte MTA generiert dann ggf. einen Bounce. > Ja. Daher auch procmail Ebene. Ich habe ich meine Spamassasin, der schon viel > Spam killt. Nun ja, wenn SA vorher den Spam kommentarlos rausfiltert ist das vielleicht eine brauchbare L�sung, zumindest ist das Risiko wesentlich geringer, dass du jemanden mit fehlgeleiteten Bounces nervst. Mit procmail kannst du das ja mit mehreren recipes nach Schema :0 *^Content-Type: multipart/signed inbox :0 EB *--BEGIN PGP inbox :0 E *^From:.*WHITELIST inbox :0 E *^From:.*BLACKLIST /dev/null :0 E |/foo/bar.pl und bar.pl muss eben aus <STDIN> den Return-Path raussuchen und dann z.B. mit mail einen korrekten Bounce basteln. Mal so als grobes Schema. Gr��e, Felix -- | /"\ ASCII Ribbon | Felix M. Palmen (Zirias) http://zirias.ath.cx/ | | \ / Campaign Against | [EMAIL PROTECTED] encrypted mail welcome | | X HTML In Mail | PGP key: http://zirias.ath.cx/pub.txt | | / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683 |
signature.asc
Description: Digital signature
