Closed ietf-svn-bot closed 1 year ago
@alexey.melnikov@isode.com changed title from Review Timeout Specifications
to G.7.12. Review Timeout Specifications
@alexey.melnikov@isode.com set component to smtp
@alexey.melnikov@isode.com commented
Hector wrote:
On a related note (maybe another issue?), only a few mailers sit after an DATA transaction holding the socket until something else comes in to start a new transaction. We had this discussion before, many years ago, and I decided to knock them out with a shorter timeout (PostDataTimeoutSecs=35 secs) after a DATA transaction because they were taking up resources setting there doing nothing for an extended time. In other words, we discussed the Timeout values and they are fine, but I felt the 5 mins was too long after the DATA transaction when certain mailers sit there and not send anything. I believe this is a permission concept to allow a client to just hold a server session, socket, process, resources, etc. When there are incoming loads limits, it doesn't help to have one client to hold a line.
@todd.herr@valimail.com changed status from new
to assigned
@todd.herr@valimail.com set owner to todd.herr@valimail.com
@todd.herr@valimail.com commented
I agree that it's worth revisiting the values in section 4.5.3.2. Since 4.5.3.2 says " Based on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows:", it's worth engaging people with current experience at mailbox providers of varying sizes to get their input on what the numbers should be.
@todd.herr@valimail.com commented
Ticket discussion opened on list on 23 February.
@todd.herr@valimail.com commented
No replies to list posting as of yet. Moving on to asking major mailbox providers what they think.
@todd.herr@valimail.com commented
Discussion at IETF 110 (https://codimd.ietf.org/notes-ietf-110-emailcore) seemed to land on "Leave 5321 alone, but maybe add something to the Applicability Statement"
@alexey.melnikov@isode.com changed component from smtp
to email-applicability-statement
Per my IETF 114 notes, I believe that this ticket is going to be closed with no further work.
keyword_SMTP
owner:todd.herr@valimail.com
type_task
| by alexey.melnikov@isode.comRFC 5321 (and its predecessors going back to 821) specify minimum periods for client and server to wait before timing out. Are those intervals still appropriate in a world of faster processors and faster networks? Should they be updated and revised? Or should more qualifying language be added?
Issue migrated from trac:16 at 2022-01-31 12:34:30 +0000