headers
Peter Bowen | 5 Mar 2011 15:23
Picon

BINARYMIME clarification


In RFC 3030, the Binary Service Extension framework specifies one
extension that is required (CHUNKING) but does not have any other
dependencies explicitly listed.  However, it claims to extend the MAIL
BODY parameter defined in the 8BITMIME service extension, nothing that
the revised syntax allows for 7bit, 8bit, and binary options.

Does this mean that all servers that advertise BINARYMIME must accept
"8BITMIME" as a MAIL BODY parameter value?
Is it permissible to advertise the BINARYMIME keyword without
advertising the 8BITMIME keyword?

Second, the framework definition includes "can only be used with the
'CHUNKING' service extension".  I am trying to figure out how to
handle the situation where a server advertises BINARYMIME but not
CHUNKING (and not 8BITMIME).

Can the client set the MAIL BODY parameter, but must set it to "7BIT"?
Or does the client have to ignore the BINARYMIME keyword, as CHUNKING
is a dependency?

While these might seem like academic questions, a recent check of over
11000 SMTP servers found 381 that had the BINARYMIME keyword, of which
18 did not have CHUNKING and 13 did not have 8BITMIME.  Thankfully
none offered BINARYMIME without either of the other two keywords, but
I'm sure that some poorly configured servers do.  Half of the servers
that did not offer CHUNKING seem to behind overzealous filtering proxy
servers (as evidenced by the presence of XXXXXXXA type keywords),
while the other half appear to just be very confused SMTP servers.
(Continue reading)

Permalink | Reply | 1 comment |
headers
ned+ietf-smtp | 5 Mar 2011 17:32

Re: BINARYMIME clarification


> In RFC 3030, the Binary Service Extension framework specifies one
> extension that is required (CHUNKING) but does not have any other
> dependencies explicitly listed.  However, it claims to extend the MAIL
> BODY parameter defined in the 8BITMIME service extension, nothing that
> the revised syntax allows for 7bit, 8bit, and binary options.

> Does this mean that all servers that advertise BINARYMIME must accept
> "8BITMIME" as a MAIL BODY parameter value?

No, not unless the 8bitMIME extension is offered.

> Is it permissible to advertise the BINARYMIME keyword without
> advertising the 8BITMIME keyword?

It's permissible but given that 8bitMIME is a proper subset of BINARYMIME, not
very useful.

> Second, the framework definition includes "can only be used with the
> 'CHUNKING' service extension".  I am trying to figure out how to
> handle the situation where a server advertises BINARYMIME but not
> CHUNKING (and not 8BITMIME).

This, OTOH, is a standards violation. You have to offer CHUNKING
in order to offer BINARYMIME.

> Can the client set the MAIL BODY parameter, but must set it to "7BIT"?

As long as the message is actually 7bit. BUt if it is, since 7bit is
the default, why even bother with the BODY parameter?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane