[Top][All Lists]

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

Re: [Nmh-workers] Garbage collection

From: Valdis . Kletnieks
Subject: Re: [Nmh-workers] Garbage collection
Date: Thu, 03 Jan 2013 02:25:02 -0500

On Tue, 01 Jan 2013 11:56:41 -0500, Ken Hornstein said:

>   it lasted that long).  Also, it looks like to me that no RFC describes
>   how UUCP addresses are supposed to be formatted, so it's not even clear
>   to me how a correct address parser are supposed to handle those things.

The real problem is that back in the mail environments where you might see
!-pathing in an address, you were *also* prone to seeing %-hacking. And usually
arcane knowledge was needed to figure out ! vs % vs @  precedence (for a while,
I ran a gateway machine where the precedence was different based on which
network interface the mail was received on, and re-writing a ! adddress going
out interface 1 had different semantics if the ! came in interface 2 or
interface 3.  And this all got done in Sendmail 5.61 .cf, with no m4 help.

> - Content-MD5 support.  I will admit that I haven't done a complete survey,
>   but from what I've seen nmh is the only MUA still generating a Content-MD5
>   header in MIME messages.  This means we need a MD5 implementation, and
>   a test for it.  This has caused portability problems in the past, and
>   I'm wondering if this is useful at all; I get the feeling that we're the
>   only ones to support it.  See Markus's thesis for a more complete survey.

I wonder if our current support is busticated.  I've looked at this
code in uip/mhbuildsbr.c:

     * output the Content-MD5
    if (checksw) {
        np = add (MD5_FIELD, NULL);
        vp = calculate_digest (ct, (ct->c_encoding == CE_QUOTED) ? 1 : 0);
        add_header (ct, np, vp);

and I haven't convinced myself that calculate_digest() actually DTRT
(in particular, I suspect that doesn't do what you think it does when
it hits a CE_BASE64 object....)

> - EBCDIC safe encoding.  Forces quoted-printable encoding if an "EBCDIC
>   unsafe" character is seen (see uip/mhbuildsbr.c:ebcdicsafe[]).  We
>   don't care about this, right?

Another thing that looks brokked at first reading.  WTF does this do:

    switch (ct->c_type) {
    case CT_TEXT:
        check8bit = 1;
        checkboundary = 1;
        if (ct->c_subtype == TEXT_PLAIN) {
            checkebcdic = 0;
            checklinelen = 0;
            checklinespace = 0;
        } else {
            checkebcdic = ebcdicsw;
            checklinelen = 1;
            checklinespace = 1;

Looks to me like if it's a text/plain, we can never check?

In any case, it should be heaved over the side - even back when a
fair share of e-mail users lived on Bitnet or VNet, even ebcdic-ebcdic
mailing wasn't guaranteed safe due to the fact that there are
multiple codepages.  And I won't discuss the issues involved in getting
the unit-record-based spooling paradigm in VM/XA to represent the null
line between rfc822 headers and body (short answer - it was emulated
with a single blank.  Yes, go ahead and think of all the ways that can
break if an actual single blank arrived.  It's a surprise I didn't
drink heavily back then.. :)

Attachment: pgppIqzMeqIxo.pgp
Description: PGP signature

reply via email to

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