> On 23 Nov 2016, at 09:29, Mariusz Piasecki <mariusz.piase...@extranet.pl>
> wrote:
>
> Try add "reject_unlisted_recipient" to smtpd_recipient_restrictions.
Thank you. That was, it seems, what I was looking for. With
smtpd_recipient_restrictions =
reject_unauth_pipelining,
reject_non_fqdn_recipient,
permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination,
reject_unlisted_recipient,
# reject_unknown_recipient_domain,
# reject_unverified_recipient,
check_client_access
regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_clients,
check_sender_access
regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_senders,
check_policy_service unix:private/policy,
permit
authenticated/local users can use the MTA without real restrictions, whereas
the open service on port 25 is limited to the local domains and then only known
recipients. t worked immediately:
Nov 23 12:48:19 vanroodewierda.rna.nl postfix/smtpd[41019]: NOQUEUE: reject:
RCPT from deric.instagolf.es[185.46.165.53]: 550 5.1.1 <wie...@rna.nl>:
Recipient address rejected: User unknown in local recipient table;
from=<he...@instagolf.es> to=<wie...@rna.nl> proto=SMTP helo=<instagolf.es>
Nov 23 12:48:19 vanroodewierda.rna.nl postfix/smtpd[41019]: disconnect from
deric.instagolf.es[185.46.165.53]
The commented entries are now unnecessary. I could move them up before
ssl_authenticated to protect my own users against errors.
G
>
> W dniu 2016-11-22 o 12:38, Mariusz Piasecki pisze:
>> You should check master.cf, maybe you have some commands below services
>> which overrides main.cf.
>>
>>
>> W dniu 2016-11-21 o 21:17, Wietse Venema pisze:
>>> Gerben Wierda:
>>>>> On 21 Nov 2016, at 17:33, Wietse Venema <wie...@porcupine.org> wrote:
>>>>>
>>>>> Gerben Wierda:
>>>>>> smtpd_recipient_restrictions =
>>>>>> permit_sasl_authenticated
>>>>>> permit_mynetworks
>>>>>> reject_unauth_destination
>>>>>> reject_unknown_recipient_domain
>>>>>> reject_unverified_recipient
>>>>> You may want to look at these settings (defaults shown):
>>>>>
>>>>> unverified_recipient_defer_code = 450
>>>>> unverified_recipient_reject_code = 450
>>>>> unverified_recipient_reject_reason =
>>>>> unverified_recipient_tempfail_action = $reject_tempfail_action
>>>>> reject_tempfail_action = defer_if_permit
>>>> from postconf:
>>>>
>>>> address_verify_map = btree:$data_directory/verify_cache
>>>> unverified_recipient_defer_code = 450
>>>> unverified_recipient_reject_code = 450
>>>> unverified_recipient_reject_reason =
>>>> unverified_recipient_tempfail_action = $reject_tempfail_action
>>>> reject_tempfail_action = defer_if_permit
>>>>
>>>>> I suspect that you're hitting a cached defer_if_permit response.
>>> Actually, the stored info is one of {accepted, deferred, rejected}.
>>> I cannot quickly locate the code that uses the
>>> unverified_recipient_tempfail_action setting.
>>>
>>>> Or should I just have to add to main.cf:
>>>> unverified_recipient_reject_code = 550
>>>> and do a reload?
>>> Yes, you probably want to reject mail immediately.
>>>
>>>> Another question. The phrase ?Reject the request when mail to the
>>>> RCPT TO address is known to bounce, or when the recipient address
>>>> destination is not reachable.? leads to some confusion for me.
>>>> Does ?not reachable? also include temporary failures?
>>> Temporary failure means that the answer is not known. When making
>>> an irreversible decision (like permanently rejecting mail), Postfix
>>> is quite insistent on making the distinction between having and not
>>> having authoritative information.
>>>
>>> Wietse
>>>
>>
>>
>
