Bruce Lilly | 3 May 18:30 2003
Picon

MICALG registry?


RFC 1847 provides for a required micalg parameter with a
multipart/signed composite media type. But 1847 lists no
values for that parameter, nor does it refer to any sort
of registry of values for it.

RFC 3335 makes use of the micalg parameter and defines
two initial values, md5 and sha1.  But again there's no
mention of any registry or registration procedure for
micalg values.

The closest thing to a registry that I could find is
http-dig-alg, but that's HTTP-specific.

Is there a micalg registry?

Bruce Lilly | 3 May 20:24 2003
Picon

More micalg oddities


RFC 1847 again, section 2.1:

    The attribute token for the micalg parameter is "micalg", i.e.,

     parameter := "micalg" "=" value

    The Message Integrity Check (MIC) is the name given to the quantity
    computed over the body part with a message digest or hash function,
    in support of the digital signature service.  Valid value tokens are
    defined by the specification for the value of the protocol parameter.
    The value may be a comma (",") separated list of tokens, indicating
    the use of multiple MIC algorithms.  As a result, the comma (",")
    character is explicitly excluded from the list of characters that may
    be included in a token used as a value of the micalg parameter.  If
    multiple MIC algorithms are specified, the purpose and use of the
    multiple algorithms is defined by the protocol.

That seems rather odd, as "value" is not defined specifically for the
micalg parameter, and the definition immediately preceding the quoted
text (for value as used in the protocol parameter) doesn't seem to be
applicable. "token" is mentioned in the text, and Content-Type header
field parameter values are specified in RFC 2045 as amended by RFC 2231.
The really odd part is that the quoted text above mentions that the
value can be a comma-separated list and mentions excluding comma. But
comma is in the list of tspecials defined in RFC 2045, and therefore
can never be part of a "token" and cannot appear unquoted (and unencoded)
in a parameter value.

So,
(Continue reading)

ned+ietf-822 | 3 May 23:54 2003

Re: More micalg oddities


> RFC 1847 again, section 2.1:

>     The attribute token for the micalg parameter is "micalg", i.e.,

>      parameter := "micalg" "=" value

>     The Message Integrity Check (MIC) is the name given to the quantity
>     computed over the body part with a message digest or hash function,
>     in support of the digital signature service.  Valid value tokens are
>     defined by the specification for the value of the protocol parameter.
>     The value may be a comma (",") separated list of tokens, indicating
>     the use of multiple MIC algorithms.  As a result, the comma (",")
>     character is explicitly excluded from the list of characters that may
>     be included in a token used as a value of the micalg parameter.  If
>     multiple MIC algorithms are specified, the purpose and use of the
>     multiple algorithms is defined by the protocol.

> That seems rather odd, as "value" is not defined specifically for the
> micalg parameter, and the definition immediately preceding the quoted
> text (for value as used in the protocol parameter) doesn't seem to be
> applicable. "token" is mentioned in the text, and Content-Type header
> field parameter values are specified in RFC 2045 as amended by RFC 2231.
> The really odd part is that the quoted text above mentions that the
> value can be a comma-separated list and mentions excluding comma. But
> comma is in the list of tspecials defined in RFC 2045, and therefore
> can never be part of a "token" and cannot appear unquoted (and unencoded)
> in a parameter value.

Oh please, this isn't rocket science. Surely it is obvious that multiple hash
(Continue reading)

dhananjay | 14 May 04:58 2003

Regarding 8bitMIME support ...


Hi,
    I am working on enhancing MTA to support SMTP extensions (especially 8
bit MIME support). I am not clear about following issue :

    If remote MTA does not support 8bit MIME, then the sender MTA should
convert message from 8 bit to 7 bit and send the message. Now, there can be
3 approaches (apart from perm error NDR generation) that I am aware of :
    1. The sender MTA should first convert whole message to original
