In RFC 2822 (defining E-Mail) is defined, that no line SHOULD be longer than 78 chars (excluding CRLF) and MUST not longer than 998 characters. With quoted-printable longer lines will be broken into more lines, ending each with a '=' until the real linebreak is reached. Conforms a mail to the standard, if it contains lines longer than 78 (or 998) characters but is encoded with quoted-printable?
There are arguments, that this isn't compliant, because the receiving mail-client has longer lines after decoding the quoted-printable message.
EDIT: To clarify the question in the way as asked by David Cary: Yes, I mean the quote-printable encoded mail should be compatible to quoted-printable, means the lines are no longer than 76 characters. But the decoded messages may have longer lines than this limit. So my question is: Is client software implementing RFC 1521 supposed to handle indefinitely long lines after decoding quoted-printable text content? This is answered yes with both answers so far (thanks) with the restriction that it is discouraged by Netiquette (RFC 1855). But Netiquette even limits a line length to 65 characters, a limit nearly nobody adheres to.
It's definitely compliant. The whole point of Quoted-Printable, and the rest of the MIME series of RFCs (RFC 2045 through RFC 2049), is to allow the encoding of data that otherwise would not be valid in e-mail. RFC 2822 explicitly (and repeatedly!) points readers at those RFCs for information on how to do this.
I'm not sure what you are asking:
a receiving mail client finds long lines before decoding quoted-printable
Say the quoted-printable encoding software on the transmitting end simply quoted non-printable letters, making the resulting encoded line longer than the original line, without ever adding "soft line breaks", resulting in an encoded line longer than the limit.
This is non-compliant.
-- Wikipedia: quoted-printable, paraphrasing RFC2045 Page 21.
the encoded lines are short, but a receiving mail client finds long lines after decoding quoted-printable
That is compliant with RFC2822 and RFC2045, and should be supported by all software.
However, creating such messages is discouraged by several Netiquette Guidelines, including Page 3 of RFC 1855 "Netiquette Guidelines".
If you really want to know how complicate it is to built a compliant email composer and parser, then you must watch this video on Youtube: http://www.youtube.com/watch?v=JENdgiAPD6c
Ricardo Signes gives inside views on different RFCs and what stupidity they bring into the real life.
It is 40 minutes long and only scratches the surface of bad and good email "content". After watching you will change your opinion about the email software you thought that it conforms to email standards.