Thunderbird was inadvertently upgraded to v102.1.1, now all mail bounces - SMTPSEND.BareLinefeedsAreIllegal
After upgrading to Thunderbird 102.1.1 - Remote Server returned '550 5.6.11 SMTPSEND.BareLinefeedsAreIllegal; message contains bare linefeeds, which cannot be sent via DATA and receiving system does not support BDAT' appears in returned message upon bounce. All suggestions found online recommend having recipients make changes to accept badly formed messages. We view that as totally impractical. We tried downgrading, but the only result was to lose the profiles. Now, end user is frantic. Please advise. Thank you, Fred
Modified by Wayne Mery
All Replies (8)
Hi, does this happen to every message, or when sending some specific attachments?
I don't think SMTP code has big changes between 91 and 102. Would be great if you can test on 91, you can create a new profile for testing.
I have the same problem on Windows 11 with Thunderbird v. 91.5.1 (64 bits) running in French. I send the mail from a hotmail.com account.
Not all the mails give this problem: If I send mails to hotmail or gmail accounts, I don't get the problem. In my case, I only get the problem sending an email to a yahoo.com user (even if the title is "Test" and the text simply "Test" too.
If I use the outlook.com web interface to send the mail to the same person, I don't get the problem.
I just changed from Windows 10 (a few weeks ago) because I had a computer problem and it was running fine on Windows 10 in June.
User became too frustrated with Thunderbird and was not happy with Outlook interface on the web, so she changed to using her Gmail.com account and is currently importing the contacts from her Outlook account. Not the solution we wanted to deliver, but the client was not happy with the other choices presented. Thank you, Ping and Jeany, for your thoughts and suggestions.--fwh
I am having the same problem. In my case, emails using a Microsoft Exchange Server, IMAP protocol, and the latest update to Thunderbird is when it started.
The reason only some emails bounce is related to the email receiving users email server. It IS illegal to send bare linefeeds and has been for like forever, but not all but some servers actually reject emails that have bare linefeeds like that. Hence the reason why some emails are bouncing back with NDR's and some not. You can read more about this specific problem here:
In the meantime, this problem is 100% Thunderbird related for not adding the customary <crlf> to each break in the page. As an old school programmer, this problem stems back to the 1980's when the whole problem began. Carriage Returns and Linefeeds are found on the American Standard Characters II chart (ASCII chart) defined as the 10th and 13th character respectively. Both CR and LF's are similar in purpose but have been used somewhat differently in different printers, platforms, and applications such as email programs. Even today, the problem of whether a document is formatted with just linefeeds, carriage returns, or both still exists. As well as the confusion of when to use either. It is also attributed to the double spacing problem that you see in some email programs when receiving emails from people using often 3rd party apps where they count both the CR and LF as a double spaced presentation on the document.
Some users pointed out disabling Avast fixed the problem https://bugzilla.mozilla.org/show_bug.cgi?id=1783559#c11. Do you happen to be using Avast as well?
A mi me pasa solo cuando envió correos desde la cuenta de Hotmail. Con la cuenta de Gmail no da error. Llevo años con TB y es el primer problema que tengo desdes que actualicé 102.1.2. Espero se solucione pronto, mientras tanto envío los correos desde el iphone.
Hi, I tried sending a simple mail to my other email address ans had the problem, receiving the postmaster error message. I disabled the Avast Mail Agent and resent the same email and the mail was sent correctly. I reported the issue to Avast today.
Finaly, Avast 22.8.6030 (version 22.8.7500.749) - Interface version 1.0.724 solves the problem.