Re: Proposal: SMTP client policy protocol (for STS)

2016-03-23 Thread David Schweikert
Hi Wietse, On Tue, Mar 22, 2016 at 10:28:48 -0400, Wietse Venema wrote: > In order to protect the stability of the Postfix SMTP client, I > propose a new feature that builds on smtp_tls_policy_maps that > allows experimentation with STS and other features. Great! I am looking forward to it. >

Re: SMTP STS and policy delegation for smtp *client* ?

2016-03-21 Thread David Schweikert
Hi Michael, On Mon, Mar 21, 2016 at 20:17:02 +0100, Michael Storz wrote: > since Postfix already implements a tls policy mechanism via > smtp_tls_policy_maps you could use the tcp_table protocol to explore > the integration of STS into Postfix. This would allow a comparison > of the possibilities

Re: Disabling Anonymous Diffie Hellman

2014-05-21 Thread David Schweikert
Hi Viktor, On Tue, May 20, 2014 at 14:21:22 +, Viktor Dukhovni wrote: Facebook made the same mistakes you did: http://www.metzdowd.com/pipermail/cryptography/2014-May/021344.html In that thread you say that CA certs are futile for SMTP servers. I think that the statement is untrue:

Re: Disabling Anonymous Diffie Hellman

2014-05-21 Thread David Schweikert
Hi Viktor, On Wed, May 21, 2014 at 14:09:16 +, Viktor Dukhovni wrote: The unstated context is at Internet scale. I know about the secure level, after all I developed that feature for Postfix, while also serving as postmaster for a large company with many SMTP secure TLS peering

Re: Disabling Anonymous Diffie Hellman

2014-05-21 Thread David Schweikert
Hi Viktor, On Wed, May 21, 2014 at 15:31:20 +, Viktor Dukhovni wrote: Yes, you benefit from herd immunity. When one sending site defers mail to a destination, it is that sending site's problem. When everyone defers mail to a destination, it is the destination site's problem. Breaking

Re: Postfix 2.8 rc2 release notes

2011-01-18 Thread David Schweikert
Hi Wietse, On Tue, Jan 18, 2011 at 07:00:10 -0500, Wietse Venema wrote: I just had a look at the release notes for the Postfix 2.8 release candidate and noticed that postscreen isn't described as a completely new feature. It wasn't however included in a previous stable release. Hmm.

Re: Postfix 2.8 rc2 release notes

2011-01-18 Thread David Schweikert
On Tue, Jan 18, 2011 at 07:08:51 -0500, Wietse Venema wrote: I noticed now the last Feature paragraph. Yes, I find it not very easy to understand for Postfix 2.7 users that didn't follow the development of the feature. I can put a pointer to POSTSCREEN_README at the start of that section.

Postfix 2.8 rc2 release notes

2011-01-17 Thread David Schweikert
Hi, I just had a look at the release notes for the Postfix 2.8 release candidate and noticed that postscreen isn't described as a completely new feature. It wasn't however included in a previous stable release. Cheers David

Milter-induced temporary reject (can't read SMFIC_HEADER reply packet header)

2009-10-22 Thread David Schweikert
Hi, We are experiencing rather frequent mail deferrals because of a milter-related malfunction: Oct 22 08:48:14 mailhost3 postfix/smtpd[723]: 23C7F8FF16: client=xxx.xxx[1.2.3.4] Oct 22 08:48:14 mailhost3 postfix/cleanup[1415]: 23C7F8FF16: message-id= Oct 22 09:18:16 mailhost3

Re: Milter-induced temporary reject (can't read SMFIC_HEADER reply packet header)

2009-10-22 Thread David Schweikert
On Thu, Oct 22, 2009 at 11:32:16 -0400, Wietse Venema wrote: Postfix does not enforce timeouts - instead, Postfix depends on the kernel to do the job. When Postfix wants to read, it waits for $timeout seconds for the socket to become readable. When the kernel reports the socket is readable but

Re: Milter-induced temporary reject (can't read SMFIC_HEADER reply packet header)

2009-10-22 Thread David Schweikert
On Thu, Oct 22, 2009 at 11:52:36 -0400, Victor Duchovni wrote: Which version? All recommended patch sets applied? We have Solaris 10 (kernel patch 13-03, dated January 2009). I did now a tcpdump during another such case and I found out that this is happening during the DATA phase: the

Re: Milter-induced temporary reject (can't read SMFIC_HEADER reply packet header)

2009-10-22 Thread David Schweikert
On Thu, Oct 22, 2009 at 17:04:50 -0400, Wietse Venema wrote: smtpd_timeout is no MESSAGE TRANSFER time limit. smtpd_timeout is an INACTIVITY time limit. OK, I get it :-) Thanks for the explanation. I did solve my problem by increasing the timeout in the milter. Cheers David