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.. :)
pgprIUzCeGxec.pgp
Description: PGP signature
_______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers