[Mailman-Developers] Missing footers with latest CVS
Ben Gertzfield
che@debian.org
Thu, 07 Mar 2002 15:45:03 +0900
>>>>> "BAW" == Barry A Warsaw <barry@zope.com> writes:
>>>>> "SJT" == Stephen J Turnbull <stephen@xemacs.org> writes:
>>>>> "Ben" == Ben Gertzfield <che@debian.org> writes:
Ben> This would violate RFC 1522:
SJT> That's right. People with broken mailers have broken
SJT> mailers. Make sure that things are robust for those with
SJT> decent software, and then do what we can for the former poor
SJT> souls.
BAW> The only hope we have of interoperating is to support the
BAW> standards, or at least not willfully break them <Hippocratic
BAW> oath wink>. Which means if the charsets don't match, we
BAW> can't simply tack on headers and footers. So we either don't
BAW> add them or we add some multipart/mixed chrome and do it in a
BAW> MIME-compliant way.
Can we safely assume that all charsets folks will use with Mailman
will have us-ascii as a subset? It seems to be the case so far.
If so, I think the code I wrote can be loosened up a bit -- us-ascii
headers/footers can *always* be added to a message, so if the list's
language is US English, adding headers and footers should be fine no
matter what the charset.
If the list's language is not US English, though, we just simply
cannot add a header/footer blindly unless the message explicitly says
it's the same charset as the header/footer will be. Any other way
lyes madness. :)
BAW> I really don't want to think about PGP right now. Mailcrypt
BAW> w/GnuPG seems to only sign or encrypt the body, and in a
BAW> non-MIME way, so if we wanted to add headers and footers it
BAW> seems like we'd be safe by wrapping the original body in
BAW> multipart/mixed chrome. Of course you'd have to unpack the
BAW> parts to verify (read) the signed (encrypted) part. Oh well,
BAW> there's not really much more you /can/ do.
Well, remember that old-style PGP bodies will have the whole:
===BEGIN PGP SIGNED MESSAGE===
blah blah
===BEGIN PGP SIGNATURE===
abcdef123456
===END PGP SIGNED MESSAGE===
thing going, so we can safely add headers/footers to these kinds of
messages, as they will be outside these ===VERY LOUD AREAS===.
I don't know how it works for S/MIME, frankly.
Ben
--
Brought to you by the letters T and G and the number 17.
"Ooh, don't touch him, HE'S got the wall sconses."
Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/