[Postfixbuch-users] Alternative zu reject_non_fqdn_sender

[Sandy Drobic]

Ralf Petry wrote:
> Am Donnerstag, den 29.06.2006, 16:44 +0200 schrieb Sandy Drobic:
>> Ralf Petry wrote:
>>> Am Donnerstag, den 29.06.2006, 15:51 +0200 schrieb Sandy Drobic:
>>>> Ralf Petry wrote:
>>>>> Hallo,
>>>>> gibt es eine Alternative zu den reject_non_fqdn_sender Massnahmen in
>>>>> bsw. smtpd-recipient-restrictions, zum Beispiel als
>>>>> redirect_non_fqdn_sender und das dann in eine extra mailbox, an
>>>>> spamassassin vorbei?
>>>> Error, error, data not sufficient...
>>>> Bitte mal etwas ausführlicher, was genau das Problem ist und was du 
>>>> erreichen möchtest.
>>> hy,
>>> gegenwärtig holen meine server per fetchmail mail von pop-boxen bei
>>> 1und1 hab und spielen sie ins system. postfix nimmt die an, übergibt die
>>> amavisd-new, dort laufen sie durch die virenfilter und spamassassin. die
>>> crux dabei ist zum einen, dass jede menge spam nicht als solche
>>> gekennzeichnet wird und dass spam überhaupt in die mailboxen der
>>> endbenutzer kommt. letzteres durchaus auch mit einer entsprechenden
>>> kennzeichnung, soweit spamassassin diese mail als solche brandmarkt. dem
>>> benutzer ist es dann überlassen, diese mails zu löschen. dem gesetz ist
>>> zwar genüge getan, dadurch, dass dem endbenutzer jegliche an ihn
>>> gerichtete mail zugeführt wird - jedoch möchten viele dass sie die
>>> spammails gar nicht erst zu sehen bekommen.
>> Da ist die Wurzel des Übels wohl der Provider, der die Mails für euch 
>> schon annimmt. Prüfe doch mal, ob du daran etwas ändern kannst.
> nee, da hat mein chef wohl die hand drauf - wir sind noch im
> kommunikationsprozess (ähem) - ich komm da nicht ran.

Dann ist der erste Schritt schon einmal, dies DEUTLICH zu kommunizieren, 
dass die Fetchmail-Konfiguration die Ursache für die schwierige 
Spambekämpfung ist.
Der Chef muss wissen, dass er selbst mit dieser Entscheidung eine große 
Hürde aufbaut. Auch muss kommuniziert werden, dass eine alternative Lösung 
ungewiss, nicht kurzfristig möglich und fehleranfällig ist. Wenn der Chef 
das weiss UND anerkannt hat, dann kann er dir sagen, was du dann machen 
sollst.

Wichtigster Punkt ist hier wirklich, dass du dich nicht zum Sündenbock 
machen lässt, wenn du nicht die Möglichkeit hast, die technisch korrekte 
Lösung zu wählen. Das ist ein netter Eiertanz, zwischen den genervten 
Anwendern, dem blockierenden Chef, der auf der einen Seite sagt "die 
Konfiguration wird grundsätzlich nicht geändert", dann aber fragt "Warum 
ist das Problem mit dem Spam nicht behoben?" und dem eigenen Frust, weil 
man ja weiss, wie es besser geht.

Für solche Sachen sind graphische Darstellungen wie Mailgraph immer sehr 
schön. Da kann ich meinen Chefs immer eindrucksvoll zeigen, wie bereits 
90-95% des Spams geblockt werden, und das bei relativ kulanten 
Einstellungen. In meinem Urlaub war genau der Port am Switch defekt, an 
dem unser Postfix Mailgateway hing, und meine Vertretung hatte deshalb die 
Mails direkt an unseren Dominoserver geschickt, der nur ein paar RBLs in 
der Konfig hat. Da haben die Mitarbeiter direkt gespürt, was für einen 
Unterschied das macht. (^-°)

>>> ich habe mir ralf hildebrandts beispielkonfiguration angesehen und bin
>>> dabei über die smtpd_recipient_restrictions gestolpert. wenn ich das
>>> richtig sehe, rejected postfix anhand bestimmter kriterien (wie bsw.
>>> reject_non_fqdn_sender) bestimmte mails.
>> Du hast keine SMTP-Verbindung, und der einliefernde Client bei Fetchmail 
>> ist localhost, da laufen diese Prüfungen leider ins Leere.
> aber aber aber smtpd_sender_restriction=hash:sender_access mit einem
> entsprechenden eintrag in der sender_access table tut. (wir hatten da
> schon mal ne diskussion ende mai)

