Ken wrote:
> [David:]
> >I have received email with C-T-E set to binary. While I don't think it
> >was needed, I haven't checked closely.
>
> Facinating! I am curious: who/what sent this to you! Do you remember
> the MIME type?
The C-T-E: binary is in the message header. The are two alternative
content parts, text/html and text/plain. Both are encoded Q-P. So
the C-T-E: binary is gratuitous. (And mhfixmsg converts it to 8-bit.)
msg part type/subtype size description
0 multipart/alternative 26K
boundary="----------=_1648114734-702538-12126"
charset="UTF-8"
1 text/html 16K
disposition "inline"
2 text/plain 9823
disposition "inline"
The sender, freecycle.org, uses that C-T-E: binary often. Maybe every
time.
> Well, I'm not SURE that's necessarily true. As you point out, that's
> only true for the bodies of message fields. And I see a lot of things
> in the code that assume the body of a message field is a valid C string,
> e.g (mhparse.c):
>
> /* if necessary, get rest of field */
> while (state == FLDPLUS) {
> bufsz = sizeof buf;
> state = m_getfld2(&gstate, name, buf, &bufsz);
> vp = add (buf, vp); /* add to previous value */
> }
That's in FLDPLUS, still in the header.
> In terms of the networking code,
> it looks like the right thing will happen when sending a NUL via
> SMTP,
Almost, but not quite. I posted a possible fix but I'm still refining
it.
> It seems for message bodies we're
> in reasonable shape (unless you are RETRIEVING a message via POP), but
> if a NUL appears in the header somewhere all bets are off.
Yeah. I'd be OK with replacing NULs with some legal
character(s). I'm not sure that just squashing them is a good
idea. I don't have a concrete example, but wonder if it could be
abused, say in a really messy URL.
David
