On Wed, Sep 02, 2020 at 11:11:32PM -0400, Bill Cole wrote:
> > For the domain above, I am able to resolve the TLSA RRs via my
> > resolver.
>
> Able to resolve the non-existence, yes. Me too.
See below.
> Yes, I see the same:
>
> [root@be03 ~]# dig @127.0.0.1 _25._tcp.mail.deaecom.gov. tlsa
Le mercredi 02 septembre 2020 à 23:11 -0400, Bill Cole a écrit :
> On 2 Sep 2020, at 19:58, Viktor Dukhovni wrote:
> > On Wed, Sep 02, 2020 at 07:09:28PM -0400, Bill Cole wrote:
> I do not understand why Postfix didn't see that as a reason to give
> up
> on DANE.
>
> There's a local instance of
On 2 Sep 2020, at 19:58, Viktor Dukhovni wrote:
On Wed, Sep 02, 2020 at 07:09:28PM -0400, Bill Cole wrote:
I had a message defer indefinitely, ostensibly due to the lack of a
TLSA
record,
No, not the lack of it, but rather inability to verify presence or
lack of it in a downgrade-resistant
On 2020/08/31 22:39, Wietse Venema wrote:
kawakami:
And this problem occurs NOT always, only in following situatision,
2, A message was sent on IPv4, but resuted 451 error.
3, A message was sent on IPv6, but resuted 451 error.
After a 4xx error, the SAME Postfix SMTP client process may
IMME
On Wed, Sep 02, 2020 at 07:09:28PM -0400, Bill Cole wrote:
> I had a message defer indefinitely, ostensibly due to the lack of a TLSA
> record,
No, not the lack of it, but rather inability to verify presence or
lack of it in a downgrade-resistant manner. DANE being a defense
against active atta
I had a message defer indefinitely, ostensibly due to the lack of a TLSA
record, which seems like a poor excuse. I expect this indicates that
there's something I don't get about DANE and/or specifically
"smtp_tls_security_level = dane" in Postfix. I seek enlightenment.
Indeed there was and is
TL;DR: programs that receive email from the Postfix pipe daemon
should not produce large amounts of output.
When Postfix logs output from a pipe-to-command delivery, there are
three output limits in effect:
- The capacity of a UNIX pipe. The pipe daemon does not read any
command output until AFTE
On Tue, 1 Sep 2020 14:03:12 -0400
Viktor Dukhovni wrote:
> On Tue, Sep 01, 2020 at 04:39:48PM +0200, Souji Thenria wrote:
>
> > To be more detailed:
> > In my case I have two servers, and I want one to recieve mails and the
> > other should only send mails. So I installed postfix on both servers
Hi,
we're using a custom python3 mail filter since ages here, but today, we
stumbled across a strange behavior, that I cannot explain.
First some environment specifications: Postfix 3.4.7/Python3.6.10 running on
OpenSUSE Leap 15.2.
The filter adheres to the simple filter "specification" from
On Wed, Sep 02, 2020 at 01:16:43PM +0100, Nick wrote:
> > If you want to prevent bounces from leaking out to forged sender
> > addresses you need to accept and discard messages, rather than reject
> > them.
>
> instead of this -
>
> -o { smtpd_sender_restrictions =
> check_sender_acce
On 2020-09-02 01:02 BST, Viktor Dukhovni wrote:
> No, I am not talking about mail not being delivered, I am talking
> about Postfix no longer working properly.
Thanks. Could you please expand on (from your earlier mail) how to do
this -
> If you want to prevent bounces from leaking out to forged
11 matches
Mail list logo
