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.
>
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
Hi,
I wonder what the Postfix community thinks or plans to do according to
this standard that is being written:
https://datatracker.ietf.org/doc/draft-margolis-smtp-sts/?include_text=1
I personally find this quite interesting. What I wonder is, if maybe
we have now reached a similar point of comp
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. Break
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
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
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 s
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.
>
>
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
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
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 clie
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
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 postfix/cleanup[141
13 matches
Mail list logo
