Steps to reproduce: 1. Send a mail 2. Watch the network traffic with e.g. Ethereal Actual results: Null characters \0 are embedded in the end of the message. The receiving mail server barfs at the message, saying "/var/lib/imap/socket/lmtp[/var/lib/imap/socket/lmtp] said: 554 5.6.0 Message contains NUL characters (in reply to end of DATA command". This disables me to send mail to users on that server. Expected results: The message should not contain \0 characters as per RFC 2822 section 2.1: "A message [...] is comprised of characters with values in the range 1 through 127 and interpreted as US-ASCII characters [ASCII]". If the user somehow pastes a \0 character into the mail, it should be encoded (quoted printable or base64). Reproducibility: Sometimes it works, sometimes it doesn't. While testing today, all messages bounced due to \0 characters. Three different Thunderbird users in the office are experiencing this error. It happens with and without attachments. It happens with replies and mails, that are not replies. I see this problem with Thunderbird 0.8 and Mozilla 1.7a on Windows XP. Thunderbird is configured to use regular unencrypted SMTP, i.e. TLS is disabled. The receiving mail server is running Postfix. Postfix forwards the mail to SpamAssassin that delivers the mail into my Cyrus IMAP server using lmtp. Appearently it is lmtp that reports this error.
>I see this problem with Thunderbird 0.8 [...] Sorry, I meant Thunderbird 0.5.
Interesting problem. Unfortunately I can't reproduce it. I'd like to know, if the mail file to be send contains the nulls itself. You should be able to load the temp file in a hexeditor when you compose a message and click send, but get asked for the smtp password. For this you need to delete your outgoing password and restart TB or Mozilla first. The temp message should reside in the systems temp folder (depends on system) while the password dialog is displayed.
Created attachment 142420 [details] Mail file grapped from temp folder while waiting for SMTP password Yes, the nulls are also present in the temporary file.
Sorry, I must have looked at something else - the nulls are NOT present in the temp file.
Thanks so far. Did you control that nulls where present on the wire when this mail was sent? It's interesting that the nulls in mail from your ethereal screenshot are before the final CRLF. So I expected them to be in the mail file too. So it's necessary to know if the mail whose temp file you examined contained nulls on the wire.
I think I did verify that the nulls were present on the wire using Ethereal. And the mail bounced with the usual error message - I still have the bounce mail so I am sure.
I tried sending some mails with attachments. Sometimes five nulls are added immediately after the closing MIME boundary: \r\n --------------000009020000060703070400--\000\000\000\000\000\r\n .\r\n Sometimes, instead of five nulls, ".\r\n\r\n" is inserted (or - interpreted differently - "\r\n.\r\n" is transmitted after the message has been sent and before the QUIT command is sent): --------------030809080609060503050009--\r\n .\r\n \r\n .\r\n This confuses the sending SMTP server. When it receives the first period, it returns "250 OK". But the empty line and the following period makes it return two "500 Unrecognized command".
Did you notice the problem in former version of Mozilla or TB (if you used the software before)? And are the nulls inserted always 5? And one or two further tests for nulls in the tempfile would be nice, if not to expensive. But I must confess that I've no clue what's going on and never heard of this problem before.
The problem also occurs with Thunderbird 0.4 on this machine. It also occurs with a brand new profile. I did four additional tests, and I still don't see null bytes in the temp files. It looks as if it always 5 bytes that are padded. Today I also noticed "\0\0\0\r\n" being padded. And as mentioned in comment 8, I have earlier seen a padding of "\r\n.\r\n". It looks as the first mail after a restart of Thunderbird always have 5 nulls padded.
Do you have any anti virus software, personal firewall or proxy running on your machine (resp. on the users machines experiencing this problem)?
Yes! We are using Panda Titanium Antivirus 2004 in the office. Appearently the problem only occurs when Panda is running. It occurs even if "automatic antivirus protection" is disabled (in this case, the Panda icon in the systray is grayed out). If I choose "Close automatic protection" by right-clicking on the Panda icon in the systray, the icon disappears, and the problem no longer occurs. I will report this problem to Panda Software. Thanks for helping me determine the cause of the problem :-) I am marking this bug INVALID.
The problem also occurs with Outlook Express, so it is probably a general problem with Panda.
For whatever reason AV tools sometimes change the data stream. :-/ But good news for Moz, thanks.
FYI, last night Panda Software released a software update that was installed automatically and now the problem appears to be fixed.
We're now tracking such bugs. This doesn't mean it's something we can fix, merely something we hope to be able to point vendors to so they can investigate. This is an automated message.
Closing old bugs in the Plugins component. We aren't going to track issues in 3rd-party plugins in the Mozilla bug tracker. In addition, support for NPAPI plugins will be removed at the end of this year; for more details see the post at https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/ If there is a serious bug in Firefox, it needs to be filed in the "Core" product, "Plug-Ins" component.