Sieve választ küld nem létező local mailre is

Sziasztok!

A cím kicsit hülyén hangzik, az a lényeg, hogy a felhasználó 'home'-jába lerakott vacation sieve script szépen küldi az Out of Office válaszokat, de ha teszt jelleggel egy nem létező local mail címről küldök, arra is szépen válaszol és a Dovecot bepakolja a helyére, a nincsilyen@domain.hu-ba. Alapból persze nem fogad nem létező címre a Dovecot, csak a sieve-től.
Van ennek valami értelme? :)

Köszönöm!

Hozzászólások

"Alapból persze nem fogad nem létező címre a Dovecot, csak a sieve-től."
Biztos ez?

Illetve szerintem a sieve is keresztülzavarja a cuccot a postfix-en (gondolom az van, bár lehet más is az MTA), szóval a postfix-nek ki kellene szórni a nem létező címre jövő levelet _ha_ úgy lenne beállítva. Ebben az esetben menne a levél mailer daemon-tól, arra is válaszolna a sieve, aztán itt valahogy megállna a dolog. Legalábbis szerintem.
Viszont erős a gyanúm, hogy a sieve valahonnan mynetworks alól dolgozik, a postfix-ben pedig a mindenféle restrictions-ök úgy kezdődnek, hogy permit_mynetworks...

Ezt teszteld le telnet localhost 25-öttel szerintem.

Ez biztos, próbáltam, szépen megy a nem létező user üzenet.
Most kipróbáltam egy külsős gépről, ami nincs a mynetworks-ben: levél elmegy, bekerül a queue-ba, aztán lesz belőle egy MAILER-DAEMON -> nem létező feladó, de ezt is szépen kézbesíti, csinál neki könyvtárat, mintha local user lenne.
A logban az látszik, hogy átmegy az amavison, az visszaadja és kézbesítésre kerül, csak még azt nem értem miért.
Submission-nél ez van:

submission inet n - - - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING

Amavis:

smtp-amavis unix - - - - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o max_use=20

127.0.0.1:10025 inet n - - - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o mynetworks=127.0.0.0/8
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks

Esetleg ez a no_unknown_recipient_checks lenne a bűnös?

Azt nem értem még, hogy kerül a sieve a láncba. Van ugye egy kliens smtp -> postfix, postfix smtp -> amavis, amavis smtp -> postfix, postfix lmtp -> dovecot. Itt ugye az elején a postfix eldönti, hogy létezik-e a címzett. De hova szúrja be a vacation levelet a sieve, ha olyankor már egyértelműen nem történik ellenőrzés?

Megjön a levél a mailbox-ba, és ott a címzett alapján lefut a sieve script (ha van).
A sieve script pedig szerintem smtp-n beküldi a postfix-nek a levelet, ami megint végigmegy a pf->amavis->pf->dovecot láncon, és mivel mynetworks-ből jön ezért különösebb ellenőrzés sincs rá, főleg ha meg van neki mondva hogy no_unknown_recipient_checks