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
hotm
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 st
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 re-tryi
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
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/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
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 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
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
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 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
11 matches
Mail list logo
