Subject: 2822upd <obs-FWS>
From: "Frank Ellermann" <[email-masked]>
To: [email-masked]
Date: Fri, 30 May 2008 15:32:03 +0200
List-Id: <ietf-822.imc.org>

Hi, in a 2616bis discussion about the wonders of "#" cum <LWS>
(= "ASCII art with commas") I mentioned how RFC 2822 + 2822upd
solved this by putting all multiple line foldings in <obs-FWS>
and saying that this is obsolete (MUST NOT generate), compare:

<http://tools.ietf.org/html/draft-resnick-2822upd-06#section-4.2> 

| FWS             =   ([*WSP CRLF] 1*WSP) /  obs-FWS
[...]
| obs-FWS         =   1*WSP *(CRLF 1*WSP)

Unless I miss something this could be made clearer with a "2":

| obs-FWS         =   1*WSP 2*(CRLF 1*WSP)
............................^

 Frank

Date: Fri, 9 May 2008 12:40:08 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: C-T-E: base64 and the real world.. what should an MUA do?
Cc: Tony Hansen <[email-masked]>, Florian Weimer <[email-masked]>, Valdis =?UTF-8?q?KlÄ“tnieks?= <[email-masked]>
Sender: [email-masked]

Florian Weimer writes:
> Actually, the RFC *requires* skipping non-base64 characters.

That requirement is considerably modified by the sentence after it:

    All line breaks or other characters not
    found in Table 1 must be ignored by decoding software.  In base64
    data, characters other than those in Table 1, line breaks, and other
    white space probably indicate a transmission error, about which a
    warning message or even a message rejection might be appropriate
    under some circumstances.

My code first tries to find the end of the base64 data (as intended by 
the sender, I mean). Only after finding an end does it call the base64 
decoder. It wasn't too difficult to write.

Arnt

Date: Thu, 08 May 2008 23:23:27 -0400
From: Keith Moore <[email-masked]>
To: Paul Smith <[email-masked]>
CC: [email-masked]
Subject: Re: header un-folding & encoded headers
Sender: [email-masked]

it's simple:

1. white space between two adjacent encoded-words is not displayed.
2. white space between an encoded-word and an ordinary rfc822 atom is 
displayed.

Keith

Paul Smith wrote:
> 
> I'm just struggling slightly to work out how you're meant to handle the 
> following situation. It seems a bit inconsistent, so I want to check I'm 
> interpreting it right.
> 
> If I have a header
> 
> Subject: hello
> there
> (no space after 'hello' and one space before 'there')
> 
> I should unwrap that to
> 
> Subject: hello there
> 
> (one space between 'hello' and 'there' - ie just remove the CRLF as 
> stated in RFC 2822 2.2.3)
> Yes?
> 
> ----
> 
> If I have a header
> 
> Subject: =?us-ascii?Q?hello?= =?us-ascii?Q?there?> 
> (two encoded words with no spaces in them, and a space between them) I 
> should decode that to
> 
> Subject: hello there
> 
> Yes?
> (to be honest, I'm not entirely sure about this because 'Subject: 
> =?us-ascii?Q?hello?=there' (without a space) is illegal, so if you 
> wanted that would you use 'Subject: =?us-ascii?Q?hello?= there' instead 
> and expect the space to be stripped out or can you just not do it - 
> section 5(1) of RFC 2047 isn't clear whether the separating LWS is 
> retained or not)
> 
> ----
> If I have a header
> 
> Subject: =?us-ascii?Q?hello?> =?us-ascii?Q?there?> (no space after the encoded 'hello' and one space before the encoded 
> 'there')
> 
> As I read it, I should decode it to
> Subject: hellothere
> i.e. in this case I should discard the CRLF *and* the space, so I can't 
> just unwrap it, and then decode as the space would be kept then.
> 
> Yes?
> 
> ----
> If so, what about
> 
> Subject: hello
> =?us-ascii?Q?there?> 
> or
> 
> Subject: =?us-ascii?Q?hello?> there
> 
> Do I keep the space after the CRLF in these situations or not?
> 
> RFC 2047 seems to ignore this little side effect of header folding, 
> although it says that wrapping should be used to make sure that no 
> encoded-word is longer than 76 characters.
> 
> 

Date: Thu, 08 May 2008 16:22:25 -0400
From: Tony Hansen <[email-masked]>
To: Florian Weimer <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: C-T-E: base64 and the real world.. what should an MUA do?
Sender: [email-masked]