encoding (octet stream), and then apply base 64 encoding on that to get 7
bit. But, this seems to be very length procedure and tedious processing.

     2. The sender MTA should apply quoted-printable encoding (one can use
even base64 encoding also .. as final aim is 7bit output ?) directly on 8
bit MIME message. But, then we lose track of original message format
(say,octet stream). And, mail clients trying to retrieve message from this
remote MTA will not be able to get original message format (octet stream).
They will be able to decode the message to 8bit MIME, but not from 8 bit
MIME to octet stream (original message format), as we have lost track of
octet stream -> 8bit MIME encoding.

    3. The sender MTA should apply either quoted printable or base 64
encoding on whole message (except original headers), and send that as
attachment to original headers. But, this means, user will get original
message as a attachment.

     Now, I am not able to make out whether my approaches are right and
which way to go ?

Regards,
(Continue reading)

Adam M. Costello | 14 May 06:57 2003

Re: Regarding 8bitMIME support ...


dhananjay <dhananjay <at> zlemail.com> wrote:

> If remote MTA does not support 8bit MIME, then the sender MTA should
> convert message from 8 bit to 7 bit and send the message.  Now, there
> can be 3 approaches (apart from perm error NDR generation) that I am
> aware of :
>
> 1. The sender MTA should first convert whole message to original
> encoding

For the five content-transfer-encodings defined by RFC 2045, this is
a no-op.  (For 8bit or binary, the conversion is just the identity
function, which is a no-op.  For 7bit, base64, or quoted-printable, the
message doesn't need 8BITMIME anyway, so just send it.)

I guess you must be concerned about how to handle other
content-transfer-encodings, besides the five defined in RFC 2045.  In
that case, I guess you're right, you need to undo it and then apply an
encoding that yields a 7bit output (like base64 or quoted-printable).

Perhaps this suggests that any new content-transfer-encoding that
produces 8bit output should be co-designed with a 7bit sibling, so that
there would be a shortcut from one to the other.  For example, maybe
the 8bit version should limit its line length to 747 bytes rather than
998, so that the 7bit version could be the same thing except that each
line is base64-encoded.  Then it would be easy to convert directly from
either one to the other.

AMC
(Continue reading)

Keith Moore | 15 May 05:33 2003
Picon

Re: Regarding 8bitMIME support ...


first, you cannot simply encode the entire message in quoted-printable or
base64.  each component of a message/rfc822 or multipart/* body part must be
considered separately.

you should not re-encode a body part which is already 7-bit compatible
(i.e. you should not re-encode a 7bit, quoted-printable, or base64 body part)

a binary or 8bit body part should be re-encoded.  as a rule of thumb,
if the content-type is text/* you can use quoted-printable; otherwise,
use base64. 

Keith

p.s. these days almost all SMTP servers can deal with 8bit message bodies (NOT
headers) even if they don't advertise the 8bitmime extension.  so there are at
least a few  implementations that just send 8bitmime messages without
converting, and they mostly seem to get away with it.  it's certainly a lot
simpler, and these days, it may even be less error-prone.  it's easy to write
an 8-bit to 7-bit converter that corrupts messages.

> Hi,
>     I am working on enhancing MTA to support SMTP extensions (especially 8
> bit MIME support). I am not clear about following issue :
> 
>     If remote MTA does not support 8bit MIME, then the sender MTA should
> convert message from 8 bit to 7 bit and send the message. Now, there can be
> 3 approaches (apart from perm error NDR generation) that I am aware of :
>     1. The sender MTA should first convert whole message to original
> encoding (octet stream), and then apply base 64 encoding on that to get 7
(Continue reading)

dhananjay | 15 May 08:25 2003

Re: Regarding 8bitMIME support ...


Hi Keith,
     Thanks a lot for reply.
     First of all, I can not get away with 7bit email servers by sending
8bit to them. I have to convert.

     So, I would need to convert each body part separately, based on its
CTE, and definitely I would need to choose between QP and base64 based on
the thumb rule as you specified.

      Now, consider a scenario where a mail client (supporting 8bit) sends
an email with a binary-converted-to-8bit attachment to my MTA, A. My MTA
connects to non-8bit remote MTA, B. Now, my MTA converts attachment from
8bit to base64, and sends it.
      Given this, when any mail client connects to MTA B, it downloads the
attachment and applies base64 conversion. Now, will that client be able to
retrieve original binary attachment, OR it will get 8bit attachment ?

       Also, could you please point out some mail clients dealing 8bit. I
could not find 8bit CTE configuration setting in outlook. It has just base64
and QP options.

       Any help is most appreciated.

Regards,
Dhananjay.

----- Original Message ----- 
From: "Keith Moore" <moore <at> cs.utk.edu>
To: "dhananjay" <dhananjay <at> zlemail.com>
(Continue reading)

Adam M. Costello | 15 May 09:32 2003

Re: Regarding 8bitMIME support ...


dhananjay <dhananjay <at> zlemail.com> wrote:

> Now, consider a scenario where a mail client (supporting 8bit) sends
> an email with a binary-converted-to-8bit attachment
>
> Also, could you please point out some mail clients dealing 8bit.

Do you understand that currently there is no binary-to-8bit
conversion registered in the transfer-encoding registry
(http://www.iana.org/assignments/transfer-encodings)?  There is a draft
for deflate-8bit (draft-freed-mime-newenc-00), but I would be surprised
if any mail clients implemented it already, since it's likely to change.

Currently, the only standard way to get an 8bit message body is for the
body to originate as 8bit (for example, plain text in almost any charset
except ASCII); there is no standard conversion from binary to 8bit.

AMC

Arnt Gulbrandsen | 15 May 09:57 2003
Picon

Re: Regarding 8bitMIME support ...


Keith Moore writes:
> p.s. these days almost all SMTP servers can deal with 8bit message 
> bodies (NOT headers) even if they don't advertise the 8bitmime 
> extension.  so there are at least a few  implementations that just 
> send 8bitmime messages without converting, and they mostly seem to 
> get away with it.  it's certainly a lot simpler, and these days, it 
> may even be less error-prone.  it's easy to write an 8-bit to 7-bit 
> converter that corrupts messages.

Spammers just-send-8. In this day and age, it probably is a bad idea to 
do what spammers do: So many people are fed up and will filter on 
anything that looks good, just to get rid of some spam.

I noticed that stock postfix can filter on just-send-8 now.

--Arnt

Keith Moore | 15 May 14:41 2003
Picon

Re: Regarding 8bitMIME support ...


>       Now, consider a scenario where a mail client (supporting 8bit) sends
> an email with a binary-converted-to-8bit attachment to my MTA, A. My MTA
> connects to non-8bit remote MTA, B. Now, my MTA converts attachment from
> 8bit to base64, and sends it.
>       Given this, when any mail client connects to MTA B, it downloads the
> attachment and applies base64 conversion. Now, will that client be able to
> retrieve original binary attachment, OR it will get 8bit attachment ?

nothing should ever be converting from binary to 8bit.  the only reason
to convert from binary to anything is when sending to a 7-bit-only MTA;
and then you have to use base64 or q-p.  one reason you don't convert to
8bit (or for that matter 7bit) is that neither 8bit nor 7bit can represent
all octet values.  8bit and 7bit were not really intended as encodings,
they were intended as a way to mark unencoded text.  these days everyone
supports MIME so there's not as much need to transmit unencoded text.

even assuming there were a binary-to-8bit converter, it would only make
sense for text objects that used short lines and CRLF line endings.

>        Also, could you please point out some mail clients dealing 8bit. I
> could not find 8bit CTE configuration setting in outlook. It has just base64
> and QP options.

I don't know of any.  I don't think 8bit is used very often.

Keith


Gmane