[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;
}
break;
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.. :)
pgppIqzMeqIxo.pgp
Description: PGP signature
- Re: [Nmh-workers] Garbage collection, (continued)
- Re: [Nmh-workers] Garbage collection, Mike O'Dell, 2013/01/02
- Re: [Nmh-workers] Garbage collection, Ken Hornstein, 2013/01/02
- Re: [Nmh-workers] Garbage collection, Valdis . Kletnieks, 2013/01/03
- Re: [Nmh-workers] Garbage collection, Lyndon Nerenberg, 2013/01/03
- Re: [Nmh-workers] Garbage collection, Ken Hornstein, 2013/01/03
- Re: [Nmh-workers] Garbage collection, Valdis . Kletnieks, 2013/01/03
- Re: [Nmh-workers] Garbage collection, Jeffrey Honig, 2013/01/04
- Re: [Nmh-workers] Garbage collection, Lyndon Nerenberg, 2013/01/04
Re: [Nmh-workers] Garbage collection, Paul Fox, 2013/01/01
Re: [Nmh-workers] Garbage collection,
Valdis . Kletnieks <=
Re: [Nmh-workers] Garbage collection, Michael Richardson, 2013/01/03
Re: [Nmh-workers] Garbage collection, Bill Wohler, 2013/01/04