search

ietf-wg-emailcore / emailcore

3 stars 0 forks source link

G.7.12. Review Timeout Specifications #16

Closed ietf-svn-bot closed 1 year ago

ietf-svn-bot commented 3 years ago

keyword_SMTP owner:todd.herr@valimail.com type_task | by alexey.melnikov@isode.com

RFC 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

ietf-svn-bot commented 3 years ago

@alexey.melnikov@isode.com changed title from Review Timeout Specifications to G.7.12. Review Timeout Specifications

ietf-svn-bot commented 3 years ago

@alexey.melnikov@isode.com set component to smtp

ietf-svn-bot commented 3 years ago

@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.

ietf-svn-bot commented 3 years ago

@todd.herr@valimail.com changed status from new to assigned

ietf-svn-bot commented 3 years ago

@todd.herr@valimail.com set owner to todd.herr@valimail.com

ietf-svn-bot commented 3 years ago

@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.

ietf-svn-bot commented 3 years ago

@todd.herr@valimail.com commented

Ticket discussion opened on list on 23 February.

ietf-svn-bot commented 3 years ago

@todd.herr@valimail.com commented

No replies to list posting as of yet. Moving on to asking major mailbox providers what they think.

ietf-svn-bot commented 3 years ago

@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"

ietf-svn-bot commented 3 years ago

@alexey.melnikov@isode.com changed component from smtp to email-applicability-statement

ksmurchison commented 1 year ago

Per my IETF 114 notes, I believe that this ticket is going to be closed with no further work.