Executive summary: -0.8 for changing Scrubber (don't think there's a benefit either way => don't bother), +0.5 for .txt (not sure it's worth the effort), plus an amusing (YMMV) story.
Mark Sapiro writes: > On 3/4/21 7:05 PM, Stephen J. Turnbull wrote: > > Mark Sapiro writes: > > > Does Scrubber really do that? Per RFC, the two Content-Type fields > > have exactly the same semantics: "it is plain text, encoded as ASCII." > > Yes, scrubber really does this. This dates back to Tokio and various > Japanese language emails which presumably weren't all ascii. Perhaps we > should revisit this, but you know much more about Japanese language > emails than I do. I don't think there's a need to change nowadays. The problems I see now are (a) spam where the rules never did apply anyway and (b) in application/* attachments such as zipfiles. Common MUAs all do the right things with text/*, and there are very few folks who bother to write their own (or use netcat to talk to port 587 ;-) anymore. > Apparently, Tokio thought it was better to scrub such a part than to > treat it as ascii when it wasn't. It certainly was back then. A little earlier than that, I was at Ohio State and they used a Prime minicomputer for email and secretary- supported wordprocessing. The professor who was head of the Econ Dept computer committee got full of himself and sent me a huge warlording .sig full of VT-220 (maybe even VT-320) control sequences for flashing and reverse video and the like, containing the message "Beware the Wizard!" It was indeed very bright! and shiny!, so I sent it back to him with compliments (something like "A sufficiently advanced technology is indistinguishable from magic, but I have the VT-220 programming manual"). Silly Rabbit, Trix are for kids -- he had ripped off the fancy large screen console terminal for use in his personal office. (I can't blame him, it was *very* nice and it's not like you need more than a VT-52 or so for the console.) It was *not* VT-compatible, and apparently that warlord sig not only reprogrammed its function keys, but proceeded to invoke them, sending a message to the host which promptly crashed hard. (I didn't notice the crash as I was using a PC for real work and email is asynchronous so nothing out of the ordinary there either. I heard about it the next day at the faculty meeting where "The Wizard" got a dressing-down for misappropriating department property. :-) I imagine that terminal lockups etc, if not full-blown system crashes, were reasonably common with Shift JIS too. > Perhaps a compromise is to give scrubbed text/plain attachments a > .txt. extension rather than taking the first item returned by > mime_types.guess_all_extensions. I'm not sure. Nowadays I'm not so worried about harming the machine as the possibility of malware (eg, URLs with Greek or Cyrillic cognates of ASCII characters directing you to a phishing site when you think you're linking to Amazon). On the other hand, I guess if you're going to fall for that with .txt, you'll probably think "computers are weird" and fall for it with Content-Type: application/octet-stream; name="inline-text.ksh" too. :-( So, yeah, if you want to go to the trouble, I think defaulting to .txt for text/plain with no filename specified is more user-friendly. ------------------------------------------------------ Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/
