Re: TCPIP$SMTP_MIME_HACK
- From: briggs@xxxxxxxxxxxxxxxxx
- Date: 2 Apr 2007 07:33:43 -0500
In article <euob23$ga7$1@xxxxxxxxx>, helbig@xxxxxxxxxxxxxxxxxxxxxxxx (Phillip Helbig---remove CLOTHES to reply) writes:
$! TCPIP$SMTP_MIME_HACK
$! When set, SMTP accepts 8BITMIME requests from SMTP clients,
$! preventing the clients from converting the message into a 7-bit
$! format.
$!
$!DEFINE/SYSTEM TCPIP$SMTP_MIME_HACK 1
What exactly does this do?
A quick web search turns up RFC 1652 which defines an ESMTP extension
using the keyword "8BITMIME".
Background...
Classically, SMTP (RFC 821) is a 7 bit transport mechanism. It is not
supposed to be able to handle 8 bit messages. If you want to pump 8
bit messages down a 7 bit pipe you need to encode them.
Clasically, MIME (RFC 2045 et al) provides three mechanisms to handle
8 bit messages. You can encode them Quoted-Printable. You can encode
them BASE64. Or you can pump them down an 8-bit safe pipe.
But since SMTP isn't 8-bit safe, you're stuck with one of the two
encodings.
RFC1652 defines an ESMTP (RFC 1869) extension to allow an SMTP client
and server to negotiate an 8-bit safe pipe.
Details...
When an ESMTP client connects to an ESMTP server it will open up
the dialogue with:
EHLO client.host.name
This is, of course, the standard ESMTP greeting. If the server is
ancient and only understands SMTP the client would fall back to the
older "HELO client.host.name" greeting instead. But we're talking
ESMTP here.
The server will respond with something that lists the ESMTP options that
it is willing to negotiate. For instance:
250-server.host.name Hello [192.168.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 HELP
Note the "250-8BITMIME" there. This advertises that the server
understands and is willing to use the 8 bit MIME extension.
In the absence of this advertisement, the server is expected to be able to
accept only messages encoded in 7 bit ASCII. The client is expected
to encode 8 bit messages accordingly. If the sending user agent has not
already done QUOTED-PRINTABLE or BASE64 encoding on the message, the
SMTP client is now stuck with that task. [Which is arguably an abuse
of protocol layering, but that's neither here nor there].
In the presence of this advertisement, the client can request its use
with, for instance:
MAIL FROM:<sender-name@xxxxxxxxxxxxxxxxxx> BODY=8BITMIME
and the server can accept this with
250 <sender-name@xxxxxxxxxxxxxxxxxx> Sender and 8BITMIME ok
So setting
$!DEFINE/SYSTEM TCPIP$SMTP_MIME_HACK 1
causes the VMS SMTP receiver to [at least pretend to] be able to
receive 8 bit SMTP traffic. It will advertise its willingness in
the greeting response. And it will accept the option on the
MAIL FROM: line that it parses.
Mind you, I've never used the option and I don't know if there are any
restrictions on the ability of the VMS smtp server to properly handle
8 bit message bodies. But this is the apparent meaning of the logical name.
.
- Follow-Ups:
- Re: TCPIP$SMTP_MIME_HACK
- From: Phillip Helbig---remove CLOTHES to reply
- Re: TCPIP$SMTP_MIME_HACK
- References:
- TCPIP$SMTP_MIME_HACK
- From: Phillip Helbig---remove CLOTHES to reply
- TCPIP$SMTP_MIME_HACK
- Prev by Date: Re: Purveyor and Auth DLL
- Next by Date: Re: Purveyor and Auth DLL
- Previous by thread: TCPIP$SMTP_MIME_HACK
- Next by thread: Re: TCPIP$SMTP_MIME_HACK
- Index(es):
Relevant Pages
|
