Erlang gen_statem permits you to postpone an event, putting it in a queue that's retried after the next state change (before moving to new events). So the MAIL FROM would put you in handle_mail_from state, and while you're in it you postpone any RCPT TOs.

Of course this might be a dumb example in this case because the process mailbox will do the right thing and be a queue if you just blockingly make the dns request in your handler process. (It also might not be, I don't know enough about the smtp state machine to say.)

SMTP pipelining was actually the cause of fairly recently discovered vulnerability. https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-... https://www.postfix.org/smtp-smuggling.html

Probably the main reason it is recommended against.

>The vulnerability was introduced many decades ago in Sendmail, by allowing the non-standard <LF> line ending in addition to the standard <CR><LF>. For compatibility with programs that expect Sendmail behavior, the non-standard <LF> line ending was also allowed by other SMTP servers including Postfix and Exim.

Sendmail, just say no.

Java's virtual threads really seem like the correct solution to this problem. Each SMTP connection would get its own reader thread, and would spawn a DNS query thread and synchronously wait on it until the response comes back.

I think it's more likely that it's caused by lack of read buffering in early implementations. The function that reads an SMTP command just reads whatever it can get from the kernel. If the connection is half-duplex as expected (following the one command, one response pattern), there will only ever be one SMTP command in the buffer after the read returns. With pipelining, that is no longer true, and the implementer has to figure out how to do proper buffer management.

(I don't why this is not mentioned in RFC 2920.)

> So now we rejected the MAIL FROM command and accepted the incorrectly addressed RCPT TO.

Which is the incorrectly addressed RCPT TO and why is it so?