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)

x86
Windows XP
defect
Not set
normal

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.
>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.
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.
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)
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.
Product: MailNews → Core
Product: Core → MailNews Core
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
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 ago8 years ago
Resolution: --- → INCOMPLETE
Product: Plugins → Plugins Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: