[Top] [All Lists]

Re: [ietf-smtp] smtp extension model

2019-02-12 09:25:07
On 2/12/2019 6:13 AM, Alessandro Vesely wrote:

On Fri 08/Feb/2019 19:15:12 +0100 John C Klensin wrote:

FWIW, I personally believe that it would be a good idea to completely
reorganize and rewrite 5321 because the process by which we folded 821, some
topics covered by 1123, and the extensions work together created a document
that is hard to follow as well as being too long.

It's here that I find it difficult to follow your reasoning.  Yeah, it would be
a fascinating idea, but would it also be a practical task to pursue?

I think so.

RFC1123 was my "holy bible" for internet hosting. It was an extremely useful consolidated guide at the time for the early internet integrated hosting servers developers of FTP, TELNET and SMTP.

I think we need something like it again, at least for SMTP. Take a look at RFC1123 section 5.4. SMTP REQUIREMENTS SUMMARY and similar tables for the other protocols. These were so unbelievable helpful as a quick reference guide. We need another modern summary like this again. I think most seasoned developers just want to know the "protocol rules" and not waste time with historical design reasoning notes. Implementators trust the cogs, who help write/mold the specs, are doing the right (IETF) engineering thing so just give us the MAY, SHOULD and MUST protocol product design rules.

RFC5321+ could be a reduced technical reference guide with straight forward state machine protocol and prototyping notes for both pure SMTP and ESMTP with add-ons such as ESMTP AUTH, STARTTLS, 8BITMIME, etc Summary (Extended) Requirements/BCP Tables would be very helpful.

I wouldn't want to add anything new unless we wanted to add a section on "Mail Filtering and Load Controls" concepts which has probably been the biggest things since 2003 done with SMTP as developers began to add these features to their implementations in order to help customers were were getting hit hard with the unprotected return path spoofs and unsolicited spam. Add-ons like GreyListing, SPF, DKIM and DKIM-based Domain Policy methods would be part of such a section discussion of the filters available. The biggest thing here would be the shift of real-time processing to the DATA state which had added significant session time overhead. But improved hardware has trumped those early performance concerns, so in general, we can do more with E/SMTP today than ever before.

I also agree that RFC5322+ should maybe be done at the same time, but not necessarily as a show stopper if IETF WG work for only RFC5321+ can be allocated.


ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>