On 15 November 2017 at 02:03, Mark Milhollan wrote:
> On Tue, 14 Nov 2017, Brandon Long wrote:
>
>>Ugh, those timeouts are insane, from a different era.
>
> They might have been shortened by RFC 5321 (only 10 years ago), but
> weren't -- satellite can be terrible and links into disaster areas can
On 11/14/2017 06:03 PM, Mark Milhollan wrote:
satellite can be terrible and links into disaster areas can
be worse, not even counting personal or overloaded servers
Why are obvious problem links significantly influencing current standards?
If I were to stand up a link across such a hostile con
On Tue, 14 Nov 2017, Brandon Long wrote:
>On Tue, Nov 14, 2017 at 10:58 AM Renaud Allard via mailop
>wrote:
>>Actually, it's way more than that:
>> Initial 220 Message: 5 Minutes
>> MAIL Command: 5 Minutes
>> RCPT Command: 5 Minutes
>> DATA Initiation: 2 Minutes
>> Data Block: 3 Minutes. This is
I know that's what the guidance is, I firmly disagree with it.
A server that takes 10 minutes to process a normal size email message is
just plain overloaded, and there's no guarantee that it will even finish in
that time frame. Wasting your own resources waiting for the remote server
is often in
On 14 November 2017 at 23:18, Renaud Allard via mailop
wrote:
> On 14/11/2017 22:59, Brandon Long via mailop wrote:
>> Ugh, those timeouts are insane, from a different era.
>
> Taken straight out of RFC5321 tough, but yes, indeed, that RFC is from 2008.
That paragraph is unchanged from rfc2821, s
On 14/11/2017 22:59, Brandon Long via mailop wrote:
Ugh, those timeouts are insane, from a different era.
Brandon
Taken straight out of RFC5321 tough, but yes, indeed, that RFC is from 2008.
quote: "Based on extensive experience with busy mail-relay hosts, the
minimum per-command timeout
Ugh, those timeouts are insane, from a different era.
Brandon
On Tue, Nov 14, 2017 at 10:58 AM Renaud Allard via mailop
wrote:
>
>
> On 14/11/2017 16:51, Jeremy Harris wrote:
> > On 14/11/17 13:16, Vladimir Dubrovin via mailop wrote:
> >>
> >> Timeout after "." on smaller messages and in the m
On 14/11/2017 16:51, Jeremy Harris wrote:
On 14/11/17 13:16, Vladimir Dubrovin via mailop wrote:
Timeout after "." on smaller messages and in the middle of transmission
on large-size messages usually mean TCP connection issues, most common
reason is PMTUD blackhole router problem.
On any si
On 14/11/17 13:16, Vladimir Dubrovin via mailop wrote:
>
> Timeout after "." on smaller messages and in the middle of transmission
> on large-size messages usually mean TCP connection issues, most common
> reason is PMTUD blackhole router problem.
On any size message they can be due to a too-smal
