I do mind broken transports.
How big a problem is code 255 with MIME and ESMTP?
I agree that this is the key question regarding 255. The only problem I've ever
observed with 255 is that it acts an introducer to TELNET options negotiation.
The reason this is important is kind of obscure:
(1) Admins wanted to be able to TELNET to port 25 so they could test their
SMTP server.
(2) Early TELNET clients always did options negotiation regardless of the
destination port. (Modern ones only do option negotiation when connecting
to the TELNET port or if you explicitly ask for it on another port.)
(3) Rather than fix the clients, some SMTP server implementations opted to
support, and essentially ignore, options negotiations.
I haven't run into one of these in at least four years, but just because I
haven't seen one doesn't mean they are completely extinct. The usual symptom is
a message that contains random 8bit is sent without negotiation and causes the
SMTP server to hang in the middle of the DATA transaction.
On the other hand, we're only talking about servers that support the 8bitMIME
extension (we know that you're asking for trouble if you send unnegotiated 8bit
to anything else). I have NEVER seen a server that offers 8bitMIME support that
has this problem. Lacking any evidence to indicate that such a beast exists,
I'd say 255 should be considered safe in practice.
Ned