On Mon, May 18, 2020 at 10:38:14PM -0400, Viktor Dukhovni wrote:
> On Mon, May 18, 2020 at 09:37:36PM -0400, Rich Felker wrote:
>
> > > Mostly dig, unbound-host, ... Most of the platform C libraries support
> > > DO=1, which obviates the need for AD=1, so they don't do that, but it is
> > >
On Mon, 2020-05-18 at 13:50 -0400, Bill Cole wrote:
> In 30 years of working with Internet email, I have never seen any
> fully
> automated mechanism for making its delivery reliable in general,
> non-contracted cases.
...
> There is no virtual replacement for a physical process server. Maybe
On Mon, May 18, 2020 at 09:37:36PM -0400, Rich Felker wrote:
> > Mostly dig, unbound-host, ... Most of the platform C libraries support
> > DO=1, which obviates the need for AD=1, so they don't do that, but it is
> > nevertheless safe. AD=1 is much cheaper than DO=1, because you get back
> >
On Tue, Apr 14, 2020 at 05:59:51PM -0400, Viktor Dukhovni wrote:
> > > That RFC was published in 2013. That's long enough ago.
> >
> > We support environments that haven't been touched since 2009 or so,
> > and to a lesser/minimal-support extent ones that haven't been touched
> > since around
I solved it. The white space in front of the arguments had been removed so it
was reading them as an instruction that it could not understand. Replacing the
white space solved the issue thank you.
Geoff
+44 20 7100 1092
+44 7770 58 48 38
+33 5 46 97 13 89
+33 6 22 93 00 53
> On 17 May
On Mon, 18 May 2020 18:20:36 +0200, Jaroslaw Rafa stated:
>Dnia 18.05.2020 o godz. 11:50:53 yuv pisze:
>> discarded the message. It is one of the main reasons why we lawyers
>> continue to use fax transmission: the protocol is reliable, my fax
>> device receives the equivalent of a 250, I can
On 18 May 2020, at 11:50, yuv wrote:
To claim successful delivery and silently discard a message
is a lie.
A 250 reply to end-of-data is not a claim of final delivery. Even if
there's following text that seems to assert that the message is
delivered, it has always been true that one cannot
Dnia 18.05.2020 o godz. 11:50:53 yuv pisze:
> Thanks for the suggestion, Gerald. I was hoping for something more ...
> *honest*. To claim successful delivery and silently discard a message
> is a lie. The legal term is *misrepresentation* and I am eagerly
> waiting for the client coming through
Dnia 18.05.2020 o godz. 11:50:53 yuv pisze:
> discarded the message. It is one of the main reasons why we lawyers
> continue to use fax transmission: the protocol is reliable, my fax
> device receives the equivalent of a 250, I can rely on the fact that
> something has been delivered. Not
On Fri, 2020-05-08 at 09:51 +0200, Gerald Galster wrote:
> > > Below is the PCRE that I came up with to catch the offending
> > > messages,
> > > without blocking other correspondence (the contacts and their
> > > organizations are likely to use Google's SMTP for their regular
> > > emails):
> > >
Le 27/09/2019 à 17:01, Emmanuel Fusté a écrit :
Hello,
I started to deploy TLS connection reuse on some non trivial outboud
gateway setups.
First I was hit by an non obvious configuration behavior:
On my gateway I have:
smtpd_tls_security_level=none
smtp_tls_security_level=dane
If I switch
On 17.05.20 22:51, Geoff Jankowski wrote:
I am using postfix 3.4.8 on Debian 10 (hostname xerxes) and am trying to
set up my IPv6 interface on eth0. The last instruction in the guide is to
run:
service networking restart
But it fails to bring up the interface (which is working on IPv4). It
Postfix does not remove mail from the queue without logging it.
Without logs there will be no support. Seriously.
Systemd is great for losing logs while you're doing bulk mail. If
your system has systemd, consider using Postfix's maillog_file
feature instead. Again, Without logs there will be no
[An on-line version of this announcement will be available at
http://www.postfix.org/announcements/postfix-3.5.2.html]
Postfix versions 3.5.2, 3.4.12, 3.2.10, 3.2.15:
* A TLS error for a database client caused a false 'lost connection'
error for an SMTP over TLS session in the same Postfix
On 2020-05-17 12:07:29 -0600, @lbutlr wrote:
> > postfix/smtpd[17880]: connect from ...[...]
> > postfix/smtpd[17880]: SSL_accept error from ...[...]: -1
> > postfix/smtpd[17880]: warning: TLS library problem: error:1417A0C1:SSL
> > routines:tls_post_process_client_hello:no shared
> >
15 matches
Mail list logo
