Re: [exim] syscall: Broken pipe (outlook.com)

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: MRob
Dátum:  
Címzett: exim-users
Régi témák: Re: [exim] syscall: Connection reset by peer (outlook.com)
Tárgy: Re: [exim] syscall: Broken pipe (outlook.com)
>>>> is it important to say this disconnect seems to happen before mail
>>>> transmission, yes, probably after "250 OK"


Correction, in this case, some time later because it is showing some
info about the message

>>>> I'm getting lots of these in exim log:
>>>> 2021-02-25 04:31:15.790 [19189] SSL_write: (from
>>>> mail-pu1apc01hn2214.outbound.protection.outlook.com (APC01-PU1-
>>>> obe.outbound.protection.outlook.com) [52.100.183.214]:42879)
>>>> syscall:
>>>> Connection reset by peer
>
>> I found this situation because single user forwarded microsoft bounce
>> message to their user said:
>>
>> Generating server: AM6PR05MB6309.eurprd05.prod.outlook.com
>> Total retry attempts: 26
>>
>> user@???
>> Remote Server returned '550 5.4.300 Message expired -> 451 Temporary
>> local problem - please try later'
>>
>> So checking my log I found the last attempt to deliver this message
>> resulted in this situation where outlook.com immediately dissconnected
>> (its how I learned about this "connection reset").
>
> The question is: did your exim log a message acceptance (a "<=" line) ?
>
> If so, this 451 is definitively their problem. On the other hand, if
> your
> system had logged several "Temporary reject" lines referencing this
> user
> and outlook, it is your problem (and separate from the TCP RST issue).


Does not log either one. In one case, the transation ended with "SMTP
command timeout on TLS connection", on the next attempt, transaction
ended with "SSL_write: ... syscall: Broken pipe"

So I guess outlook.com server is disconnection because it is impatient
or something? I make a mistake that this problem was not "Connection
reset by peer" (only that I noticed those log message when investigating
this situation). I see other "broken pipe" errors from outlook.com but
not nearly as many.