[Postfixbuch-users] Blacklisted uceprotect.net & apews.org. Woher kam die eMail?

[Sandy Drobic]

Robert Felber wrote:

>> smtpd_recipient_restrictions zum Zeitpunkt der unbekannten eMail
>> ------------------------------------------------------------------
>> smtpd_recipient_restrictions =
>>        permit_sasl_authenticated,
>>        permit_mynetworks,
>>        warn_if_reject reject_unknown_client
>>        reject_invalid_hostname
>>        reject_unauth_destination,
>>        reject_non_fqdn_hostname,
>>        reject_non_fqdn_sender,
>>        reject_non_fqdn_recipient,
>>        reject_unknown_sender_domain,
>>        reject_unauth_pipelining,
>>        reject_rbl_client list.dsbl.org,
>>        reject_rbl_client bl.spamcop.net,
>>        reject_rbl_client zen.spamhaus.org,
>>        reject_rbl_client pbl.spamhaus.org

pbl sollte hinter zen eigentlich keine Treffer mehr anzeigen, da die pbl
in zen enthalten ist. Vielleicht noch ein paar seltene Treffer, bevor die
Einträge mit zen synchronisiert werden, mehr nicht.

>>        check_policy_service inet:127.0.0.1:60000
>>        reject_unverified_sender
>>        permit

Ich hatte früher auch einmal hinter Greylisting (policyd) noch ein
sender_verify laufen. Da aber hinter dem Greylisting fast keine Mails mehr
abgewiesen wurden durch sender_verify und die Fehlerquote erheblich
dadurch stieg, habe ich es einfach abgeschafft.

Genau das gleiche würde ich dir auch raten für reject_unknown_client.
Setze defer anstelle von defer_if_permit für Greylisting und teste dann
dahinter, ob der Einsatz von reject_unknown_client wirklich lohnt.

> (An dieser Stelle frage ich mich uebrigens, wieso postgrey per default
> DEFER_IF_PERMIT zurueckgibt, bisher viel mir so recht kein sinnvolles
> Szenario dafuer ein)

Die einzige Begründung dafür, die ich gehört habe, war: warum eine Mail
verzögern, wenn ein dahintergeschalteter Check sie ohnehin endgültig abweist.

-- 
Sandy

Antworten bitte nur in die Mailingliste!
PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com