Sharing a news story

[Phone]

Hi Bob thanks for the links. To tell you the truth if there wasn't such a catterwallin on the list the first time some dross showed up in one of my posts, I wouldn't care. I can live with a little dross myself.

I note that RFC stands for request for comments.

If I hadn't noticed that it appeared that charactars were being appended on send before being handled by the mail list software I might agree wholeheartedly that the list is at fault. Having made that comment, I'll also say this, if a linux hacker can't post to a hobbyist lug about making his linux device send plain text then where should they go.

It's not like there's a huge enterprise relying on absolute accuracy here. If there is such a thing as absolutly uniform behaviour in cross platform applications, I hardly ever see much of that.

As for taking this discussion offline, I could see that, if the list managers decide android is in fact not a linux. If it is, then we all know how to deal with list chatter we have no interest in.

Respectfully,
Ross
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Bob Jonkman <bjonkman-w5ExpX8uLjYAvxtiuMwx3w at public.gmane.org> wrote:

On 11-11-20 08:55 PM, waltdnes-SLHPyeZ9y/tg9hUCZPvPmw at public.gmane.org wrote:
> No trailing garbage at all. FYI, here's the raw message, with leading
> space inserted to avoid screwing up simple MUA's...
>
>_____________________________________________

> Date: Sun, 20 Nov 2011 13:54:54 -0500
> Subject: [TLUG]: Sharing a news story
> Message-ID:<edyds3onm8mm7ul27t4a8jvb.1321815294844-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf at public.gmane.org>
> From: Russ<rreiter91-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>
> To: "tlug-lxSQFCZeNF4 at public.gmane.org"<tlug-lxSQFCZeNF4 at public.gmane.org>
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: base64
> Sender: owner-tlug-lxSQFCZeNF4 at public.gmane.org
> Precedence: list
> Reply-To: tlug-lxSQFCZeNF4 at public.gmane.org
> X-Whitelist: Whitelisted (sender *@ss.org)
>
> SGVyZSBpcyB0b2RheXMgaG9yb3Njb3BlLiBBbnkgdHJhaWxpbmcgbm9pc2U/CgpodHRwOi8vbW9i
> aWxlLnRoZXN0YXIuY29tL21vYmlsZS9ob3Jvc2NvcGVzL2FydGljbGUvMTA3Nzk1NQ==
>
> --
> The Toronto Linux Users Group. Meetings: http://gtalug.org/
> TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
>_____________________________________________


It's a wonderful illustration of the problem: The headers declare that 
the text is Content-Transfer-Encoded with Base64 (a perfectly valid 
encoding for e-mail), but the contents of the message body includes the 
TLUG footer which is not encoded with Base64, thus corrupting the 
contents of the message body.

The problem is not the MUA that Ross is using, but the behaviour of the 
mailing list software. If it is going to add a footer, it should first 
decode the Base64 message body, add the footer, and then (optionally) 
re-encode to Base64. Or the mailing list software could re-transmit the 
message with Content-Type set to Multi-part/mixed, with the message body 
in one part and the TLUG footer in another part.

It is a different problem than trying to get a particular MUA to send 
with a particular Content-Transfer-Encoding, which seems to be what Ross 
et al. are trying to do. Even if you find a way to suppress Base64 
Content-Transfer-Encoding on your MUA it does not solve the problem of 
the mailing list software corrupting messages. Perhaps this MUA testing 
could be taken off-line.

--Bob.

MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for 
Specifying and Describing the Format of Internet Message Bodies 
https://tools.ietf.org/html/rfc1521

The Base16, Base32, and Base64 Data Encodings https://tools.ietf.org/html/rfc4648

--
The Toronto Linux Users Group. Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/legacy/attachments/20111120/fc5dd22a/attachment.html>