nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (Not-so) hypothetical question: What to do about NULs?


From: David Levine
Subject: Re: (Not-so) hypothetical question: What to do about NULs?
Date: Tue, 21 Feb 2023 19:44:08 -0800

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]