Negotiate ESMTP extensions

SMTP is from 1982. It still works today because it learned to grow without breaking. The mechanism is ESMTP, Extended SMTP, and you already met it: the list of 250- lines a server sends after EHLO.

Each line is an extension the server supports. The base protocol never changes. New features are opt-in, and only when both sides agree.

The extensions you’ll meet most

SIZE declares the largest message the server accepts. 8BITMIME allows bodies with 8-bit bytes instead of forcing everything into 7-bit ASCII. SMTPUTF8 allows international addresses like josé@flaviocopes.com and UTF-8 headers. PIPELINING lets the client send several commands without waiting for each reply.

The rule is strict. If the server didn’t advertise an extension, the client must not use it. It needs a fallback, or it must report that this message can’t be sent as written.

Capabilities change what goes on the wire

Here the server advertised three extensions, so the client uses two of them in MAIL FROM:

S: 250-SIZE 10485760
S: 250-8BITMIME
S: 250 SMTPUTF8
C: MAIL FROM:<josé@flaviocopes.com> SMTPUTF8 SIZE=2381

Take SMTPUTF8 away and the non-ASCII address becomes impossible in this transaction. Changing the visible From header wouldn’t help. The problem is the envelope address, and the envelope is what MAIL FROM carries.

Take 8BITMIME away and the client has to encode the body into 7-bit form (quoted-printable or base64) or pick another route.

SIZE is a courtesy that saves bandwidth. If the server says 10 MB and my message is 25 MB, the client knows before sending a single byte of content.

PIPELINING changes timing, not meaning

Without pipelining, every command is a round trip. With it, the client can send MAIL FROM, two RCPT TO, and DATA in one burst, then read the replies in order.

The commands mean exactly the same thing. The client still has to match each reply to its command, and stop correctly if one fails. And it must not pipeline commands the extension forbids, like EHLO or STARTTLS.

Extensions are hop by hop

This one bites people. My provider’s submission server supports SMTPUTF8. That says nothing about Sara’s server. Each SMTP hop negotiates on its own.

So my provider, sitting in the middle, has a choice when the next server lacks an extension: transform the message so it fits, or fail visibly and bounce it. Silently mangling it is the one thing it must not do.

Try this: remove SMTPUTF8 from the capability list above. Write down which line of the transaction becomes invalid, and why fixing the From header alone wouldn’t help.