Re: Behavior of postscreen_access_list = static:retry
On Mon, 30 Jan 2012 19:17:17 -0500 (EST), Wietse Venema wie...@porcupine.org wrote: Mark Alan: Would the following be an acceptable way to do it? postconf -e 'postscreen_access_list = reject' postconf -e 'soft_bounce = yes' Only if this is documented. The soft_bounce parameter is listed on the postscreen(8) manpage, this is perhaps a sufficient promise to match user expectations and so I would expect it to work. Sadly it does not. Although postscreen marks it as BLACKLISTED, then tlsproxy kicks in and lets the email pass: Only because you failed to configure postscreen_blacklist_action = drop. Wietse Not exactly a failure, as doing so would instruct postscreen to simply DISCONNECT (i.e., drop the connection immediately). In which case a single 'master_service_disable = inet' would be more elegant and similarly effective. My question should have been: Using only the frugal postscreen resources is there a way to achieve something like 'postscreen_blacklist_action = defer' , i.e., to configure it to immediately NOQUEUE all connections with a 450 SMTP reply? Thank you, M.
Re: Behavior of postscreen_access_list = static:retry
On 1/31/2012 4:36 AM, Mark Alan wrote: On Mon, 30 Jan 2012 19:17:17 -0500 (EST), Wietse Venema wie...@porcupine.org wrote: Mark Alan: Would the following be an acceptable way to do it? postconf -e 'postscreen_access_list = reject' postconf -e 'soft_bounce = yes' Only if this is documented. The soft_bounce parameter is listed on the postscreen(8) manpage, this is perhaps a sufficient promise to match user expectations and so I would expect it to work. Sadly it does not. Although postscreen marks it as BLACKLISTED, then tlsproxy kicks in and lets the email pass: Only because you failed to configure postscreen_blacklist_action = drop. Wietse Not exactly a failure, as doing so would instruct postscreen to simply DISCONNECT (i.e., drop the connection immediately). In which case a single 'master_service_disable = inet' would be more elegant and similarly effective. My question should have been: Using only the frugal postscreen resources is there a way to achieve something like 'postscreen_blacklist_action = defer' , i.e., to configure it to immediately NOQUEUE all connections with a 450 SMTP reply? Thank you, M. You need to set both postscreen_blacklist_action = drop and soft_bounce = yes. The soft_bounce changes the 521 hangup into a 421 hangup. Alternately, you can use postscreen_blacklist_action = enforce with soft_bounce = yes. This delays the 450 reject until the client sends recipient information. http://www.postfix.org/postconf.5.html#postscreen_blacklist_action http://www.postfix.org/postconf.5.html#soft_bounce -- Noel Jones
Re: Behavior of postscreen_access_list = static:retry
Mark Alan: On Mon, 30 Jan 2012 19:17:17 -0500 (EST), Wietse Venema wie...@porcupine.org wrote: Mark Alan: Would the following be an acceptable way to do it? postconf -e 'postscreen_access_list = reject' postconf -e 'soft_bounce = yes' Only if this is documented. The soft_bounce parameter is listed on the postscreen(8) manpage, this is perhaps a sufficient promise to match user expectations and so I would expect it to work. Sadly it does not. Although postscreen marks it as BLACKLISTED, then tlsproxy kicks in and lets the email pass: Only because you failed to configure postscreen_blacklist_action = drop. Wietse Not exactly a failure, as doing so would instruct postscreen to simply DISCONNECT (i.e., drop the connection immediately). In which case a According to documentation: drop Drop the connection immediately with a 521 SMTP reply. Set soft_bounce=yes to change the reply into 421. Wietse
Re: Behavior of postscreen_access_list = static:retry
On Tue, 31 Jan 2012 06:17:39 -0600, Noel Jones njo...@megan.vbhcs.org wrote: You need to set both postscreen_blacklist_action = drop and soft_bounce = yes. The soft_bounce changes the 521 hangup into a 421 hangup. Thank you Noel, If we wanted a mere 4.x.x hangup, it would be more elegant to set a single 'master_service_disable = inet' as Viktor Dukhovni pointed out. Alternately, you can use postscreen_blacklist_action = enforce with soft_bounce = yes. This delays the 450 reject until the client sends recipient information. The intention is neither to delay until some other event. The intention is to simply have postscreen immediately answer '450 Service currently unavailable' to all connections (friend or foe) that are presented to it. So, ideally: a) postscreen must answer. It is not enough to simply drop the connection as 421 does; b) it must the answer as it does at every first encounter with a new IP, i.e., with a '450 Service currently unavailable'. It did not imagine that it would be so difficult to configure postscreen/postfix to achieve such a simple specification. Thank you, M.
Re: Behavior of postscreen_access_list = static:retry
Mark Alan: It did not imagine that it would be so difficult to configure postscreen/postfix to achieve such a simple specification. The hardest part of support on this mailing list is to get a precise spec that does not conflict with itself. Once we have that, configuration is not hard at all. # postconf -n|grep postscreen postscreen_access_list = static:reject postscreen_blacklist_action = enforce postscreen_greet_banner = # telnet 127.0.0.1 smtp Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 foo.example.com ESMTP Postfix ehlo foo 250-foo.example.com 250-SIZE 1024 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN mail from:me 250 2.1.0 Ok rcpt to:you 450 4.3.2 Service currently unavailable You complained that Postfix would engage into STARTTLS, but that is a requirement if you want it to reject mail EXACTLY as if postscreen talks to a stranger. Wietse
Re: Behavior of postscreen_access_list = static:retry
On Mon, Jan 30, 2012 at 09:03:39PM +, Mark Alan wrote: Regarding the config option: postscreen_access_list = static:retry Where is retry documented as a valid access list keyword? 3) the similar syntax of 'transport_maps = static:retry' The transport table is not access(5) table, and retry is a transport, not an access keyword. Shouldn't: postconf -e 'postscreen_access_list = static:retry' ; postfix reload immediately make postscreen defer all incoming email? It should probably cause postscreen to log warnings about misconfiguration. Is there any other way to make the postscreen/postfix combination temporarily defer all incoming emails with '450 4.3.2 Service currently unavailable' (in order to give us some time to migrate the postfix server to some other IP) ? The documentation for the postscreen_access_list parameter. -- Viktor.
Re: Behavior of postscreen_access_list = static:retry
On Mon, 30 Jan 2012 21:50:52 +, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Mon, Jan 30, 2012 at 09:26:42PM +, Mark Alan wrote: Is there any other way to make the postscreen/postfix combination temporarily defer all incoming emails with '450 4.3.2 Service currently unavailable' (in order to give us some time to migrate the postfix server to some other IP) ? Just turn off the SMTP listener. This functionally identical to a 4.X.X reject and saves resources on both client and server. Thank you Viktor, In this particular setup I really need to have the server answering: Don't worry, I am alive but right now I am not able to accept your email, i.e., 450 Service currently unavailable The documentation for the postscreen_access_list parameter. Would the following be an acceptable way to do it? postconf -e 'postscreen_access_list = reject' postconf -e 'soft_bounce = yes' Only if this is documented. The soft_bounce parameter is listed on the postscreen(8) manpage, this is perhaps a sufficient promise to match user expectations and so I would expect it to work. Sadly it does not. Although postscreen marks it as BLACKLISTED, then tlsproxy kicks in and lets the email pass: Jan 30 23:12:36 mx postfix/postscreen[11975]: CONNECT from [74.125.82.181]:61868 Jan 30 23:12:36 mx postfix/postscreen[11975]: BLACKLISTED [74.125.82.181]:61868 Jan 30 23:12:42 mx postfix/tlsproxy[11978]: CONNECT from [74.125.82.181]:61868 Jan 30 23:12:42 mx postfix/tlsproxy[11978]: setting up TLS connection from [74.125.82.181]:61868 Jan 30 23:12:42 mx postfix/tlsproxy[11978]: Anonymous TLS connection established from [74.125.82.181]:61868: TLSv1 with cipher RC4-SHA (128/128 bits) This said, it is far simpler to turn off SMTP service. # postconf -e 'master_service_disable = inet' # postfix reload That is true. I too prefer to keep setups simpler (and near to the default configuration). But in this particular setup it does not help at making my server send, to every connection attempt, a 450 Service currently unavailable . Again, thank you Viktor for your time. M.
Re: Behavior of postscreen_access_list = static:retry
Mark Alan: Would the following be an acceptable way to do it? postconf -e 'postscreen_access_list = reject' postconf -e 'soft_bounce = yes' Only if this is documented. The soft_bounce parameter is listed on the postscreen(8) manpage, this is perhaps a sufficient promise to match user expectations and so I would expect it to work. Sadly it does not. Although postscreen marks it as BLACKLISTED, then tlsproxy kicks in and lets the email pass: Only because you failed to configure postscreen_blacklist_action = drop. Wietse