Please re-read the message that started this. It started by asking for 
strategies for dealing with poorly formatted messages where an 
intermediate mail reflector added in a signature at the end such as

	base64 stuff
	--
	this message went through the wringer

The text after the -- looks like base64, but when decoded as base64 
causes strange control characters to become part of the message.

Yes, the RFC requires skipping non-base64 characters. There's never been 
a question about that.

My email pointed out two things:

1) If there's an '=' character, you can *always* stop base64-decoding 
the body part right there. This is by definition of base64.

2) As a heuristic algorithm, instead of blithely skipping over 
non-base64 & non-whitespace characters, you *could* also stop 
base64-decoding at that point. My example was the "--" in the example 
message. However, doing so may cause other issues, your mileage may 
vary, and it's not a perfect solution.

3) If we were to update base64 (and I'm not suggesting that we should), 
it would be worthwhile adding an explicit end of sequence character that 
is *always present*. Right now we have the "=" sometimes present, but it 
isn't always there.

	Tony Hansen
	[email-masked]

Florian Weimer wrote:
> * Tony Hansen:
> 
>> If there's a padding "=" at the end of the base64, you can stop
>> processing right at that point. You *could* also stop processing when
>> you run into a non-whitespace character that isn't in the base64
>> alphabet, such as the "-" or ":" in your example. It's not perfect.
> 
> Actually, the RFC *requires* skipping non-base64 characters.

From: Florian Weimer <[email-masked]>
To: Tony Hansen <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: C-T-E: base64 and the real world.. what should an MUA do?
Date: Thu, 08 May 2008 21:46:54 +0200
Sender: [email-masked]

* Tony Hansen:

> If there's a padding "=" at the end of the base64, you can stop
> processing right at that point. You *could* also stop processing when
> you run into a non-whitespace character that isn't in the base64
> alphabet, such as the "-" or ":" in your example. It's not perfect.

Actually, the RFC *requires* skipping non-base64 characters.

Date: Thu, 08 May 2008 13:56:16 +0100
From: Paul Smith <[email-masked]>
To: [email-masked]
Subject: Re: header un-folding & encoded headers
Sender: [email-masked]

Paul Smith wrote:
>
> I'm just struggling slightly to work out how you're meant to handle 
> the following situation. It seems a bit inconsistent, so I want to 
> check I'm interpreting it right.
Don't worry about this, I've found what I needed hidden away in the 
examples at the end of RFC 2047... Sorry, I should have looked there 
first, but I was looking for a description of the behaviour in the text, 
not just the examples...

Date: Thu, 08 May 2008 12:12:23 +0100
From: Paul Smith <[email-masked]>
To: [email-masked]
Subject: header un-folding & encoded headers
Sender: [email-masked]

I'm just struggling slightly to work out how you're meant to handle the 
following situation. It seems a bit inconsistent, so I want to check I'm 
interpreting it right.

If I have a header

Subject: hello
 there
(no space after 'hello' and one space before 'there')

I should unwrap that to

Subject: hello there

(one space between 'hello' and 'there' - ie just remove the CRLF as 
stated in RFC 2822 2.2.3)
Yes?

----

If I have a header

Subject: =?us-ascii?Q?hello?= =?us-ascii?Q?there?
(two encoded words with no spaces in them, and a space between them) I 
should decode that to

Subject: hello there

Yes?
(to be honest, I'm not entirely sure about this because 'Subject: 
=?us-ascii?Q?hello?=there' (without a space) is illegal, so if you 
wanted that would you use 'Subject: =?us-ascii?Q?hello?= there' instead 
and expect the space to be stripped out or can you just not do it - 
section 5(1) of RFC 2047 isn't clear whether the separating LWS is 
retained or not)

----
If I have a header

Subject: =?us-ascii?Q?hello? =?us-ascii?Q?there?(no space after the encoded 'hello' and one space before the encoded 
'there')

As I read it, I should decode it to
Subject: hellothere
i.e. in this case I should discard the CRLF *and* the space, so I can't 
just unwrap it, and then decode as the space would be kept then.

Yes?

----
If so, what about

Subject: hello
 =?us-ascii?Q?there?
or

Subject: =?us-ascii?Q?hello? there

Do I keep the space after the CRLF in these situations or not?

RFC 2047 seems to ignore this little side effect of header folding, 
although it says that wrapping should be used to make sure that no 
encoded-word is longer than 76 characters.

-- 
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows