Sykje yn Support

Mij stipescams. Wy sille jo nea freegje in telefoannûmer te beljen, der in sms nei ta te stjoeren of persoanlike gegevens te dielen. Meld fertochte aktiviteit mei de opsje ‘Misbrûk melde’.

Mear ynfo

Dizze konversaasje is argivearre. Stel in nije fraach as jo help nedich hawwe.

BUG REPORT and workaround - TBrd parses Name incorrectly and server refuses message

  • 5 antwurd
  • 1 hat dit probleem
  • 5 werjeftes
  • Lêste antwurd fan JKEngineer

more options

I am reporting a problem and its apparent cause. Versions of TB later than 31.7 were not able to send email. I have determined that it appears that TB was parsing the Your Name field: "Name @ Place" by removing the spaces. This caused the server to refuse the mail based on a "syntax error". Here's part of the error message (edited to remove actual names):

2016-02-18 12:25:32 1aWUCi-0005uw-Ou H=([192.168.1.2]) [72.80.225.42]:49323 X=TLSv1.2:DHE-RSA-AES128-SHA:128 F=<email@domain.org> A=dovecot_plain:email@domain.org rejected after DATA: syntax error in 'From:' header when scanning for sender: malformed address: <email@domain.org> may not follow Name@Place in "Name@Place <email@domain.org>"

Note the conversion of "Name @ Place" in Your Name to "Name@Place" in the error message. Changing this in the TB setup to "Name at Place" fixed the error.

I am reporting a problem and its apparent cause. Versions of TB later than 31.7 were not able to send email. I have determined that it appears that TB was parsing the Your Name field: "Name @ Place" by removing the spaces. This caused the server to refuse the mail based on a "syntax error". Here's part of the error message (edited to remove actual names): 2016-02-18 12:25:32 1aWUCi-0005uw-Ou H=([192.168.1.2]) [72.80.225.42]:49323 X=TLSv1.2:DHE-RSA-AES128-SHA:128 F=<email@domain.org> A=dovecot_plain:email@domain.org rejected after DATA: syntax error in 'From:' header when scanning for sender: malformed address: <email@domain.org> may not follow Name@Place in "Name@Place <email@domain.org>" Note the conversion of "Name @ Place" in Your Name to "Name@Place" in the error message. Changing this in the TB setup to "Name at Place" fixed the error.

Alle antwurden (5)

more options

'@' has a very special significance in email addresses, as I'm sure you're aware. I'm surprised anyone would even think about using it in the display name.

RFC 2822 lists '@' as a "special" and hints that you could use it but need to escape it with a \.

Did you wrap your name with its included spaces in inverted quotes?

more options

I did not do anything special in the older versions. Just entered "Name @ place" without quotes into the Your Name box of the account set up. It worked fine. I ran into problems when I upgraded to a later TB version.

The combination of the server error message and a recognition that @ is a special character is what allowed me to get it working again.

I'm reporting it as a bug because it worked and then did not.

I will test using it with quotes (not sure what you mean by inverted quotes) and with a \ in front of the @ and report back.

more options

Test results: Using Name \@ Place for Your Name goes through, but displays as Name Place (no @ sign). Using "Name @ Place" and 'Name @ Place' do not go through.

Are any of these what you meant by inverted quotes?

Is it possible that the later versions of TB are removing the spaces around the @ and thereby causing the problem when the older version did not?

more options

I'm not clear whether your problem is using the interesting label as the sender or as the addressee. I've made it work both ways round with the escape. Interestingly, while Thunderbird insists on collapsing the spaces, other mail clients (for example those on my Android tablet) preserve them. Since display names are not important to routing, I'd be surprised if it turned out that the spaces matter.

Thunderbird doesn't seem to encourage us to worry about quotation marks. It seems it builds the display name and applies them if needed.

I'm not sure it's a bug. It seems to me that Thunderbird is now more compliant with the standard.

I think your problem was the @ and not the spaces.

more options

Thanks for your help (belatedly - should have said that immediately).

I'm not really sure whether to blame the loss of spaces or the @. I am happy to leave my system using "at" instead, since it works.

If it's your belief that this should not be considered a bug, I am willing to accept your judgement on it. It's well beyond my expertise.