Ah, stimmt, Fetchmail sendet zwar von localhost, aber über SMTP, und damit 
greifen die smtp_*_restrictions. Nur ist es eben nicht so hilfreich, weil 
DNS- und Client-IP-Checks keinen Sinn machen.

Wie gesagt, wenn dein Chef an Fetchmail festhält, dann musst du dich in 
RegExp, Perl und Spamassassin einarbeiten, und das dauert seine Zeit.

>> Du kannst höchstens header-checks in Postfix schreiben, die nach non-fqdn 
>> Mustern suchen, um Mails umzuleiten, aber das ist sehr fehleranfällig und 
>> deshalb nicht unbedingt zu empfehlen.
>>
>>> ich möchte gerne erreichen, dass mails, die in unsere systeme kommen,
>>> wenn sie solche kriterien erfüllen (wie bsw. non_fqdn_sender), nicht
>>> rejected werden, sondern direkt in eine bestimmte mailbox laufen. ich
>> Rejecten geht nicht, dann würdet ihr zur Backscatter-Quelle.
> will ich auch gar nicht und auch gar nicht sein.
>>> verspreche mir davon, dass 1. spamassassin weniger zu tun hat (nicht
>>> dass es performance-probleme gäbe, aber was man nicht mehr untersuchen
>>> muss, muss man nicht mehr untersuchen) und 2. die endbenutzer weniger
>>> spam auszusortieren haben und 3. trotzdem keine mails verloren gehen.
>>> also: fetchmail holt die mail aus den 1und1 boxen, postfix macht den
>>> smtpd_recipient_restriction test, mails werden entweder an den
>>> endbenutzer zugestellt oder irgendwo anders hin (redirect) (bei woanders
>>> hin kann ich von zeit zu zeit prüfen, ob keine false-positive dabei
>>> waren). mit den body und header checks müsste das gehen, aber auf die
>>> anderen kriterien will ich ebenfalls nicht verzichten.
>>> war jetzt etwas umfänglich, sorry, aber ich hoffe, dass ich mich soweit
>>> verständlich ausgedrückt habe.
>> Yepp, jetzt weiss ich wenigstens was genau du erreichen willst und wo das 
>> Problem dabei ist.
>>
>> Wichtigster Hebel hier ist, Fetchmail zu beseitigen. Wenn das nicht 
>> möglich ist, würde ich mir schwer überlegen, ob es wirklich Sinn macht, 
>> viel Arbeit in fehleranfällige header-checks oder SA-Checks zu investieren.
> tja, das geht leider nicht. entweder leben alle mit dem spam, oder ich
> finde doch einen weg und wenn ich erstmal nur body und headerchecks
> nehme.

Wie gesagt, ich würde nicht zuviel Arbeit in dieses Projekt stecken und 
ruhig etwas Leidensdruck aufbauen lassen. Schließlich hast du als Admin 
auch noch andere Arbeiten zu erledigen. Frage deinen Chef doch einmal, 
wieviel Zeit du in diese Problematik investieren kannst, dann kannst du 
ihm zumindest sagen, welche Erfolgsaussicht du dabei siehst. Siehe oben: 
lasse dich nicht zum Sündenbock machen.

Du kannst vielleicht einen Anfang machen, indem du prüfst, welche Spams 
durch welche Checks direkt abgewiesen würden. Dann kannst du ja versuchen, 
einen Test zu bauen, der das als Perl- oder Batchscript emuliert und als 
Aktion den gewüschten Transport oder Redirect herausgibt.

Wenn das anhand von ein paar Testmails erfolgreich ist, baue das Script 
als Pipe content_filter ein und teste es anhand eines eigenen Transportes 
mit einer Auswahl von Spam und Ham.

Wenn der Filter dann robust läuft, dann binde ihn vor amavisd-new als 
allgemeinen ersten Check ein, der erkannten Müll direkt in die Spambox 
schiebt und nur den Rest an Amavis übergibt.

Ob das Konzept Aussicht hat, solltest du anhand einer Statistik deiner 
Spams erst einmal prüfen. Der Test müsste ja anhand der Headerzeile 
gemacht werden, wo die Mail von 1und1 entgegengenommen wurde.

Sandy