Mailing List Archive

Small fix in pipe.c
Hi all,

We've found a small error in insert_message_temp() in pipe.c.
The buffers strblock and tmpline were not initialised with '\0'
characters. Because of this, sending emails with an empty body resulted
in the message body possibly being filled with random characters (or
worse, characters from a previous message). This happened because the
strblock buffer was immidiately read from when the message body was empty.

A simple memset() did the trick.

I wonder if we have more of those possibly uninitialised buffers lying
around. :/

Ilja
Re: Small fix in pipe.c [ In reply to ]
The sizes returned through the msgsize, rfcsize, headerrfcsize, etc. variables
should all have been zero. So there's also a problem of assuming a non-binary,
null terminated message. Aren't now email programs encouraged to support
binary data nowadays?

Aaron


Ilja Booij <ilja@ic-s.nl> said:

> Hi all,
>
> We've found a small error in insert_message_temp() in pipe.c.
> The buffers strblock and tmpline were not initialised with '\0'
> characters. Because of this, sending emails with an empty body resulted
> in the message body possibly being filled with random characters (or
> worse, characters from a previous message). This happened because the
> strblock buffer was immidiately read from when the message body was empty.
>
> A simple memset() did the trick.
>
> I wonder if we have more of those possibly uninitialised buffers lying
> around. :/
>
> Ilja
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>



--
Re: Small fix in pipe.c [ In reply to ]
Aaron Stone wrote:

> The sizes returned through the msgsize, rfcsize, headerrfcsize, etc. variables
> should all have been zero.

I constructed a message with a header, but without a body. So the header
size and other sizes are not zero. Only the message body was empty.

ilja@test01:~/sandbox/dbmail$ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 test01.office.fastxs.net ESMTP Postfix (Debian/GNU)
HELO example.com
250 test01.office.fastxs.net
MAIL FROM:<foo@example.com>
250 Ok
RCPT TO:<bar@test01.office.fastxs.net>
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject:

.
250 Ok: queued as 249AD19F30A

This had the possibility of going wrong when the buffers were not set to
zero


> So there's also a problem of assuming a non-binary,
> null terminated message. Aren't now email programs encouraged to support
> binary data nowadays?
I have no clue actually.. :/

>
> Aaron
>
>
> Ilja Booij <ilja@ic-s.nl> said:
>
>
>>Hi all,
>>
>>We've found a small error in insert_message_temp() in pipe.c.
>>The buffers strblock and tmpline were not initialised with '\0'
>>characters. Because of this, sending emails with an empty body resulted
>>in the message body possibly being filled with random characters (or
>>worse, characters from a previous message). This happened because the
>>strblock buffer was immidiately read from when the message body was empty.
>>
>>A simple memset() did the trick.
>>
>>I wonder if we have more of those possibly uninitialised buffers lying
>>around. :/
>>
>>Ilja
>>
>>_______________________________________________
>>Dbmail-dev mailing list
>>Dbmail-dev@dbmail.org
>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>
>
>
>
>
Re: Small fix in pipe.c [ In reply to ]
> null terminated message. Aren't now email programs encouraged to support
> binary data nowadays?

I would guess so. rfc 2822 is much less restrictive on valid character
set in a message than 822. Eg. 822 did not allow NULL's in email, but
2822 does. dbmail is 822 compatible in that reguard, cause it strips
nulls out (which is nice for older OE clients, which die with them in
a message).

--
Jesse Norell

administrator@kci.net is not my email address;
change "administrator" to my first name.
--