🚀 go-pugleaf

I would hope that words within a protocol are exempt.  If things are done
right (which they aren't with SMTP but are with VAXMAIL and the various X.400
mailers) the user should never have to see the actual keywords associated with
the components of a mail packet.

Using VAXMAIL as an example, since you did, there are translated versions of
both the character cell and the DECwindows versions of that mailer.  These
present all prompt in the language of the UI.  They even do things like use
the locale specific equivalent of RE: and FWD: when generating the subject
line for a reply or a forward.  The normal approach here is to leave the
display of strings for Date, From, Subj, etc. to the display program and
not to encode them in the message.  Things like RE: in the subject line will
be in to language of the sender.

As far as things like SMTP, you run into a problem there because the header
information is in formatted plain text and most mailers allow the user direct
access to that text, rather than parsing it and hiding behind translated UI.
The other, much more serious problem that you run into is that SMTP is based
on MAIL-11, which is a 7bit protocol.  As such, you are prevented from using
ISO8859-1 for European mail and get forced into either 7 bit local character
set or working around the lack of accents by using stupid formats like Gr"u"se.
If you are working within a corporation or between 2 corportations with an
agreement to use the 8 bit extension to MAIL-11 you can get around that.
All of the above applies to NNTP as well.

In any case, I would not try to translate SMTP or NNTP anymore than I would
try to translate the term ASCII.  These are, as far as I know, international
acronyms and should be left alone.

Dick