Email Header too Long

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.

Lines of quoted-printable encoded data must not be longer than 76 characters. To satisfy this requirement without altering the encoded text, soft line breaks may be added ... These soft line breaks also allow encoding text without line breaks (or containing very long lines) for an environment where line size is limited, such as the "1000 characters per line" limit of some SMTP software, as allowed by RFC 2821.

-- 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".

Is this valid e-mail, or is it an attempt to exploit delivered-to 'bouncing'? Is it something like that described here.

Summary:

Notice that delivery address is the same as the Delivered-To address. Next, postfix accepts the message, as being local and for an existing user, and then it immediately sees the Delivered-To header and it decides there is a mail forwarding loop going on and it bounces that message to the forged sender address.

Otherwise, it sounds like someone in the mail chain is incorrectly adding delivered-to headers. Normally, I'd suggest the typical 'be generous in what you accept' approach, but in this case, doing that could lead to mail loops, which is what the header is there to avoid. I'd check first to see if it's not something slightly more sinister, and if it's genuine, I would tell your users it's a bug on the sending site (maybe mail being forwarded by a tool which isn't stripping an existing delivered-to address, i.e. already delivered mail being forwarded).