I am outlining an I-D that hopefully covers all of the main issues
discussed here regarding recent discoveries surrounding the concept of
"time" in SMTP and how it helped explains many of the long time
various issues that we had to observed and contend with over the years.
Hopefully, it can serve as a guide for better implementing SMTP, even
improve mail delivery, understand GOOD senders better and maybe serve
to help update SMTP. Although I realize there are folks who will
ignore this, but I feel confident (I have too, otherwise I need to
retire) there are those that can put aside the side-issues and feel
compel to contribute. So if you wish to comment here or in private
with your suggestions, that would be very helpful to getting the
widest input. I have unfortunately no faith it will go anywhere until
someone else authored it. So maybe it can be a starter for someone
else to take over the I-D, which would be my preference as long as
alienation is not the result.
Anyway, here is an initial draft outline (which can be reduced) for an
I-D, I have initially titled:
Issues and Enhancements for modern SMTP environments
Subtitle: Dealing with a good and bad mail senders.
(note the plurality of "modern SMTP environments")
(Keep in mind I am trying to do this as general as purpose)
o Background
o Traditional Mailer Designs
- Email vs Groupmail
- Immediate vs Delayed Scheduling, Delivery
o Timeouts
o Hold Times for new mail
- Mail Queuing
- Connection Sharing
o Purpose of Quit
o Extended SMTP Overhead issues
- TLS, AUTH
- DATA Filtering
o Scalability issues
o Increase resources
o Loading Limits
o Service Availability
o Socket TIME_WAIT state
o Understanding the TCP state machine
o Who closes first? Server or Client
o Port Reusability
o Recommendations
o Adhering to SMTP standards and recommendations
- High Efficiency
- High Throughputs
- Lower IDLE SMTP Waste
o Shorter Timeouts
- when allowing higher timeouts is "good" or "bad"
o Negotiated Bulk Mail exchanges
- Using current methods
- Ideas for new SMTP extensions
o How to use the QUIT command
o Recommended updates to RFC5321
--
Sincerely
Hector Santos
http://www.santronics.com