Re: Archive One Message Behind Using -add
On February 7, 2002 at 15:33, Don wrote: You could easily do some tests to find out what is going on by replacing webnewmail with a simple program (like cat) that just dumps the contents /var/mail/beta to some temp file. Then you can examine the temp file to see if the new message actually exists or not. I had actually tested that possibility with a ksh and in fact it did execute the ksh script before the email landed in the spool file. What was confusing is that it would work without the -add. Could be a race condition. If the call to webnewmail is a forked sub-process, then the addition to the beta spool file could be happening in parallel. If this is the case, the -add causes mhonarc to run much faster over the spool file since it will skip already archived messages. Without the add, it is reconverting every message, making the processing of the spool file slower and potentially giving time to sendmail to perform the append operation before mhonarc gets to the end of the file. --ewh
Re: Possible to change $DATE$ display format?
On February 7, 2002 at 22:18, Ed Reiss wrote: I'd like to change the format with which $DATE$ is displayed in the general (by date) archive from: Wed, 6 Feb 2002 16:13:10 -0700 (MST) to Wed, Feb 6 2002 16:13:10 -0700 (MST) Thanks for any help. Look at the $MSGLOCALDATE$ and $MSGGMTDATE$ resource variables. --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
TSLICE problems
Hi all, For me, using TSLICE (and MHonArc v2.5.2) with TSLICE 4:4:1 /TSLICE and referring to it with a plain $TSLICE$ results in slices which list the previous messages in the thread, the current message, but only ever the *first* of the following messages. So, if there are six items in the thread, the slice for 1 will show 1 and 2; the slice for 2 will show 1,2 and 3, etc., but only the sixth thread will have the complete list. It's almost as though the second argument to TSLICE is stuck on 1. From the 2.5.0b docs I gleaned: --- Problem: Some messages not updated to show changes in thread slice listing. Solution: This is really a limitation on how messages are tagged for update and problem may occur explicit range parameters are specified for $TSLICE$ that differ from default values in TSLICE. Work-around to problem is now documented in the TSLICE resource page. --- ... but as I'm not specifying explicit range parameters for $TSLICE$ this doesn't seem to be relevant. A Google search found (30 Sep 2001): --- [...] To summarize the note above: Some message pages may not get properly updated to reflect changes in $TSLICE$ listing. This can occur if the message is more than one message away from a new message in a thread. I consider it not a major problem since the next/prev links still function properly. However, older messages may not properly show the latest slice representation, and as the reader goes through the thread, the slice listing can appear to grow as they go from older messages to newer messages. --- ... which is very close to my experience, except that for me it's not some message pages, may not, or can appear --- it's consistent, and it doesn't seem to matter how I juggle the ordering. I would respectfully disagree with not a major problem. Consider the situation where a user clicks a message from say the middle of a thread index. On being presented with the message, the slice will not tally with what (s)he previously saw. (S)he thinks that the list is somehow corrupt, or the messages have been deleted ; at best it's back to the thread index page. However, I assume it's an error on my part, as others are apparently using TSLICE perfectly - e.g. I think this is a MHonArc list : http://archiver.rootsweb.com/th/read/ENG-BLACK-COUNTRY/2002-02/1012973479 Any suggestions for what on earth I'm doing wrong? Thanks, Mike
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: TSLICE problems
On February 9, 2002 at 08:41, Mike Hamilton wrote: Hi all, For me, using TSLICE (and MHonArc v2.5.2) with TSLICE 4:4:1 /TSLICE and referring to it with a plain $TSLICE$ results in slices which list the previous messages in the thread, the current message, but only ever the *first* of the following messages. So, if there are six items in the thread, the slice for 1 will show 1 and 2; the slice for 2 will show 1,2 and 3, etc., but only the sixth thread will have the complete list. Is this after successive archive updates? From the 2.5.0b docs I gleaned: --- Problem: Some messages not updated to show changes in thread slice listing. Solution: This is really a limitation on how messages are tagged for update and problem may occur explicit range parameters are specified for $TSLICE$ that differ from default values in TSLICE. Work-around to problem is now documented in the TSLICE resource page. --- ... but as I'm not specifying explicit range parameters for $TSLICE$ this doesn't seem to be relevant. It should not, but ... --- [...] To summarize the note above: Some message pages may not get properly updated to reflect changes in $TSLICE$ listing. This can occur if the message is more than one message away from a new message in a thread. I consider it not a major problem since the next/prev links still function properly. However, older messages may not properly show the latest slice representation, and as the reader goes through the thread, the slice listing can appear to grow as they go from older messages to newer messages. --- ... which is very close to my experience, except that for me it's not some message pages, may not, or can appear --- it's consistent, and it doesn't seem to matter how I juggle the ordering. Can you provide test data and a scripted scenario (eg. add this message, then this, then this, add see the results -- maybe encapsulated in a shell script)? Please include any resource files and command-line options you used. I would respectfully disagree with not a major problem. Consider the Of course, it is always a matter of perspective. situation where a user clicks a message from say the middle of a thread index. On being presented with the message, the slice will not tally with what (s)he previously saw. (S)he thinks that the list is somehow corrupt, or the messages have been deleted ; at best it's back to the thread index page. I agree there could be some confusion, but without any real user testing, we do not know if it matters. I.e. There is a dependency on how users interact with the archive. However, I assume it's an error on my part, as others are apparently using TSLICE perfectly - e.g. I think this is a MHonArc list : http://archiver.rootsweb.com/th/read/ENG-BLACK-COUNTRY/2002-02/1012973479 Note, the site you give looks like they use MHonArc, but there is no direct indications that it is being used except for similiar page layout stylistic conventions. Any MHonArc-type markers in the HTML are not present and there is no mention of MHonArc on the site. How do you know MHonArc is being used at archiver.rootsweb.com? Any suggestions for what on earth I'm doing wrong? Not currently. It is probably a bug. I will have to do some testing to see what is going on. The first step is to have a recreatable test case so I can use it to help analyze the code. --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
