Am Dienstag, 22. Oktober 2019, 13:19:28 CET schrieb Hardy via Exim-users:
> I didn't change effectively anything, neither to cause nor to resolve
> the problems, and the sender sides were too many different ones as I
> would think it plausible they had a problem.
>
> Some of you in this list
Hi all,
I just want to let you know the situation normalized "all by itself",
and as far as I can judge no message was lost, as obviously the sender
part considered the problem a temporary one and we were still within
retry periods.
I didn't change effectively anything, neither to cause nor
Slowly mails from this afternoon roll in...
Hope my excitement is not too early, but whenever I happen to learn what
has been spooking there, I will let you know.
Thank for your head ups. Still would like to know what the hummus
server's log had to tell about the timeout.
On 18.10.19 16:15,
On 18/10/2019 23:29, Niels Dettenbach (Syndicat.com) via Exim-users wrote:
> - removed some DNSBL requests (shorten timing / eliminate some DNS reqs)
If there's a possibility of the receiving exim taking long enough to
cause the sender to give up (yet, in the OP's case, stop sending
data but not
> Am 18.10.2019 um 09:32 schrieb Hardy via Exim-users :
>
> Cyborg,
>
> you mean it really may happen that "all of a sudden" my kernel is not IP
> stack compatible with half of the other world?
Had a similar „effect“ since 4.92* with only a few out of hundreds MTAs
connecting to EXIM on our
On Fri, Oct 18, 2019 at 12:55:17PM +0200, Hardy via Exim-users wrote:
> Hi all,
>
> all of a sudden (after a reboot of the machine, but I cannot see a
> connection to that) exim produces a lot of
>
> data timeout on (message abandoned) on connection from mx.example.com [IP]
> F=
>
> in my logs.
Cyborg,
you mean it really may happen that "all of a sudden" my kernel is not IP
stack compatible with half of the other world?
Given, it is quite an old one, as I do not update productive systems
often, I prefer to build a new system and migrate - but not as often then.
But again, all of
Am 18.10.19 um 14:38 schrieb Jeremy Harris via Exim-users:
> On 18/10/2019 13:06, Hardy via Exim-users wrote:
>> And NOW:
>> 2019-10-18T13:56:03.718183+02:00 mailfass exim[4587]: SMTP data timeout
>> (message abandoned) on connection from hummus.csx.cam.ac.uk
>> [131.111.8.88] F=
>>
>> Perhaps
On 18/10/2019 13:06, Hardy via Exim-users wrote:
> And NOW:
> 2019-10-18T13:56:03.718183+02:00 mailfass exim[4587]: SMTP data timeout
> (message abandoned) on connection from hummus.csx.cam.ac.uk
> [131.111.8.88] F=
>
> Perhaps someone from your side may have look ;-)
Not our problem :)
> Few
Update
Jeremy, I saw your post via web. I do not even use check_data, it is
commented. In the check_rcpt I now added a condition-less "accept" VERY
early to mitigate effects of later rules. Problem persists.
And NOW:
2019-10-18T13:56:03.718183+02:00 mailfass exim[4587]: SMTP data timeout
Hi all,
all of a sudden (after a reboot of the machine, but I cannot see a
connection to that) exim produces a lot of
data timeout on (message abandoned) on connection from mx.example.com
[IP] F=
in my logs. These are always the same systems, that retry and fail
again. Other systems don't
11 matches
Mail list logo
