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 incorrect.
When the p90 for delivery with a new connection is on the order of 5s, having an entire delivery take 30 minutes is laughable. Considering it just down at that point is basically a rounding error. Having those limits be the "standard" limits in a server these days is a good way to turn some types of remote server outages into local server outages, you can have your queuing try to handle that type of head of line blocking, but you can waste significant resources when the service goes from 5s to 30m just in the time it takes to detect the phase change. Brandon On Tue, Nov 14, 2017 at 2:25 PM Renaud Allard via mailop <mailop@mailop.org> wrote: > > > 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 values SHOULD be as follows"... > > Note that those values SHOULD be the minimum ones :) > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
