Re: truncated heading

Hi Jack:

Am 06.09.16 23:53 schrieb(en) Jack:
Messages I get from my cell phone provider include (copied/pasted from "show source")

From: Consumer Cellular <reply e consumercellular com>
Reply-To: "Consumer Cellular"

When I show all headers, however, the "Reply-To:" shows
Consumer Cellular <reply-fe8d15767c6c067e70-32888_HTML-80821681-6368648-1233@e.consumercellul>

So - where is this truncation happening?  It does seem due to the header being wrapped to three lines - but I'm not sure what is 
legal here, and whether the problem is with the sender or with balsa.  It causes me grief, because if I "Reply" to a 
message, unless I remember to add the "" to the address, it just bounces with an illegal To:.

RFC 5322, sect. 2.2.3. "Long Header Fields" (<>) says:

   Each header field is logically a single line of characters comprising the field name, the colon, and the field body. 
 For convenience however, and to deal with the 998/78 character limitations per line, the field body portion of a 
header field can be split into a multiple-line representation; this is called "folding".  The general rule is 
that wherever this specification allows for folding white space (not simply WSP characters), a CRLF may be inserted 
before any WSP.
The process of moving from this folded multiple-line representation of a header field to its single line representation 
is called "unfolding".  Unfolding is accomplished by simply removing any CRLF that is immediately followed by 

IOW, after unfolding the complete header line looks like

Reply-To: "Consumer Cellular" <reply-fe8d15767c6c067e70-32888_HTML-80821681-6368648-1233@e.consumercellul>

However, according to RFC 5322, sect. 3.4.1. "Addr-Spec Specification", the TAB char in the mail address is 
not allowed...

I think the sending MUA simply creates a malformed reply-to: header, probably because it strictly wants to 
limit the line length to 78 chars (although the absolute maximum limit is actually 998, see RFC 5322, sect. 
2.1.1).  I guess the reply message in your sentbox (i.e. what Balsa produced) will have the full address 
unsplit, even though the line is longer than 78 chars.

In short, I think the header you received is a violation of the standards, and thus noting we can fix in 

Hope this helps,

Attachment: pgpUfsY3Id_qg.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]