Re: Make TLS errors hard, not soft

2014-02-28 Thread Peer Heinlein
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 27.02.2014 20:15, schrieb Wietse Venema: > Fifth option (best): short queue life time, to that Postfix does > not give up after the first MX host failure... ...but to that Postfix will start having Problems with Greylistung and that makes Postfi

Re: Make TLS errors hard, not soft

2014-02-28 Thread Ralf Hildebrandt
* Viktor Dukhovni : > It is far easier to enable fast delay notices, or set a very short > maximal queue lifetime if fast failure is more appropriate than > eventual success for the messages being sent. Yes, but the delay notice is (probably!) too cryptic for the end-user. -- [*] sys4 AG http:

Re: License question

2014-02-28 Thread Alessandro Vesely
Hi Wietse, On Thu 27/Feb/2014 15:00:31 +0100 Wietse Venema wrote: > > Second, I am not a legal expert, but by my reading the IPL (IBM > public license) permits making changes and distributing the resulting > program as long as one complies with the IPL. I will not comment > on combining code wit

Re: Make TLS errors hard, not soft

2014-02-28 Thread Wietse Venema
Peer Heinlein: > Am 27.02.2014 20:15, schrieb Wietse Venema: > > > Fifth option (best): short queue life time, to that Postfix does > > not give up after the first MX host failure... > > ...but to that Postfix will start having Problems with Greylistung and > that makes Postfix bouncing mails eve

Re: Make TLS errors hard, not soft

2014-02-28 Thread Wietse Venema
Ralf Hildebrandt: > * Viktor Dukhovni : > > > It is far easier to enable fast delay notices, or set a very short > > maximal queue lifetime if fast failure is more appropriate than > > eventual success for the messages being sent. > > Yes, but the delay notice is (probably!) too cryptic for the e

Re: License question

2014-02-28 Thread Wietse Venema
Alessandro Vesely: > Hi Wietse, > > On Thu 27/Feb/2014 15:00:31 +0100 Wietse Venema wrote: > > > > Second, I am not a legal expert, but by my reading the IPL (IBM > > public license) permits making changes and distributing the resulting > > program as long as one complies with the IPL. I will no

Re: Make TLS errors hard, not soft

2014-02-28 Thread Wietse Venema
Wietse Venema: > Ralf Hildebrandt: > > * Viktor Dukhovni : > > > > > It is far easier to enable fast delay notices, or set a very short > > > maximal queue lifetime if fast failure is more appropriate than > > > eventual success for the messages being sent. > > > > Yes, but the delay notice is (p

Re: qmgr_queue_throttle not fired up in 2.12.20140209

2014-02-28 Thread Birta Levente
On 24/02/2014 02:59, Wietse Venema wrote: Wietse Venema: Birta Levente: On 21/02/2014 15:44, Wietse Venema wrote: The behavior that you seem to prefer (throttle down domains after 4XX reply to "MAIL FROM") is really a bug in the Postfix SMTP client implementation. Postfix normally does not th

Re: qmgr_queue_throttle not fired up in 2.12.20140209

2014-02-28 Thread Wietse Venema
Birta Levente: > > This turns out to be problematic, so I won't change this for now. > > Postfix should probably throttle destinations that persistently > > drop connections after deferring mail. It is a strong hint that the > > SMTP client is not welcome. > > Just for confirmation: 20140223 shoul

Re: Make TLS errors hard, not soft

2014-02-28 Thread Viktor Dukhovni
On Fri, Feb 28, 2014 at 09:16:56AM +0100, Peer Heinlein wrote: > > Fifth option (best): short queue life time, to that Postfix does > > not give up after the first MX host failure... > > ...but to that Postfix will start having Problems with Greylistung and > that makes Postfix bouncing mails ev

Re: Different content_filter for incoming & outgoing mail?

2014-02-28 Thread LuKreme
On 27 Feb 2014, at 19:46 , Noel Jones wrote: > # main.cf > smtpd_sasl_auth_enable = no > content_filter = amavis-smtp:[127.0.0.1]:10026 there's no need to set smtpd_sasl_auth_enable = no as that is the default setting. It might be a good idea to set it explicitly to remind the admin, but it's

~/.forward separator

2014-02-28 Thread Alex
Hi, I've read local(8) and numerous other man pages and postfix docs, but still can't find the definitive list of separators that are permitted to be used to separate multiple email addresses in a user's .forward file. It appears semicolons are permitted as well as commas, as per my test, but is

Re: ~/.forward separator

2014-02-28 Thread Wietse Venema
Alex: > Hi, > > I've read local(8) and numerous other man pages and postfix docs, but > still can't find the definitive list of separators that are permitted > to be used to separate multiple email addresses in a user's .forward > file. According to local(8): An alias or ~/.forward file may li

Re: ~/.forward separator

2014-02-28 Thread Alex
Hi, >> I've read local(8) and numerous other man pages and postfix docs, but >> still can't find the definitive list of separators that are permitted >> to be used to separate multiple email addresses in a user's .forward >> file. > > According to local(8): > > An alias or ~/.forward file may li

Re: ~/.forward separator

2014-02-28 Thread Wietse Venema
Alex: > >> I've read local(8) and numerous other man pages and postfix docs, but > >> still can't find the definitive list of separators that are permitted > >> to be used to separate multiple email addresses in a user's .forward > >> file. > > > > According to local(8): > > > > An alias or ~/.fo

Re: Postfix 2.9.6/OpenLDAP Recipient Not Found in Table after Attribute Change

2014-02-28 Thread Ron Scott-Adams
So, it did end up being a Postfix problem. I eventually found the problem in mail.warn. mydestination included $myhostname, joab.tohuw.net, which was also in MailDomains in LDAP. So, I had a double-mapped entry. I removed it from mydestination and all is well. Thanks everyone. On Feb 27, 2014,