>>>>> "BAW" == Barry A Warsaw <[EMAIL PROTECTED]> writes: >>>>> "SJT" == Stephen J Turnbull <[EMAIL PROTECTED]> writes: >>>>> "Ben" == Ben Gertzfield <[EMAIL PROTECTED]> 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/ _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers