Sending to "orange.fr" gets message "SMTP error from remote server for TEXT command, host: smtp-in.orange.fr (80.12.242.9) reason: 552 5.2.0 Invalid 7bit DATA
When sending to adresses on "orange.fr" & "wanadoo.fr" I get a refusal message "SMTP error from remote server for TEXT command, host: smtp-in.orange.fr (80.12.242.9) reason: 552 5.2.0 Invalid 7bit DATA". This is a new problem with this provider (orange and wanadoo are the same provider) but maybe there's something I can tweak in Thunderbird? Text encoding for send and receive is set to Unicode (UTF - 8)
Vybrané riešenie
Good news! I have now received receipt confirmation from several addresses which systematically bounced before. We can call the problem solved. Many thanks for your insight Matt. To save people scrolling back up, here is Matt's link to the fix https://bugzilla.mozilla.org/show_bug.cgi?id=1495564#c4
Čítať túto odpoveď v kontexte 👍 0Všetky odpovede (15)
Please post a screenshot of your Thunderbird font setting.
At the top right of the Thunderbird window, click the menu button > Options > Display > Formatting > Fonts & Colors > Advanced
https://support.mozilla.org/kb/how-do-i-create-screenshot-my-problem
Are you using a templates for composing messages?
Upravil(a) christ1 dňa
Here is a screenshot. Maybe you can see something? As well as this, I have confirmed that I can send the same mails using GMX's webmail so it rather looks as though the problem lies in Thunderbird and not with orange.fr
Sorry, just saw the rest of the post. No, not using templates.
Your font settings look good. As a test, can you try to change the encoding for outgoing mail from UTF-8 to Western (ISO-8859-1)?
Is there any difference?
I'm afraid not. The mail is still rejected with the same message.
This must be a Thunderbird problem. I am having the same problem. 1and1 tried to see if there was anything on their end to fix but nothing worked. If I send the same email from yahoo it works fine. Please fix this problem Thunderbird!
I really don't know whether this is caused by Thunderbird or Orange/Wanadoo. Did this start out of the blue? Are you doing anything different than you did do before? Have you made any changes to your Thunderbird setup (except those for troubleshooting the problem)? It may well be related to changes at Orange/Wanadoo. You may try to look at their support forum if there are any more complaints. If so, this may give a clue.
This problem came out of the blue with no changes in Thunderbird setup. Remember that I can send the same message successfully from Webmail (same text, same photo, same sending address, same destination adress.) In view of the post from luck589 above, relating to 1and1, the single common factor would appear to be Thunderbird. I don't think 1and1 and orange are related but I'll stand corrected. However, we know that several ISPs have been tightening up on security recently and what got through the net previously (maybe bending the rules a little) doesn't any more.
Might it be significant that all the rejected messages contain diacriticals (accented letters)? My understanding is that these need 8 bits.
Does lucky589 also use diacriticals?
No, I do not have any accented letters. I was able to get a brand new email out after following the below actions. BUT when I replied to the email response I again received a bounce back with the error: 552 5.2.0 Invalid 7bit DATA.
I did try 2 things today and emails are going through to the addresses that were bouncing back.
1. went into fonts and changed the outgoing mail from Unicode (UTF-8) to Western (ISO-8859-1).
2. First I removed the signature text (for the signature block).
3.Tried an email with success.
4.re-did signature block to be HML format.
5.Test also wroked.
6. Note: I did NOT use the same email message that bounced the prior times as it contained the old signature block.
7.Also note: My signature block had not changed in years prior to changing it today.
I will keep you posted as to whether or not I continue to have this issue.
thank you, Lucky 589
Upravil(a) lucky589 dňa
A SMTP 552 email error typically occurs when there is a problem with an attachment. Try View (Alt-V) -> Message Source or Ctrl-U to look at the raw source of your copy of the sent message. See if it contains a Content-Transfer-Encoding: header (after the message body) set to 7bit, 8bit or base64. The error would occur if it's set to 7bit.
An example:
A172C71360C80049028CC8C6 Content-Type: text/plain; charset=utf-8; format=flowed *Content-Transfer-Encoding: 8bit*
Also, if you're normally composing in HTML, try to compose and send the message in plain text instead. At the top right of the Thunderbird window, click the menu button > Options > Composition > Send Options Check "Send messages as plain text if possible".
Here is a copy from the source code of one of the blocked messages: >snip Content-Type: multipart/alternative;
boundary="------------DA476A667952643829EB6045"
Content-Language: fr-xx-classique
This is a multi-part message in MIME format.
DA476A667952643829EB6045
Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit >unsnip "Send messages as plain text if possible" is checked
Bug 1495564 appears to have the same error message, but a different mail provider.
Perhaps you could try my suggestion in comment 4 of the bag and see if it has any effect at all. (It might be a complete failure)
Sorry for the silence guys. I have followed Matt's suggestion to modify the Config Editor (mail.strictly_mime) and then sent several mails asking for delivery confirmation. One week on, I have no bounces but also no delivery confirmations. So it's looking hopeful but I shall have to ask again for delivery confirmations. Been travelling for the last week so this has waited for me to get back to my desk. Fingers crossed!
Vybrané riešenie
Good news! I have now received receipt confirmation from several addresses which systematically bounced before. We can call the problem solved. Many thanks for your insight Matt. To save people scrolling back up, here is Matt's link to the fix https://bugzilla.mozilla.org/show_bug.cgi?id=1495564#c4