[Postfixbuch-users] Greylisting empfängerindividuell aus MySQL

[Kai Fürstenberg]

Moin Ronny,

Am 17.02.2013 15:07, schrieb Ronny Seffner:
>> Außerdem ist smtpd_delay_reject defaultmäßig auf yes
>>
> Konntest Du nicht wissen, habe ich auf "no", sonst macht die Differenzierung
> der Restrictions ja - wie Du darlegst - kaum Sinn.

die macht auch sonst keinen besonderen Sinn. Es gibt nur wenige Setups,
wo dieses überhaupt sinnvoll ist.

Ich wollte z.B. in meinem Setup durch ein vorgeschobenes "Sleep" und ein
reject_unauth_pipelining frühzeitig Gurkenkisten rauswerfen, die sich
nicht an die Regeln halten.

Entsprechend sah das Setup auch aus:
smtpd_client_restrictions = sleep 2, reject_unauth_pipelining
smtpd_recipient_restrictions = ...

Das war aber auch schon alles und, da dies aber auch in den letzten
Jahren überhaupt keinen Effekt hatte, habe ich wieder umgestellt.
Außerdem soll das wohl mittlerweile Postscreen erledigen können, da muss
ich mich aber noch etwas reinlesen, bevor ich den einsetze.

>>> 	reject_unlisted_sender
>>
>> ^ der nützt hier nichts mehr, weil permit_sasl_authenticated 
>> vorher schon sein OK gegeben hat.
>>
> Rücke ich das vor permit_sasl_authenticated, verhindere ich, dass
> Authentifizierte ihren Absender fälschen - zumindest außerhalb gültiger
> Adressen? 

dein Nachsatz trifft es eher: du verhinderst, dass irgendein Benutzer
mit irgendeiner nicht vorhandenen Adresse sendet. Ob sie ihm gehört,
spielt in diesem Test allerdings keine Rolle.
Die Parameter, die du vermutlich suchst sind
- reject_sender_login_mismatch
- reject_unauthenticated_sender_login_mismatch
- reject_authenticated_sender_login_mismatch
musst dir nur den aussuchen, den du haben willst.

Trotzdem gehören auch die _vor_ permit_sasl_authenticated, sonst haben
auch die keinen Effekt mehr.

> Dahinter ist es nicht grundsätzlich verkehrt, nur halb so wirksam,
> ja?

Er ist gar nicht mehr wirksam. Den könntest du hier auch gleich
weglassen. permit_sasl_authenticated sendet im Erfolgsfall ein OK. Damit
ist die Mail angenommen. Alle nachfolgenden Tests spielen keine Rolle mehr.

>>> 	reject_unverified_recipient
>>
>> ^ vielleicht auch etwas weiter nach oben?
>>
> Das ist doch recipient-address-verification, braucht also DNS und baut eine
> SMTP-Verbindung zum Empfänger auf um zu prüfen, ob es den dort überhaupt
> gibt - richtig? Dann scheint mir der Test teuer und deshalb habe ich ihn
> hinten. Ich kann nicht genau einschätzen, was teurer ist, dieser Test,
> policy-weightd, spf, greylist - hier sollte ich ihn wohl "richtig"
> einordnen.

Wenn du relayst und das Setup die Verifizierung des Empfängers einer
lokalen Datenbank vorzieht, ist die Prüfung auf einen nicht
existierenden User und die Ablehnung der Mail immer noch "billiger", als
tausend weitere Tests durchzuführen, die möglicherweise bestanden
werden, um dann festzustellen dass die Mail nicht für dich bestimmt ist.

Ich sage aber auch: das kann möglicherweise genau so gewollt sein.

Ich für meinen Teil ziehe die Ablehnung aufgrund eines nicht
existierenden Empfängers vor. Bei mir ist aber auch der meiste Spam an
nicht existierende Empfänger gerichtet.

>> Egal wie: Das Log ist dein Freund.
>>
> Da war nichts. Zu Recht, denn es ging - ich übersah nur oder testete falsch.
> Heute sind seit meinem Eingriff gestern ausreichend "postgrey" Einträge im
> Log zu sehen. 

Dann sollte dein Problem ja gelöst sein. :-)

>>> Edit : Ich sehe gerade 2x check_recipient_access hintereinander. 
>>> Stört das?
>>> Aber auch eine Bereinigung auf einen Eintrag mit den 4 Quellen 
>>> führt zu keiner Besserung.
>>
>> Nein, das gehört sogar so. Wenn du die Einträge alle hintereinander 
>> schreibst, kann das unerwünschte Effekte haben. Das hatten wir vor 
>> kurzem hier auf der Liste.
>>
> Du meinst hier :
> https://listi.jpberlin.de/pipermail/postfixbuch-users/2012-December/059484.h
> tml? Da sagst Du "nur" es geht nicht, ich bin sicher, dass es ebi mir
> funktioniert hat. Wie dem auch sei, ich hab jetzt 5x check_recipient_access.
> Wenn ich Ralfs Antwort richtig verstehe, konnte es bei mir funktionieren,
> weil ich das ja in check_recipient_access in den recipient_restrictions
> mache.

Genau das meine ich. Ralf sagt aber auch, dass das seit Jahren bereits
obsolet ist. Außerdem macht es das Setup unübersichtlich, wenn ich mir
bei einer blanken Zeile wie
  mysql:/etc/postfix/mysql-virtual_policy_greylist.cf
noch überlegen muss, in welcher Restriction die gerade drinsteht.

-- 
Kai Fürstenberg

PM an: kai at fuerstenberg punkt ws