[lug] Be careful what you ask for (Re: Cluttering the Internet)
Tom Christiansen
tchrist at perl.com
Sun Nov 29 00:41:58 MST 2009
In-Reply-To: Message from Sean Reifschneider <jafo at tummy.com>
of "Sat, 28 Nov 2009 22:49:10 MST." <4B120B56.5060003 at tummy.com>
+----------------------------------------------------------------------+
| +------------------------------------------------------------------+ |
| | READ THIS IN A FIXED-WIDTH FONT, OR ELSE IT WILL BE SCRAMBLED. | |
| +------------------------------------------------------------------+ |
+----------------------------------------------------------------------+
> So, what you're saying is that you had a message to convey, and that
> message is:
> [-- Attachment #1: Freedom-formatted reply by tchrist to anselmi --]
> [-- Type: application/pdf, Encoding: base64, Size: 6.5K --]
> [-- application/pdf is unsupported (use 'v' to view this part) --]
I regret that your UMA is not set up to handle PDF. Have you ever
heard of MH? It has no difficulties with such things. You might
consider upgrading.
Just a thought.
> [-- Attachment #2 --]
> [-- Type: text/plain, Encoding: 7bit, Size: 0.2K --]
> I realize I'm being a bit flippant here, but come on -- PDF?
Why, sure.
Permit me to demonstrate.
>There are standards for e-mail communication, this is a solved problem, a=
>nd
>PDF is *NOT* the solution.
It is indeed a solution to a particular set of problems.
While one could in theory effect a similar result with appropriate
markup using HTML, that's a lot more trouble than
enscript file | ps2pdf
which is all the outbound filter needs to do.
>If someone says that they prefer looking at non-fixed-width fonts, and se=
>ts
>that in their mail client, it is not reasonable that you *FORCE* them to
>read it in your preferred configuration.
Please consult the six samples following my signature for a clear
demonstration of why this is necessary.
What about people who force me to launch a web browser just to read
their email? Isn't that therefore also unreasonable?
>But I'll be clear, I do not think we should allow posting as attachments,=
>period.
Are you sure you've thought that through? You've just disqualified yourself!
$ scan cur +blug
1111+ 22:49 5991 Sean Reifschne Re: [lug] Cluttering the Internet
$ mhlist
msg part type/subtype size description
1111 multipart/mixed 2713
1 multipart/signed 2076
1.1 text/plain 1359
1.2 application/pgp-signatur 253 OpenPGP digital signature
name="signature.asc"
2 text/plain 217
Your message is itself a couple of attachments. I don't think you meant to
disallow yourself, but that's what your policy would do.
On the other hand, unlike your attachmented message, my PDF message was
*not* an attachment. My message had a single, non-multipart MIME type
which was inlined. This is exactly the same as any other inlined single
non-multipart MIME type.
If you really intend to limit messages to "non-attachments", that is,
to single, non-multipart MIME types, then mine is ok and yours is not.
I'm sure you prefer a definition that's the reverse of that, and I am
curious how you are going to manage that.
Checking actual mailing-list messages, I find all of the following MIME
types have been sent through:
GROUP 1:
TEXT/PLAIN; charset=X-UNKNOWN
text/plain; charset="us-ascii"
text/plain; charset="ISO-8859-1"
text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
text/plain; charset=ISO-8859-1; format="fixed"
text/plain; charset=ISO-8859-1; format=flowed
text/plain; charset=UTF-8
text/plain; charset=Windows-1252
text/plain; charset=UTF-8; format=flowed
GROUP 2:
text/html; charset=ISO-8859-1
text/html; charset=UTF-8
text/html; charset="Windows-1252"
GROUP 3:
application/octet-stream; x-unix-mode=0644; name=hack_cal.ics.bz2
application/pdf
application/pdf; filename="Cluttering_the_Internet.pdf"; name="Cluttering_the_Internet.pdf"
application/pgp-signature; name="signature.asc"
application/pkcs7-signature
application/x-cat
GROUP 4:
image/gif; name="538624.gif"; x-mac-type=47494666; x-mac-creator=4A565752
image/jpeg; name="PGH7.jpg"
image/png
GROUP 5:
multipart/alternative
multipart/mixed
multipart/related
multipart/signed
multipart/signed; micalg=pgp-sha1
I'm pretty sure people had reasons for those, but perhaps they didn't
have good ones. I would not dare to hazard any guess though.
Which of those would pass your admittance criteria?
Which would fail your admittance criteria?
I'm guessing you'd want a Content-Disposition of inline only, right?
That will take care of the attachment problem once you forbid group 5.
What about Content-Type? I suppose group 4 has to be out, since that's not
communication, even if it saves a thousand words. I'm guessing you'd
require it to be text only, right? Is postscript text? Or would you mean
*plain* text only?
Group 3 would be out, right? That's merely application stuff.
I suspect you don't want to give a full ok to everything in group 2 and
group 1. Of course, group 2 requires launching some extra program for
those attachments, so that's out.
I suppose people who want to mail web pages will be put off, but that may
be inevitable. After all, those who don't use a web browser to read mail
would be forced to fire up an external viewer to read a mailed web page,
which I believe is your argument against attachments.
Even with group 1, there are things you have to ack or nak.
What about any restrictions based on character set? Is a charset of
Windows 1252 ok? How about UTF-8? What about those whose charset is
out of spec, like the X-UNKNOWN above, or any message that says it's in
a bigger subset than it is (eg, calling 7-bit data Latin1 or CP1252),
which is also in violation.
What about the Content-Transfer-Encoding? Some people don't have much
control over whether something gets quoted-printable (or not), or even
base64-encoded. I've certainly seen regular UTF-8 come over as a big ugly
base64 block. Is that still ok?
Please don't mistake me. I am *not trying* to make any sort of argument at
all either in favor or against any of those. I am just trying to *really*
understand what you are really asking for so that I be a good citizen. I
don't really care what the rules are so long as I understand them,
especially since I'm perfectly capable of working within an all text/plain
environment. A lot of people's mailers are currently misconfigured, but
this is no true barrier.
I do imagine howls of "MIME-hating Luddite!" might be raised, but *I*
certainly will not be one of those voices. I'll just do as everyone
is told to do.
> PDF? DOC? They just do not help with the goal, which is
> communication. For example, I *STILL* haven't read the message(s)
> that sparked this, because as you see above the content is obscured.
Again, it's a shame your mailer is so behind the times. There are many
free ones available you could certainly upgrade to which would not
have this bug.
--tom
+-------------------------------------------------------------------+
| Figure 1: Compute duplication percentage |
| <H1>Figure 1: Compute duplication percentage</H1> |
+===================================================================+
| |
| $ mhlist `pick +blug -search multipart/alternative` | |
| perl -ne '/\d\.\d.*(html|plain).*?(\d+)/i and ${lc $1} += $2; |
| END { |
| printf "html %d, plain %d, %.0f%%\n", |
| $html, $plain, 100 * $html/$plain; |
| }' |
| ^ |
| /|\ |
| / | \ |
| # Notice in the above code I vertically aligned the "html" bits |
| # in pattern match, printf arg, and variable name. This needs |
| # a fixed-width font to line up properly, lest meaning be lost. |
| |
+-------------------------------------------------------------------+
+------------------------------+
| Figure 2: |
| Snowflake Heptahexagon |
+==============================+
| |
| 1 |
| |
| 1 |
| 5 3 |
| 7 4 |
| 7 |
| 5 2 |
| 4 2 |
| 8 |
| |
| 6 |
| |
+------------------------------+
+-----------------------------------------------+
| Figure 3: Standard Heptahexagon |
+===============================================+
| |
| 1 |
| |
| 7 4 |
| 1 |
| 8 5 2 2 |
| |
| 2 5 8 4 8 |
| 6 2 |
| 4 7 7 1 5 |
| |
| 1 7 7 7 |
| 7 |
| 7 7 7 4 |
| |
| 5 1 7 1 2 |
| 5 3 |
| 8 4 5 7 8 |
| |
| 2 8 7 5 |
| 4 |
| 2 1 |
| |
| 4 |
| |
+-----------------------------------------------+
+----------------------------------------------+
| Figure 4: BRC Septasexagon |
+==============================================+
| |
| 1 |
| |
| 7 .-. 4 |
| |1| |
| 8 5 .-. 2 2 |
| |
| 2 - 5 8 4 - 8 |
| |6| |2| |
| 4 - 7 7 1 - 5 |
| \ ^ / |
| 1 7 \./ 7 7 |
| 7 |
| 7 7 /|\ 7 4 |
| / \ |
| 5 - 1 7 1 - 2 |
| |5| |3| |
| 8 - 4 5 7 - 8 |
| |
| 2 8 - 7 5 |
| |4| |
| 2 - 1 |
| |
| 4 |
| |
+----------------------------------------------+
+----------------------------------------------------------------------+
| Figure 5: Galactus's Heptahexagonal Birthday Cake |
+======================================================================+
| |
| * |
| I I I * I I I |
| I I I ******* I I I I |
| VII ******* * ******* VII VII |
| VII VII ******* ******* ******* VII |
| II I I ******* * ******* I I I |
| I I I ******* I I I |
| i i i * i i i |
| iii v iii v iii v iii v iii v iii v |
| iiivvi iiivvi iiivvi iiivvi iiivvi iiivvi |
| .... .... .... .... .... .... |
| :14: :28: :42: :57: :71: :85: |
| :28: :57: :85: :14: :42: :71: |
| :57: :14: :71: :28: :85: :42: |
| ------- ------- ------- ------- ------- ------- ------- |
| i 142857 142857 142857 142857 142857 142857 i |
| ii 285714 285714 285714 285714 285714 285714 ii |
| iii 428571 428571 428571 428571 428571 428571 iii |
| iv 571428 571428 571428 571428 571428 571428 iv |
| v 714285 714285 714285 714285 714285 714285 v |
| vi 857142 857142 857142 857142 857142 857142 vi |
| |
| ^ iiiivv iiiivv iiiivv iiiivv iiiivv iiiivv ^ |
| ^ iiv i iiv i iiv i iiv i iiv i iiv i ^ |
| ^ i i i i i i ^ |
| ^ :57: :14: :71: :28: :85: :42: ^ |
| ^ :28: :57: :85: :14: :42: :71: ^ |
| ^ :14: :28: :42: :57: :71: :85: ^ |
| <<<<<<^ ___ ___ ___ ___ ___ ___ ___ >>>>>>^ |
| |
+----------------------------------------------------------------------+
+--------------------------------------------------------------------------+
| Figure 6: ERRANTRY |
+==========================================================================+
| *This*'ll |
| get TahtaahaHwatHhhtSesaHthaHihahoaahaaa |
| people h eo neneicheiehhloneoenene en ensn |
| to em ld d tra s aeu d d f bc d d |
| love rebwo p chots bt dl wsm cfblmfoat f |
| mail esuaapeca s aee leosonafaiuoaiarhrlq |
| with sindoralcsltrgfadnivadeuliwdrtareuu |
| fixed-width weld rfrla a rglu ggereagaleee vecta |
| o anteorudertyaaeugh a e thmtr heaktv |
| n - sg rfimadgh nndthihla ahte haeldlee |
| t :-) - ea dem oebdt temed h e nahen eerr |
| s t ar iygdote e raed rtebrht ordbadsii |
| . o ,gnee mhsrtsy r usyire e lu u- snn |
| m i,lsh e iwa peant s ewroissaigglgg |
| weld eal l ea ivenardtpuasiti fteh-lley,, |
| vecta r daofrnwneeg-e idnunlni t,ostim |
| peant rmenwo di rn ttbhtide;egnsl eh mssat |
| sendno yadd rw nts aatyiye - petsihm hnh |
| caen r o ildo t ry midsatlabi o meeiede |
| aaa pighrptas somr t,n mihenedb omrrn y |
| e e e anoaarhv ce eybo gwireadweohfe i sw |
| n n n sendno eoavtliu d;ity t irwi rmnnqaw |
| srd gvmnfreaontme zh-fhsl-eddiageuva |
| e;oieead rnrdgtal aytoewdtreinr caen |
| c n lnsnreaytry;eru rihlraeh- agv knrd |
| g a djrr ey rrd dnil lrrhhm e ldie |
| a e h eo.ghe fye rgnowlmeoeo l aenr |
| r e rr oinh l d y. wioeaurn l crge |
| e a r ;a sm i yh nwnds d o ee,d |
| m i m ih ig-t;eh u sd |
| n e . mi n w e s o |
| s .m i a -t n |
| e , n d h . |
| g ; e |
| m |
| , |
| n |
| |
+-------------------------.------------------------------------------------+
More information about the LUG
mailing list