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
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
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
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
Hey list!
Does anyone have an email admin contact for dhl.com (or .de given the RTT I'm
seeing from their MTA)
Having a problem with one of their MTA's not DKIM signing emails and these
emails are getting rejected by my client's mailbox provider because dhl.com's
DMARC is set to REJECT. These
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
On Tue, 2017-11-14 at 10:05 +0100, David Hofstee wrote:
> I agree that it is a problem. I do think this could be done at connection
> time only. Of of the tricky parts is that all mail servers I know have
> trouble with throttling.
[...snip...]
Traditional MTAs often respond by queuing and
I agree with Ken that the need for guidelines is well intended. Many legitimate
senders want to avoid pushing too hard and wasting resources on both ends. But
I think exchanging specific limits between receiver and sender via a new
mechanism is infeasible, and may not even be needed.
Why not
Hi Ken,
I agree that it is a problem. I do think this could be done at connection
time only. Of of the tricky parts is that all mail servers I know have
trouble with throttling. They can throttle on a (set of) recipient
domain(s), but not on a cluster of MXs from e.g. Microsoft. E.g. they put
10 matches
Mail list logo