Hi again. The problem seemed cured, now I am getting garbled posts again.

Further, this post took a full 6 days to show up after I sent it.

Maybe I am on moderation, and the moderator is slow at checking in. Or ??

Michael Welch wrote at 07:04 PM 06/20/2007:

This list's posts started showing up with all the line returns ignored. None of my other emails are showing up this way. Not sure when it started, I have been on vacation. But I noticed it earlier today and decided to start watching it.

Am I the only one?

Michael Welch, volunteer Redwood Alliance PO Box 293 Arcata, CA 95518 707-822-7884 mwelch@redwoodalliance.org www.redwoodalliance.org

Thanks Brad & Dan for straightening me out. Kinda embarrassing, since I am a header watcher.

Peace.

Brad Knowles wrote at 09:29 AM 06/26/2007:

On 6/26/07, Michael Welch wrote:

...

Hi again. The problem seemed cured, now I am getting garbled posts again.

Further, this post took a full 6 days to show up after I sent it.

Maybe I am on moderation, and the moderator is slow at checking in. Or ??

Try checking your headers again:

   Received: from homepower.com (rickgermany.com [72.32.57.52])
           by bag.python.org (Postfix) with ESMTP
           for <mailman-users@python.org>; Tue, 26 Jun 2007
           13:20:00 +0200 (CEST)
   Received: from adsl-66-126-233-22.dsl.anhm01.pacbell.net
           [66.126.233.22] by homepower.com with SMTP; Wed,
           20 Jun 2007 19:15:19 -0700

Whatever machine is running homepower.com, they delayed your mail, not us.

Moreover, mailman-users is one of the very few mailman-* lists where new members are not moderated by default. Once you're subscribed, you should be able to post immediately.

I can't speak to the other problems.

-- Brad Knowles <brad@shub-internet.org>, Consultant & Author LinkedIn Profile: <http://tinyurl.com/y8kpxu> Slides from Invited Talks: <http://tinyurl.com/tj6q4>

09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Michael Welch, volunteer Redwood Alliance PO Box 293 Arcata, CA 95518 707-822-7884 mwelch@redwoodalliance.org www.redwoodalliance.org

Mark Sapiro wrote:

My guess (I haven't actually looked at the raw decoded message) is that the decoded plain text has *nix <LF> only line endings as opposed to <CR><LF> endings. This would not violate RFC 2821 as the data on the wire is the base64 encoded data, not the original text.

I have now looked, and in today's two base64 encoded posts in the "export list subscribers list" thread, the decoded message body does have text with only <LF> as a line ending.

So,

I think the issue may be that your MUA doesn't recognize a single <LF> in the decoded text as a line break.

I don't know if there is a standard that says your MUA 'should' recognize a single <LF> in the decoded text as a line break, but of five MUA's I just tried, four - Ultrafunk Popcorn 1.76, Mozilla Thunderbird 2.0.0.4, MS Outlook Express 6 and Mutt 1.4.2.1i - all rendered <LF> in the decoded text as a line break. The fifth - Qualcomm Eudora 5.2 (very old) - didn't decode the base64 encoded text at all, it just displayed the raw base64 encoded data.

-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Ivan Van Laningham wrote:

I think something else is going on, besides just the <LF> only line ending. I'm using two versions of T-Bird, 1.5 and 2.0 something, and both display the message concerned the same way, all crammed together on a single line. I think there must be some encoding issue. It probably is some configuration issue with T-Bird, but I've not been able to find it.

I can't find any relevant configuration setting in T-Bird, and I don't see the problem in T-Bird 2.0.0.4 with a utf-8 charset base64 encoded message I received through a test list. The message contained the following

This should be a unicode encoded message.

Throw in a few “funny” chars

To get encoding

The lines of dashes are separate lines and in between are a line of text, an empty line, a second line of text, a second empty line and a third line of text. I'm sending this in utf-8 charset (I hope), and it should come from the list encoded base64, and I expect it will display as described in my T-Bird 2.0.0.4. What do you see?

-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Hi everyone. Just as a followup, Katrina on the Eudora list I am on came up with a UTF-8 decoder plug-in. http://windharp.de/software/utf8iso.htm

Stephen J. Turnbull wrote at 07:22 PM 06/26/2007:

Mark Sapiro writes:

...

I don't know if there is a standard that says your MUA 'should' recognize a single <LF> in the decoded text as a line break,

Since it's in UTF-8, Unicode does, Technical Annex #14. Conformance is required by Unicode 4.0.

Of course if the MUA doesn't claim conformance to Unicode there's no requirement, and AFAIK there's nothing in RFC 2822 or the MIME RFCs that requires conformance to any text standard beyond ASCII. However, most Unicode requirements are considered "best current practice".

Michael Welch, volunteer Redwood Alliance PO Box 293 Arcata, CA 95518 707-822-7884 mwelch@redwoodalliance.org www.redwoodalliance.org