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