On Mon, 7 Oct 2002, Jonathan Chum wrote: > I've sent a HTML document successfully to the list and I'm curious > what will happen to those who cannot read HTML documents properly? Is > there an option in Mailman for subscribers to subscribe to a text only > version, or will that require setting up a new list?
The proper way to handle a subscriber base where the capabilities of the end-users' e-mail software varies is to send a multipart message with the same content rendered in various formats. Such messages are called "multipart/alternative" (for obvious reasons) and modern e-mail software will select an appropriate part to display. Modern e-mail software will also -compose- these multipart/alternative messages for you; make sure you are using modern e-mail software and that you have it configured to do this. The down side? Your outgoing message is larger than it needs to be, because it contains the same information more than once. (Also, some formats, like HTML, are "fluffy" -- they are all by themselves larger than they need to be to convey the information.) This is a problem if you pay for your connectivity by the byte, or if you are near your monthly limits or whatever. If connectivity is cheap for you, then you may find this downside to be small. If connectivity is -not- cheap for your subscribers, they may very well ask if you can drop the HTML stuff and just send it plain-text. If you do not mind sending the same message twice - once in HTML and once in plain text - you are certainly free to set up two lists and direct people to subscribe to the one that suits them. The nature of the messages going out, and the nature of your subscriber base will determine whether or not this becomes a huge pain in the neck. For example, this might lead to an administrative nightmare if subscribers become really confused about the two lists, or if your turn-over rate is high, or whatever. Or, it may be a breeze. > Or will Mailman handle this for me? I will hazard a guess that no, Mailman will -never- take care of reposting HTML messages to HTML or plain text (or other formats) based on the subscriber's preference. For one, as I outlined above, accommodating varying e-mail reading software capabilities is already taken care of with an established standard (RFC 2046 (see section 5.1.4 in particular)). For another, there is already plenty of work to do on essential and highly desireable features, to say nothing of docs, etc. What you envision would require Mailman to have a full-blown HTML parser so that it can render things like nested HTML tables into the equivalent formated plain text. For the same reason that Mailman will (I would guess) never contain a spell-checker, I would guess that it will never contain an HTML parser: This is not Mailman's role. - Andrew ---------------------------------------------------------------- Mailman Administrator - http://www.tux.org/mailman/listinfo/ ------------------------------------------------------ Mailman-Users mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
