On 15 November 2017 at 02:03, Mark Milhollan <m...@pixelgate.net> 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 > be worse, not even counting personal or overloaded servers (as was > suggested, taking a while to scan content). General aviation crusing at > 100kts continues even while others fly or ride 5 times faster -- I see > similar in SMTP/networking/servers; hell a hundred-fold difference > probably exists between my home and your employer's datacenter yet > either of us can source or sink SMTP sessions -- I'd not need 10 minutes > to scan but it is nice that I am (they are) not required to run races > just because others can/do/must.
rfc5321 in "6.1. Reliable Delivery and Replies by Email" says: *To avoid receiving duplicate messages as the result of timeouts, areceiver-SMTP MUST seek to minimize the time required to respond tothe final <CRLF>.<CRLF> end of data indicator.* So the received MUST seek to minimize that response time. The sender, instead, SHOULD implement a timeout of 10 minutes. In rfc terms this mean you indeed ARE REQUIRED to run races. The client instead is not REQUIRED (they used SHOULD instead of MUST) to implement such long timeouts. Stefano > That being aside from what we actually > practice despite the rules (guidelines it sometimes seems). > /mark
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
