This looks ok, assuming that the line breaks, empty lines and so on are caused by cut+paste and are not present in the original message.

I wonder what are the spool characteristics of the file (I mean Q R ALL * spoolid and also the TAG).

One potential problem is that you are not using LMail, which is actually a pre-req for LISTSERV, even though it will usually work if you feed LISTSERV directly from FAL. Usually but without guarantees. FAL typically uses a derivative of the old CMS NOTE format, and LISTSERV does support CMS NOTE, so it has to try and figure out which incoming NOTE format files are genuine NOTE, which are RFC822, etc. This could potentially interfere with the respooling code. With genuine NOTE it would not be a problem since you are hardly going to have any HTML ;-)

A second, unrelated problem is that the actual command is missing from your first example. This is probably due to a bug in the initial 1.8e release build that could lose the last line in a multipart message if it was formatted in a certain way (eg by Lotus). There is a fix for that, but you do not reach that point yet. For now, I suggest adding a second line in the text messages to put this problem aside while working on the main problem.

Anyway, the whole point of this new feature is to properly support users who send HTML mail by default (which is becoming the majority of users with a recent version of Windows and Outlook). 1.8d had absolutely no support for this. The message would be processed line by line, generating error messages, and eventually you would run into the first line of the text/plain part, which would be executed successfully. Then more error messages and eventually LISTSERV would give up. It worked, but it was confusing to the users. And it only worked when using unencoded ASCII. 1.8e will respool the message after removing everything but the plain text. There was the unfortunate bug about sometimes losing the last line (which remained undetected for a long time since most users who default to HTML also have a signature file, and LISTSERV stops scanning when it reaches it, so it did not matter if the last line was lost), but apart from that there have been no reported problems. I have just tested it again on VM with the initial 1.8e build and it worked as expected, which is why I am getting suspicious about the LMail issue.

  Eric