Re: Preferring text/plain over text/html?
I would get some hints how to incorporate such a unhtml tool. I am triggering monarch with a cronjob. Sendmail is building the inbox. Where might I hook up the unhtml as standard input??? Surprised that nobody has suggested Tim Pierce's unhtml.c. Works fine for me ; search for it with google. This program reads a message on __standard___input___ and prints a demangled version on standard output. If the message has a content-type of `multipart/alternative', the body is discarded and replaced with the first text/plain subpart that can be found. If the message isn't multipart/alternative, or if it contains no text/plain subparts, the original message is passed through unmodified. For example, it can easily be hooked into SmartList in rc.local.s00 (and .r00):
Re: Preferring text/plain over text/html?
On February 15, 2002 at 14:19, Mike Acar wrote: Currently, if you specify that text/html should be excluded, then the text/plain will be used, but the exclusion applies to all text/html data, even for non-multipart/alternative messages. [...] I've finally gotten around to testing this, and it doesn't appear to work; MHonArc's output just includes text/html: EXCLUDED and that's all. This is a bug, as I stated in a different message. See http://www.xray.mpe.mpg.de/mailing-lists/mhonarc/2002-02/msg00029.html. --ewh
Re: Preferring text/plain over text/html?
On February 8, 2002 at 13:59, Morse, Richard E. wrote: What if the text/plain message is merely a message saying I'm sorry, but thi s message cannot be displayed in you mailer. The actual message has been attac hed as an HTML message. -- This has happened. Live with it. Seriously, this is extremely bad behavior of the MUA. The sematics of multipart/alternative is to have each part be reasonable *alternatives* of each other. With the example you provided, this is not the case. The MUA should have not bothered with using multipart/alternative and just set the main Content-Type to text/html. The receipient's MUA will be responsible for telling the receipient if the MUA is unable to render the data received. Also, if the main type was text/html and the receipient's MUA was MIME aware but did not support text/html, it would still show the raw HTML text. This is desired fallback behavior of a MIME-aware MUA when encountering unknown text media types. I.e. The MUA would treat the data as text/plain for purposes of displaying the message to the user. IMO, it is unreasonable to have MHonArc try to deal with such a situation. --ewh
Re: Preferring text/plain over text/html?
On Fri, 8 Feb 2002 13:59:24 -0500 Richard E Morse Morse wrote: What if the text/plain message is merely a message saying I'm sorry, but this message cannot be displayed in you mailer. The actual message has been attached as an HTML message. -- This has happened. True, tho I've only seen it happen with SPAM. -- J C Lawrence -(*)Satan, oscillate my metallic sonatas. [EMAIL PROTECTED] He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
Re: Preferring text/plain over text/html?
Morse, Richard E. [EMAIL PROTECTED] wrote: What if the text/plain message is merely a message saying I'm sorry, but this message cannot be displayed in you mailer. The actual message has been attached as an HTML message. -- This has happened. It gets chucked. You can call me an arrogant luddite if you'd like, but I'm of the opinion that HTML has no business being used for mail content, and I have no remorse about enforcing this opinion upon the users of my mail archive. -- Brilliance and gorgeousness| Mike Acar And we tell ourselves we don't want the treasures | [EMAIL PROTECTED] But we hate the glass anyway |
RE: Preferring text/plain over text/html?
I think you misunderstand -- this is the text/plain section of the message. This is _not_ something done by the MUA -- I know, because the actual message was somewhat less terse. It is really the fault of the MSA (Mail Sending Agent), and probably somewhat the fault of the person who wrote the message... Ricky -Original Message- From: Earl Hood [mailto:[EMAIL PROTECTED]] Sent: Friday 08 February 2002 3:06 PM To: [EMAIL PROTECTED] Subject: Re: Preferring text/plain over text/html? On February 8, 2002 at 13:59, Morse, Richard E. wrote: What if the text/plain message is merely a message saying I'm sorry, but thi s message cannot be displayed in you mailer. The actual message has been attac hed as an HTML message. -- This has happened. Live with it. Seriously, this is extremely bad behavior of the MUA. The sematics of multipart/alternative is to have each part be reasonable *alternatives* of each other. With the example you provided, this is not the case. The MUA should have not bothered with using multipart/alternative and just set the main Content-Type to text/html. The receipient's MUA will be responsible for telling the receipient if the MUA is unable to render the data received. Also, if the main type was text/html and the receipient's MUA was MIME aware but did not support text/html, it would still show the raw HTML text. This is desired fallback behavior of a MIME-aware MUA when encountering unknown text media types. I.e. The MUA would treat the data as text/plain for purposes of displaying the message to the user. IMO, it is unreasonable to have MHonArc try to deal with such a situation. --ewh
Re: Preferring text/plain over text/html?
On February 8, 2002 at 16:38, Morse, Richard E. wrote: I think you misunderstand -- this is the text/plain section of the message. This is _not_ something done by the MUA -- I know, because the actual message was somewhat less terse. It is really the fault of the MSA (Mail Sending Agent), and probably somewhat the fault of the person who wrote the message.. I do not know what an MSA is. If you are refering to an MTA, Mail Transfer Agent, I do not know of one that would actually do this, unless we start talking about Microsoft products. I guess an MSA could be something that does not compose/read messages, but just hands off messages to an MTA. However, usually MUAs perform this function directly. The mess with multipart/alternative has typically been caused by modern MUAs (Outlook, Netscape Composer) that do the plain-text/HTML junk. Although, Exchange may be involved also (which is also the source of the dreaded tnef data). Of course, all of this is done while keeping the users of the software completely ignorant causing them to become the bearers of electronic heat from irate receipients. Now, if you are refering to a multipart/mixed message where the first part contains the message you have mentioned and the other part(s) are HTML, then, again, we'll have to live with it. If you are using the MIMEEXC resource to block out text/html data, then the MHonArc message page will show that the data was explicitely excluded. If the message example you provided is the first part of multipart/alternative sections, then if the text/html part is being excluded, then hmmm ... looking at readmail.pl ... it appears the current version of MHonArc will actually use the text/html part, but it will state that is has been excluded (assuming MIMEEXCS is set to exclude text/html). Looks like a bug. readmail.pl should fallback to the text/plain part. --ewh
Re: Preferring text/plain over text/html?
Hi People a strange problem. Forbidden name for a list? While adding new lists to our multiple languages we have the basic 'a-infos' to which we add '-xx' to compose the individual list. So, a-infos-en is the name of the English posts a-infos-de is the name of the German posts etc. The webpage of the lists are on our domain name/xx/ on our server the address is .www/xx/ and in the aliases file of postfix it is a-infos+xx a-infos-en-h: ainfos+en - for the English one. In the past we tried to build a list a-infos-sh for Serbo-croat a-infos-sh-h: ainfos+sh but the archiving failed. When we changed it to a-infos-st-h: ainfos+st It worked. Now, we tried the a-infos-pl-h: ainfos+pl and it failed. I wonder if 'pl' is a forbidden suffix like 'sh'. Ilan Shalif
Re: Preferring text/plain over text/html?
On February 8, 2002 at 15:43, Charlie Watts wrote: Do you think it's the fault of the MUA or of the user operating it when established internet standards for quoting text aren't followed when replying? The MUA. When forced to use Outlook (what I prefer to call Outhouse) at my previous job, I had to make the extra effort to reply to messages in the prefered style of the internet community. Because Outlook makes it more of a effort on the user to format message replies in a different manner than the Outlook wants you to do it, even the users who know better fall into the Outlook style over time. Can software be passive-aggressive? If the only exposure to the Internet community a person has is with software that prefers to make its own rules, it is hard to blame the person for bad style. It is now the norm that most people interacting with the Internet use proprietary software, a world where the proprietary software vendors promote their way of how things should be done to lock their user in. --ewh
List-names (was Re: Preferring text/plain over text/html? )
On February 9, 2002 at 01:20, Ilan Shalif wrote: In the past we tried to build a list a-infos-sh for Serbo-croat a-infos-sh-h: ainfos+sh but the archiving failed. When we changed it to a-infos-st-h: ainfos+st It worked. Now, we tried the a-infos-pl-h: ainfos+pl and it failed. I wonder if 'pl' is a forbidden suffix like 'sh'. I'm having a hard time seeing how this relates to MHonArc. Can you provide how you invoked MHonArc and what kind of errors you received? --ewh
Re: Preferring text/plain over text/html?
On February 6, 2002 at 16:02, Mike Acar wrote: Is there a way to get MHonArc to prefer text/plain versions of messages over text/html in multipart/alternative? Not without code changes. Currently, if you specify that text/html should be excluded, then the text/plain will be used, but the exclusion applies to all text/html data, even for non-multipart/alternative messages. Some thought needs to be applied on what would be the best way to support such a feature. One part is that actual implementation, the other is how the user would tell MHonArc about multipart/alternative preference ordering. --ewh
Re: Preferring text/plain over text/html?
Earl Hood [EMAIL PROTECTED] wrote: On February 6, 2002 at 16:02, Mike Acar wrote: Is there a way to get MHonArc to prefer text/plain versions of messages over text/html in multipart/alternative? Not without code changes. Currently, if you specify that text/html should be excluded, then the text/plain will be used, but the exclusion applies to all text/html data, even for non-multipart/alternative messages. Which would be ok with me; I can't really see that there's any reason to send HTML to this list. Some thought needs to be applied on what would be the best way to support such a feature. One part is that actual implementation, the other is how the user would tell MHonArc about multipart/alternative preference ordering. Well, by far the most common is text/plain and text/html sent by such clients as Outhouse (which you love so well ;), so the obvious thing would be simply adding a prefer-multipart-plain-over-html config option. More generally I guess you could have a config section that specified a a multipart type and a list of MIME types in order of preference... A truly generic solution might be difficult to describe elegantly in a config file. -- Brilliance and gorgeousness| Mike Acar And we tell ourselves we don't want the treasures | [EMAIL PROTECTED] But we hate the glass anyway |
Re: Preferring text/plain over text/html?
On Wed, 06 Feb 2002 09:36:54 -0800 Earl Hood [EMAIL PROTECTED] wrote: Some thought needs to be applied on what would be the best way to support such a feature. One part is that actual implementation, the other is how the user would tell MHonArc about multipart/alternative preference ordering. FWIW this is what exmh does (my preferred MUA) and it works very nicely. -- J C Lawrence -(*)Satan, oscillate my metallic sonatas. [EMAIL PROTECTED] He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
Re: Preferring text/plain over text/html?
On February 6, 2002 at 23:18, Mike Acar wrote: Is there a way to get MHonArc to prefer text/plain versions of messages over text/html in multipart/alternative? Not without code changes. Currently, if you specify that text/html should be excluded, then the text/plain will be used, but the exclusion applies to all text/html data, even for non-multipart/alternative messages. Which would be ok with me; I can't really see that there's any reason to send HTML to this list. Then you can use the MIMEEXCS resource. Some thought needs to be applied on what would be the best way to support such a feature. One part is that actual implementation, the other is how the user would tell MHonArc about multipart/alternative preference ordering. Well, by far the most common is text/plain and text/html sent by such clients as Outhouse (which you love so well ;), so the obvious thing would be simply adding a prefer-multipart-plain-over-html config option. This is too specific. There can be other cases where you may want to set a preference list of types for multipart/alternative data. More generally I guess you could have a config section that specified a a multipart type and a list of MIME types in order of preference... A truly generic solution might be difficult to describe elegantly in a config file. Exactly. Maybe something like: MIMEAlternativePrefs text/enriched text/plain application/pdf text/html /MIMEAlternativePrefs The list goes from most prefered to least prefered. A problem is how mhonarc should order things for a multipart/alternative message that includes some parts that are in the list and some that are not. What to do about the ones not in the list. An alternative approach is to specify paired preferences settings. For example: MIMEAlternativePrefs text/enriched; text/plain text/plain; text/html /MIMEAlternativePrefs This states that text/enriched is prefered over text/plain and text/plain is prefered over text/html. I.e. If a message contained a text/plain part and a text/html part, the text/html part will automatically be discarded since the prefered text/plain part exists. Of course, mhonarc should be smart enough to resolve the case where a message contained a text/plain, a text/enriched, and a text/html part: text/enriched should be the winner. You also have other types of complexities: MIMEAlternativePrefs text/plain; text/html text/enriched; text/html /MIMEAlternativePrefs The winner would then be determined by the part ordering in the message. If text/enriched occur later than text/plain, text/enriched wins. Otherwise, text/plain wins. Now, the issue with unspecified types is handled pretty easily (and come to thing about it, the approach I am going to mention could apply to the first usage of MIMEAlternativePrefs). MIMEAlternativePrefs basically defines a exclusion list that only applies with mulitpart/alternative data. For example, a text/html part is automatically excluded if a text/plain part exists. Once all parts are excluded, the part ordering sematics of mulitpart/alternative come in to determine which part wins out. With this model, the first MIMEAlternativePrefs usage (specifying a preferences list) can be used and should be less confusing than the second usage. A subtle problem that could show up is the case of nested multipart/alternatives. For example: --XXX Content-Type: text/plain asdfasd --XXX Content-Type: multipart/alternative; boundary=YYY --YYY Content-Type: text/html html.../html --YYY-- --XXX-- In this case, the text/html would sneak through. Now, if the MIMEAlternativePrefs is implemented a certain way, the above could be addressed with the following setting: MIMEAlternativePrefs text/plain text/html multipart/alternative /MIMEAlternativePrefs This states that a text/plain or a text/html has precedence over a nested multipart/alternative part. It would be cool if multipart/alternative nesting was flattened out, but I think this would take too much work, and since it is probably extremely rare to have multipart/alternative parts within multipart/alternative parts, why bother. The final thing to deterime if base types should be supported. Example: MIMEAlternativePrefs text/* image/* /MIMEAlternativePrefs --ewh
