Null (\0) characters are added to body when sending (bug in Panda Antivirus)

RESOLVED INCOMPLETE

Status

Plugins Graveyard
Panda AV
RESOLVED INCOMPLETE
14 years ago
a year ago

People

(Reporter: Christian Schmidt, Unassigned)

Tracking

Details

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
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

14 years ago
Created attachment 142251 [details]
Screendump of Ethereal showing the \0 characters
(Reporter)

Comment 2

14 years ago
>I see this problem with Thunderbird 0.8 [...]
Sorry, I meant Thunderbird 0.5.

Comment 3

14 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

14 years ago
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.
(Reporter)

Comment 5

14 years ago
Sorry, I must have looked at something else - the nulls are NOT present in the
temp file.

Comment 6

14 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

14 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

14 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

14 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

14 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

14 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

14 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
Last Resolved: 14 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

14 years ago
The problem also occurs with Outlook Express, so it is probably a general
problem with Panda.

Comment 14

14 years ago
For whatever reason AV tools sometimes change the data stream. :-/
But good news for Moz, thanks.
(Reporter)

Comment 15

14 years ago
FYI, last night Panda Software released a software update that was installed
automatically and now the problem appears to be fixed.
Product: MailNews → Core
(Assignee)

Updated

9 years ago
Product: Core → MailNews Core

Comment 16

7 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

a year 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
Last Resolved: 14 years agoa year ago
Resolution: --- → INCOMPLETE
(Assignee)

Updated

a year ago
Product: Plugins → Plugins Graveyard
You need to log in before you can comment on or make changes to this bug.