Postfix postafiókot csinál nem létező usernek

Sziasztok!

Valahol elcsúszik a postfix/dovecot konfigom és egyelőre nem lelem hol.
Kutya közönséges rendszer, ldap-ból kérdezi le a usereket, dovecot-lmtp kézbesít, amavis szűr, minden csodálatos. Egy dolgot kivéve: ha egy spoofolt feladó, akinek a címe a saját domain-ról jönne, létező címre küld spamet és azt észreveszi az amavis (vbs kiterjesztésű melléklet), küld neki egy választ, hogy ezt a levelet nem fogja kézbesíteni. Normál esetben ennek a válasz levélnek nem kéne megérkezni, mert a spoofolt feladó nem létezik a rendszerben. Ennek ellenére létrehoz neki egy postafiókot és beleteszi a levelet.
Vagyis ha dick.25@domain.hu küld a létező_user@domain.hu-ra.
Tehát ebben az esetben kimarad a címzett ellenőrzése.
Main.cf: http://pastebin.com/t8taXTSP
Master.cf lényeges része: http://pastebin.com/J3cNPqf0

Hol néztem be valamit?

Köszönöm!

Hozzászólások

Talán valamelyik ezek közül neked minden címre matchel:

virtual_mailbox_maps = proxy:ldap:/etc/postfix/ad_virtual_mailbox_maps.cf
virtual_alias_maps = proxy:ldap:/etc/postfix/ldap-group.cf, proxy:ldap:/etc/postfix/ldap-alias.cf

Próba adatokkal le kellene tesztelni, hogy jó-e. LDAP-ot nem használtam még, nem ismerem milyen query-k vannak ott, de innen indulnék.

Illetve a recepient szűrésbe én még betenném min. ezt: reject_unlisted_recipient,

Úgy néz ki akkor történik ilyen, ha nem 'egyenes' úton halad befelé a levél. Tehát, ha postfix -> amavis -> dovecot -> postaláda az út, akkor minden ok, az ismeretlen címzett jelzésre kerül és nem készül postafiók.
De ha postfix -> amavis -> postfix -> dovecot az út, mert valami miatt az amavis küldene valamit, na akkor legyen bárki is a feladó, ha saját domain-es, készül neki postafiók.
Fejvakarós smiley...

Persze, ezek kamu levelek, de ezt nem tudom kiszűrni, bárki hamisíthat feladót, nem lenne ezzel semmi gond, ha utána nem generálódna új postafiók :)
Tehát írjak bele egy $notify_method = 'smtp:[192.0.2.1]:20025'-t az amavisba és vegyek fel egy smtp transportot a main.cf-be pl a 20025-ös portra és abba rakjak recipient ellenőrzést?

Oké, szerintem a sorrend nem jó itt:
smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination

A permit_mynetworks legyen hátrébb.

Amúgy elférne még pár policy. Nálam:


smtpd_client_restrictions   = permit_mynetworks,
			      check_client_access hash:/etc/postfix/access1_client,
			      permit_sasl_authenticated,
			      reject_unknown_client_hostname,
			      reject_unknown_reverse_client_hostname



smtpd_helo_restrictions      = permit_mynetworks,
                               permit_sasl_authenticated,
                               check_helo_access  hash:/etc/postfix/access2_helo,
                               reject_invalid_helo_hostname,
                               reject_non_fqdn_helo_hostname,
			       reject_unknown_helo_hostname,
			       reject_invalid_hostname,
			       reject_non_fqdn_hostname
			       #reject_unknown_hostname

smtpd_sender_restrictions    = check_sender_access hash:/etc/postfix/access3_sender,
                               reject_non_fqdn_sender,
                               reject_unknown_sender_domain,
#                               reject_sender_login_mismatch,
                               permit_mynetworks,
                               permit_sasl_authenticated

smtpd_recipient_restrictions = reject_non_fqdn_recipient,
                               reject_unknown_recipient_domain,
                               permit_mynetworks,
                               permit_sasl_authenticated,
                               check_recipient_access hash:/etc/postfix/access4_recipient,
                               reject_unauth_destination,
                               reject_unlisted_recipient,
#                               reject_unverified_sender,
                               permit



smtpd_data_restrictions      = reject_multi_recipient_bounce,
                               reject_unauth_pipelining

Igen, cseréld vissza, közben láttam, hogy nálam is úgy van, mint nálad. Így akkor az más. Viszont van ott még pár szabály. Próbáld már ki, hogy 1:1-ben bemásolod az én policy listámat, kiszedve az access* sorokat, mert olyanod még úgy sincs.
Néztem a master.cf fájlodat, nálam is úgy van az amavis és nem okoz problémát.

Master.cf-ben melyik instance-nél?

Olyan viszont nincs, hogy "benne is kell legyen", mert nyilván egy opció, van ahol benne kell lennie és van ahol nem.

Az egyik általam üzemeltett postfix-nél a main.cf-ben (ez a default) ez van:

receive_override_options = no_address_mappings

A master.cf-ben pedig a content filtertől visszatérő smtpd-nél ezt felülírom így:

-o receive_override_options=no_unknown_recipient_checks,no_milters

Tehát az egyiknél van unkown_recepient_check. Bár lehet nem is itt van a probléma.

Kicsit bele vagyok most gabalyodva a dolgokba.
Elvileg a master.cf-ben elhelyezett receive_override_options arra jó, hogy tehermentesítsük a szervert a dupla munkavégzés alól, hiszen a címzett ellenőrzést egyszer már elvégezte. Ez ok, de esetemben az eredeti címzett létezik, viszont a notification címzett nem. Ha pedig ezt visszaillesztéskor nem ellenőrzi, akkor érthető, hogy simán bekerül a levél.
Lehet, hogy tényleg az lesz a megoldás, hogy a notification_method-ot máshova kell irányítanom, csak fura, hogy ezzel más nem találkozott...