On Wed, Aug 10, 2022 at 04:00:51PM -0700, Marc MERLIN wrote:
> > I've also reached out to the Gmail team. They're aware. Which is not
> > to say that there's a quick fix in the works, the front-end connection
> > termination devices are both non-trivial and critical, so changes will
> > happen c
On Wed, Aug 10, 2022 at 06:46:16PM -0400, Viktor Dukhovni via Exim-users wrote:
> On Wed, Aug 10, 2022 at 11:17:43PM +0100, Andrew C Aitchison via Exim-users
> wrote:
>
> > On Wed, 10 Aug 2022, Marc MERLIN via Exim-users wrote:
> >
> > > On Wed, Aug 10, 2022 at 06:29:47PM +0100, Jeremy Harris vi
On Wed, Aug 10, 2022 at 11:17:43PM +0100, Andrew C Aitchison via Exim-users
wrote:
> On Wed, 10 Aug 2022, Marc MERLIN via Exim-users wrote:
>
> > On Wed, Aug 10, 2022 at 06:29:47PM +0100, Jeremy Harris via Exim-users
> > wrote:
> >> That's extremwly weird. I can't see a logical connection betwe
On Wed, 10 Aug 2022, Marc MERLIN via Exim-users wrote:
On Wed, Aug 10, 2022 at 06:29:47PM +0100, Jeremy Harris via Exim-users wrote:
That's extremwly weird. I can't see a logical connection between the
TCP startup detail and a problem that late in the SMTP conversation.
That was my thought to
On Wed, Aug 10, 2022 at 06:29:47PM +0100, Jeremy Harris via Exim-users wrote:
> That's extremwly weird. I can't see a logical connection between the
> TCP startup detail and a problem that late in the SMTP conversation.
That was my thought too, I don't get it.
> I'd love to hear from someone at
On 10 August 2022 17:12:55 BST, Marc MERLIN via Exim-users
wrote:
>> hosts_try_fastopen = !*.l.google.com
>>
>> into /etc/exim4/conf.d/transports/30_exim4-config_remote_smtp (or
>whichever
>> config the remote transport is in depending on how you have installed
>Exim
>> on Debian).
>
>Thank you
On Wed, Aug 10, 2022 at 11:21:31AM +0100, Graeme Coates via Exim-users wrote:
> This does sound something like this issue I blogged about:
> https://www.chromosphere.co.uk/2022/06/01/googles-tcp-fast-open-breaks-exim-
> delivery/
>
> The workround I have (so far!) successfully implemented with the
This does sound something like this issue I blogged about:
https://www.chromosphere.co.uk/2022/06/01/googles-tcp-fast-open-breaks-exim-
delivery/
The workround I have (so far!) successfully implemented with the same
version of Exim on Debian 11 is:
hosts_try_fastopen = !*.l.google.com
into /etc/
Hi all,
i use BATV for some time, it is done in remote transport by:
return_path = ${if def:return_path \
{${prvs{$return_path}{BATV_SIGNKEY}{BATV_KEYNUM}}}fail}
And it works (worked) as expected.
But recently i setup recipient callout, to catch failed recipients,
where i setup (bes
On 8/10/22 09:51, Andrew C Aitchison wrote:
the command, including any surrounding angle brackets.
Argh, RTFM :(
So $1 *does* include the opening "<" which is why you had to add the ">"
The rule
^([^<]*)@(.*)\\.olddomain\\.org $1@$2.newdomain.org TS
seems to work for me.
I still had
On Wed, 10 Aug 2022, Olaf Hopp (SCC) via Exim-users wrote:
On 8/9/22 17:54, Andrew C Aitchison wrote:
On Tue, 9 Aug 2022, Olaf Hopp (SCC) via Exim-users wrote:
[...]
You have:
^(.*)@(.*)\.olddomain\.org $1@$2.newdomain.org TS
The examples suggest that:
*@*olddomain.org $1@$2.newdo
11 matches
Mail list logo
