[Postfixbuch-users] welche blacklists?

PV pv_mailings at amaltea.ath.cx
Sa Okt 31 22:16:06 CET 2009


Alois Kratochwill schrieb:
> Hi,
> und nun wäre ein Musterbeispiel eurer Erkenntniss für uns alle von großem
> Nutzen!
Du meinst ein Musterbeispiel für 'warum ist es "besser"
reject_unauth_destination vor den RBL Checks zu setzen'?

Nun ähm, also
das ist seine Konfig:
smtpd_recipient_restrictions =
    check_client_access cidr:/etc/postfix/access_client,
    check_helo_access btree:/etc/postfix/access_helo,
    check_sender_access btree:/etc/postfix/access_sender,
    check_recipient_access btree:/etc/postfix/access_recipient,
    reject_nonfqdn_sender,
    reject_nonfqdn_recipient,
    reject_unknown_sender_domain,
    reject_unknown_recipient_domain,
    permit_sasl_authenticated,
    permit_mynetworks,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client ix.dnsbl.manitu.net,
    reject_rbl_client bl.spamcop.net,
    reject_rbl_client dnsbl.njabl.org,
    recect_rbl_client list.dsbl.org,
    reject_rhsbl_client blackhole.securitysage.com,
    check_policy_service inet:127.0.0.1:12525,
    check_policy_service inet:127.0.0.1:60000,
    reject_unverified_recipient,
    reject_unauth_destination,
    permit

Und das würde ich daraus machen:
smtpd_recipient_restrictions =
    check_recipient_access btree:/etc/postfix/access_recipient-rfc,
    check_client_access cidr:/etc/postfix/access_client,
    check_helo_access btree:/etc/postfix/access_helo,
    check_sender_access btree:/etc/postfix/access_sender,
    check_recipient_access btree:/etc/postfix/access_recipient,
    reject_nonfqdn_sender,
    reject_nonfqdn_recipient,
    reject_unknown_sender_domain,
    reject_unknown_recipient_domain,
    permit_sasl_authenticated,
    permit_mynetworks,
    reject_invalid_helo_hostname,
    reject_unauth_destination,
    reject_rbl_client ix.dnsbl.manitu.net,
    check_policy_service inet:127.0.0.1:12525,
    check_policy_service inet:127.0.0.1:60000,
    reject_unverified_recipient
smtpd_data_restrictions         =
    reject_multi_recipient_bounce
    warn_if_reject reject_unauth_pipelining

Soll heißen:
Ich setze reject_unauth_destination direkt nachdem ganz klar ist, dass
die Mail auslieferbar ist (also nach check_mumble_dings, fqdn,
permit_bla) oder von meinen Leuten (sasl & mynetworks).
Wenn die Mail bis hierhin noch nicht permittet wurde, ist fast sicher,
dass die Mail von fremden stammt.
Da ich keine kaputten Helo mag, setze ich es direkt danach ein. Kann
sein, muss nicht. Der check kostet nichts und liefert wenig false positivs.
Dann stellst du sicher, dass der Server bei der Mail weiß, dass die Mail
auch für ihn bestimmt ist (reject_unauth_destination).
Weil ich Manitus Liste sehr vertraue, setze ich den als harten reject ein.
Anschliessend erst starte ich die spritverbrauchenden Motoren an und
setze postgrey und polw ein.
Wen die Mail das überlebt hat, dann wird erst wieder das
wieder ressourcenverbrauchende Verifying gestartet. Am besten mit DB.
z.B.
address_verify_map      = btree:/var/lib/postfix/address_verify_map_DB
Anschliessend noch ein paar andere kuriose aber sinnvolle Rejects
(multi_recipient).

Alles klar?

Viele Grüße
Paul




> 
> Danke,
> Alois
> 
> 
> 
> 
> 
> 
> 
> -------------------
> Hi Paul,
> 
> ja, wir denken in die selbe Richtung.
> Du drückst es nur besser und richtiger aus.
> 
> Viele Grüße
> 
> Norbert
> 
> PV schrieb:
> 
>>> Ja, das meinte ich: man REJECTED hier alles, was nicht für die
>>> eigenen Adressen gültig ist und vermeidet so, quasi intern noch
>>> zum Spam-Verteiler zu werden?
>>> Danke und freundliche Grüße
>> Ich bin mir nicht ganz sicher, ob wir uns verstehen, daher hier noch ein
>> paar Brainstorming Gedanken.
>>
>> So früh wie möglich, so spät wie nötig... würde ich
>> reject_unauth_destination setzen, denn
>> warum z.B. einen RBL Check durchführen, wenn klar ist, dass du sowieso
>> nicht zuständig für die Zieldomain bist.
>>
>> Ich denke, wir denken schon in die richtige Richtung. :)
>>
>> Gruß,
>> Paul
>>
>>> Norbert
>> --
> 
> 
> --
> _______________________________________________
> Postfixbuch-users -- http://www.postfixbuch.de
> Heinlein Professional Linux Support GmbH
> 
> Postfixbuch-users at listen.jpberlin.de
> https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users



Mehr Informationen über die Mailingliste Postfixbuch-users