Closed
Bug 235589
Opened 20 years ago
Closed 8 years ago
Null (\0) characters are added to body when sending (bug in Panda Antivirus)
Categories
(Plugins Graveyard :: Panda AV, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: bugzilla.mozilla.org-3, Unassigned)
Details
Attachments
(2 files)
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.
Reporter | ||
Comment 1•20 years ago
|
||
Reporter | ||
Comment 2•20 years ago
|
||
>I see this problem with Thunderbird 0.8 [...]
Sorry, I meant Thunderbird 0.5.
Comment 3•20 years ago
|
||
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.
Reporter | ||
Comment 4•20 years ago
|
||
Yes, the nulls are also present in the temporary file.
Reporter | ||
Comment 5•20 years ago
|
||
Sorry, I must have looked at something else - the nulls are NOT present in the temp file.
Comment 6•20 years ago
|
||
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.
Reporter | ||
Comment 7•20 years ago
|
||
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.
Reporter | ||
Comment 8•20 years ago
|
||
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".
Comment 9•20 years ago
|
||
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.
Reporter | ||
Comment 10•20 years ago
|
||
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.
Comment 11•20 years ago
|
||
Do you have any anti virus software, personal firewall or proxy running on your machine (resp. on the users machines experiencing this problem)?
Reporter | ||
Comment 12•20 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Summary: Null (\0) characters are added to body when sending → Null (\0) characters are added to body when sending (bug in Panda Antivirus)
Reporter | ||
Comment 13•20 years ago
|
||
The problem also occurs with Outlook Express, so it is probably a general problem with Panda.
Comment 14•20 years ago
|
||
For whatever reason AV tools sometimes change the data stream. :-/ But good news for Moz, thanks.
Reporter | ||
Comment 15•20 years ago
|
||
FYI, last night Panda Software released a software update that was installed automatically and now the problem appears to be fixed.
Updated•20 years ago
|
Product: MailNews → Core
Assignee | ||
Updated•15 years ago
|
Product: Core → MailNews Core
Comment 16•13 years ago
|
||
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.
Assignee: sspitzer → nobody
Status: RESOLVED → UNCONFIRMED
Component: Networking: SMTP → Panda AV
Ever confirmed: false
Product: MailNews Core → Plugins
QA Contact: nbaca → panda-antivirus
Resolution: INVALID → ---
Version: Trunk → unspecified
Comment 17•8 years ago
|
||
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.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 8 years ago
Resolution: --- → INCOMPLETE
Assignee | ||
Updated•8 years ago
|
Product: Plugins → Plugins Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•