Re: How do you manage the ‘hold’ queue?

On 26/01/2021 07:13, David Bürgin wrote: I’ve recently begun using the ‘hold’ queue, because of a milter that I use. A milter may ‘quarantine’ a message, which causes the message to be placed in the ‘hold’ queue (eg OpenDMARC does this when the DMARC policy requests quarantine). But how does

Re: How do you manage the ‘hold’ queue?

* David Bürgin : > I’ve recently begun using the ‘hold’ queue, because of a milter that I > use. A milter may ‘quarantine’ a message, which causes the message to be > placed in the ‘hold’ queue (eg OpenDMARC does this when the DMARC policy > requests quarantine). > > But how does one manage that

How do you manage the ‘hold’ queue?

I’ve recently begun using the ‘hold’ queue, because of a milter that I use. A milter may ‘quarantine’ a message, which causes the message to be placed in the ‘hold’ queue (eg OpenDMARC does this when the DMARC policy requests quarantine). But how does one manage that queue? I know that

Re: thunderbird problem after update to v.78.6

On Tue, Jan 26, 2021 at 07:46:01AM +0200, Tsakiridis Sotiris wrote: > Recently we've encounter a strange behaviour regarding thunderbird > (v78.6) and postfix 3.4.13 . Some clients can't recieve emails, some > others can't send and others have no problem at all!  I think it has > something to

thunderbird problem after update to v.78.6

Good morning Recently we've encounter a strange behaviour regarding thunderbird (v78.6) and postfix 3.4.13 . Some clients can't recieve emails, some others can't send and others have no problem at all!  I think it has something to do with SSL/TLS but I can't pinpoint the problem. Does

Re: 1st MX connection fails, 2nd successful

On Mon, Jan 25, 2021 at 10:38:46PM +0100, Jörg Backschues wrote: > # TLS > tls_high_cipherlist = > ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305 Limiting the ciphers

Re: 1st MX connection fails, 2nd successful

On Mon, Jan 25, 2021 at 10:38:46PM +0100, Jörg Backschues wrote: > can someone explain me why the 1st connection to the remote MX fails and > the 2nd connection is successful? Both delivery attempts fail to establish a TLS session on the first TCP connection. > Jan 25 21:14:56 mx00

Re: 1st MX connection fails, 2nd successful

J?rg Backschues: > Hello, > > can someone explain me why the 1st connection to the remote MX fails and Because the TLS handshake fails. > the 2nd connection is successful? Because the TLS handshake succeeds. :-) > Is this a kind of fallback? Yes. As required by the SMTP protocol standard,

1st MX connection fails, 2nd successful

Hello, can someone explain me why the 1st connection to the remote MX fails and the 2nd connection is successful? Is this a kind of fallback? Thank you very much. Jan 25 21:14:56 mx00 postfix/smtp[212676]: mxin.upcmail.net[213.46.255.45]:25: TLS cipher list