[ih] Design choices in SMTP

[Dave Crocker]

On 2/7/2023 8:00 AM, Ralph Holz via Internet-history wrote:
> Hi everyone,
>
> During a lecture today, the following question came up: SMTP requires quite
> a few round-trips to deliver an email. Why was this design choice made,
> i.e., why does a submitting client not just send everything to the server
> in one RTT?

1. Save bandwidth -- in 1982, that matter a lot more than it does today, 
but even today, not all transactions are across extremely high bandwidth 
paths.

2. Save server capacity


> Apart from the client-server philosophy at play, I am wondering if that was
> because we wanted a receiver to terminate the delivery process as early as
> possible, i.e., before sending the body, if anything was amiss.

Yes.


> Does anyone have insights on that or maybe even know a nice write-up? I
> checked a few sites that discuss the history of SMTP, but so far no luck
> with this aspect.

Eventually there was enough motivation to have a transaction be 
conducted in a batched fashion:

The Batch SMTP  Media Type

datatracker.ietf.org

RFC ft-freed-bsmtp: The Batch SMTP Media Type <#>

The Batch SMTP Media Type (RFC 2442, November 1998

🔗 https://datatracker.ietf.org/doc/html/rfc2442 
<https://datatracker.ietf.org/doc/html/rfc2442>

Shortly after that, the capability to pipeline the transaction over an 
SMTP connection was developed.  This does not change the nature of the 
connection, but removes most of the latency delays to the session.

    SMTP Service Extension for Command Pipelining

www.rfc-editor.org

RFC 2920: SMTP Service Extension for Command Pipelining <#>

🔗 https://www.rfc-editor.org/rfc/rfc2920 
<https://www.rfc-editor.org/rfc/rfc2920>

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker at mastodon.social