Re: Question about reject_unverified_recipient in smtpd_recipient_restrictions
Try add "reject_unlisted_recipient" to smtpd_recipient_restrictions.
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 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
Re: Question about reject_unverified_recipient in smtpd_recipient_restrictions
> On 23 Nov 2016, at 09:29, Mariusz Piasecki
> 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 :
Recipient address rejected: User unknown in local recipient table;
from= to= proto=SMTP helo=
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 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
>>>
>>
>>
>
Re: AW: Possible Bug ? postfix 3.1.0-3 fails on mysql table lookup
On 11/22/2016 01:35 AM, Joel Linn wrote: > Hey Guys, > > this issue has decayed a bit but I now finally found the time (and the > nerves) to integrate the fix in my system. > I'm running Ubuntu 16.04 and trying not change to many things and be > able to have clean comparison I applied the patch to the apt sources > and only replaced the postfix-mysql package (ubuntu is using 3.1.0 it > seems) with my own. > I introduced some stored procedures and from my tests I conclude it > works. I will see in the next couple of days if there are issues I > overlooked. > I ran into an issue where I was returning no result set using > "smtpd_recipient_restrictions = check_recipient_access mysql:/[...]". > I'm not sure if that's an dict_mysql issue or caused by design > upstream. I overcame that by doing "select 1 from dual where false" > when I don't have anything else to return, which basically is an empty > result set. > > Thanks very much for your work, > Joel Joel can you provide some more information to reproduce the issue you mentioned? John
Re: AW: Possible Bug ? postfix 3.1.0-3 fails on mysql table lookup
On 2016-11-23 21:57, John Fawcett wrote: On 11/22/2016 01:35 AM, Joel Linn wrote: Hey Guys, this issue has decayed a bit but I now finally found the time (and the nerves) to integrate the fix in my system. I'm running Ubuntu 16.04 and trying not change to many things and be able to have clean comparison I applied the patch to the apt sources and only replaced the postfix-mysql package (ubuntu is using 3.1.0 it seems) with my own. I introduced some stored procedures and from my tests I conclude it works. I will see in the next couple of days if there are issues I overlooked. I ran into an issue where I was returning no result set using "smtpd_recipient_restrictions = check_recipient_access mysql:/[...]". I'm not sure if that's an dict_mysql issue or caused by design upstream. I overcame that by doing "select 1 from dual where false" when I don't have anything else to return, which basically is an empty result set. Thanks very much for your work, Joel Joel can you provide some more information to reproduce the issue you mentioned? John Sure I can. Have a look at my log: Nov 23 22:42:49 leuchtkanone postfix/smtpd[5863]: connect from divmail1.helmholtz-berlin.de[134.30.104.21] Nov 23 22:42:49 leuchtkanone postfix/smtpd[5863]: warning: mysql:/etc/postfix/sql/recipient-access.cf: table lookup problem Nov 23 22:42:49 leuchtkanone postfix/smtpd[5863]: NOQUEUE: reject: RCPT from divmail1.helmholtz-berlin.de[134.30.104.21]: 451 4.3.5 : Recipient address rejected: Server configuration error; from= to= proto=ESMTP helo= I used this empty test procedure (query = CALL ret_empty;): CREATE DEFINER=`vmail`@`localhost` PROCEDURE `ret_empty`() BEGIN END In my procedure I had some code paths return a result and some not. Like I said i'm now using "SELECT 1 FROM dual WHERE false;" for those dead paths, this simulates the behavior of the previous solution (one line query) which always returns a result set, even if it's empty.
