Re: Famous Hacker Uses Challenge-Responses

From: *Vanguard* (lh_vanguard_at_mailblocks.com)
Date: 07/16/04 

Date: Fri, 16 Jul 2004 01:08:33 -0500

"Sam" <sam@email-scan.com>
wrote in news:cone.1089942945.272161.25519.500@commodore.email-scan.com:

> Before you start to lecture someone about MIME, it helps if you actually try
> to understand what MIME is. Obviously, you don't.
<snippy>
> Plain text, E-mail messages had a carriage return/line feed pair at the end
> of every physical line. And paragraph breaks were completely empty lines.

Yep, so far your description matches Quoted-Printable which DOES have the CR-LF sequence at the end of the line to provide a line break.

> Did you get that part? Did you let that sink through your head? Carriage
> return/linefeed at the end of every line. Empty line to delimit paragraphs.
> Before going any further, wrap your brain around that simple concept.

Yup, yup, uh huh, which way did he go, George, which way did he go? Uh huh, uh huh. Guess that'll make you happy. Just because I won't shut up or roll over simply because someone declares they know better doesn't mean I'm dumb. It means I require them to prove their point. I'm still trying to accumulate enough through the numerous posts to feel that their arguments are then my arguments, too. I'm not a lemming that just agrees with anyone but need some convincing which means I have to know, too. That's the learning process that I'm in now. The nose thumbing does wear thin after awhile, though, and detracts from the credence of the argument.

<snip>
> A properly-written MIME processor, takes the output of the Microsoft
> shitware you're running, and removes those "soft returns". What it ends up
> is a huge, single line, over a thousand characters long. Each individual
> paragraph in your message decodes to a single line of text, a thousand
> characters (or so) each.

So this "properly-written MIME processor" mangles the MIME formatted content so it is no longer RFC compliant by converting is physical representation to what should only be its logical representation as rendered by the client. So after it gets mangled by removing the trailing "=<CRLF>" how can it still be considered in Quoted-Printable format as delivered to the client? It has been converted to a different format.

> Your messages do not logically consist of individual lines of text, 80-or-so
> characters each, with a blank line between paragraph breaks. In every one
> of your horribly broken E-mail messages each paragraph is a single, huge,
> line of text. This is how the output of your Microsoft shitware looks to
> every MIME processor.

So every MIME processor alters the raw data to alter its encoding by stripping out the "=<CRLF>"?

> Now, some mail clients may choose to simply cut off all text that exceeds
> their display width. Other mail clients may choose to wrap these humongous
> lines within the alloted display width, without concern for word breaks.
> Still other, more sophisticated clients, will try to compensate for your
> shitware's brain damage by trying to word-wrap these huge lines of text
> within their alloted display. However, each one of these alternatives is
> technically valid. If, as a result, your messages look like ***, it is not
> their fault. Your messages were broken to begin with.

But you just said my messages were one big long humongous line rather than being broken by line breaks. Apparently sending in Quoted-Printable format means, according to you, that every MIME processor will mangle the encoding format and converting my paragraph that is composed of lines physically limited to under 76 characters and ending with CR-LF into one long line equated to its logical representation. Well, then I can understand why some clients will truncate at their window width. For those that wrap at the window width on a character rather than parsing on a word means they may be technically correct (i.e., simply the "code behaves as written") but neglects that the content is intended for human consumption and humans read by words, not characters.

> The proper way to specify “soft” line breaks, and “hard” paragraph breaks,
> is specified by RFC 2646. My messages, for example, follow that
> specification, and any MIME-aware processor that implements RFC 2646 will be
> able to re-wrap my messages within whatever line width it uses, preserving
> paragraph breaks.

I've got a link to RFC 2646 and that's the next one I'll read. But then other claimed wizards also noted http://www.ietf.org/internet-drafts/draft-ietf-usefor-useage-00.txt which does address using Quoted-Printable within usenet posts. Does this RFC and I-D conflict with each other? *If* so then which am I supposed to believe? RFC 2646 ratified in 1999 or the draft (which I'm told is based on de facto standards) dated May 2004? Since both mention "format=flowed" and other posters have mentioned this, then this appears the key to compatibility (to clue the clients to wrapping but which seems obviously from the encoding which I didn't know got mangled).

> But -- and this is the crucial part that you need to absorb -- my
> quoted-printable messages, still decode to ordinary plain text, each line no
> more than 80 characters long. Still, any RFC 2646-aware client can do the
> right thing and adjust this text to any logical line width.

Could you post another message but WITHOUT the PGP signing? You and I already discussed this before that OE has a defect in that your PGP-signed posts get treated as attachments (I had to copy and paste to this post from the .txt attachment that OE displays for your post). I think it's a result of OE not obeying the "Content-Disposition: inline" directive maybe from Microsoft being overly protective. So I cannot see the raw format of your message to see how yours differs from what is described by RFC 2045 and what appears to be generated by OE. Can you issue a single post without PGP or disable it temporarily to post without PGP so I could see what I get from the news server for the raw format of your non-PGP signed post? I can see the raw content but would like to see it without the PGP overhead to focus on just what you are talking about. Thanks.