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"
<reply-fe8d15767c6c067e70-32888_HTML-80821681-6368648-1233@e.consumercellul
ar.com>
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 "ar.com" to the address, it just bounces with an illegal To:.
RFC 5322, sect. 2.2.3. "Long Header Fields" (<https://tools.ietf.org/html/rfc5322#section-2.2.3>) says: <quote> 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 WSP. </quote> IOW, after unfolding the complete header line looks like Reply-To: "Consumer Cellular" <reply-fe8d15767c6c067e70-32888_HTML-80821681-6368648-1233@e.consumercellul ar.com> 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 Balsa. Hope this helps, Albrecht.
Attachment:
pgpUfsY3Id_qg.pgp
Description: PGP signature