John Fawcett wrote:
> 
> I think the correct place to strip nuls is:
> spool.c: spool_copy_msg
> 
> To be consistent should this change also be made to:
> message.c: message_copy_strict
> 
> Any other ideas or comments which would help with making a patch?
> 
> thanks
> John

I've taken a look at the modifications needed to spool_copy_msg()
in spool.c.

It makes use of the prot_fgets() function which seems not
capable of handling embedded nuls. The fact that there are
embedded nuls can be identified but nothing can be done about it
since there is no information about the number of characters
in the buffer: the first nul encountered is interpreted
as end of the buffer.

I can see two approaches:
(1) make a new function which has the same functionality of
prot_fgets(), but returns the number of chars read.
I don't like this approach since it's adding further code
to the prot_*() layer which is so similar to the existing code
but returns an extra piece of info. It just highlights that
prot_fgets was not designed to work on strings with embedded
nuls.
(2) change spool_copy_msg() to use prot_read() calls instead
of prot_fgets(). prot_read() returns the number of characters
so is fully able to manage embedded nuls.
As the processing inside spool_copy_msg() is per line
processing this would require reworking so as to manage,
whole buffers at a time.

I think (2) is the best way. Any comments or suggestions?
Also does anyone know what message_copy_strict is for and
whether it should be updated too? It's the only other place
where I can see MESSAGE CONTAINS NULS being issued.

One further point: what about nuls in message headers?
As far as I can see spool_copy_msg() handles the body.
So it doesn't seem that lmtp messages with NULs in the
headers will produce the MESSAGE CONTAINS NULs rejections
anyhow. Any views about this or whether NULs in headers
have been a problem too?

John
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Reply via email to