[net.bugs.usg] bugs in /bin/mail

matt@ncr-sd.UUCP (Matt Costello) (10/10/86)

I've found two bugs in the mail program recently, and thought
I'd share them.

The first occurs when mail is being forwarded to another system.
Running mail with no arguments causes it to print the address your
mail is being forwarded to, but first it checks that the mail file
is readable by group mail.  The check for readability is broken and
will complain unless the mode is exactly 0660.  The offending lines
are:

	if (!((stbuf.st_gid == MAILGRP) && ((stbuf.st_mode & 0777)== MFMODE))) {
		printf("Your mail cannot be forwarded.\n");
		printf("Check permissions and group id of mail file.\n");

A more appropriate check would be:

	if (!((stbuf.st_gid == MAILGRP) && ((stbuf.st_mode & 0440)== 0440)) &&
	    !(stbuf.st_mode & 0004) ) {


The second (and more serious) bug comes about because of the trouble
mail goes through to preserve null characters in mail.  Since it cannot
use strlen to find the length of an input line it searches for the
terminating newline that terminates the fgets function.  If the last
character of the mail input is not a newline, then the last line will
not have a newline to find.  In this case one or more bogus characters
will be written out.  The code fragments in question are:

	while (fgets(line, sizeof(line), f1) != NULL) {
		...  some code omitted here  ...
		n = strln(line);
		if (write(f2->_file,line,n) != n) {
			...  some code omitted here  ...
		}
	}

/*
*  strln - determine length of line (terminated by '\n')
*/
strln (s)
char *s;
{
	int i;
	for (i=0 ; i < LSIZE && s[i] != '\n' ; i++);
	return(i+1);
}

The simple solution is to use fread rather than fgets since it does
return the number of bytes read.

Now for the questions.  Why does mail go to so much trouble to preserve
nulls in a mail file?  Mailx aborts if it detects a null and vi strips nulls.
Does anybody know why mail does not remove them?  Does anyone see any
reason why stripping nulls would have a detrimental effect?

-- 
Matt Costello, matt@ncr-sd.SanDiego.NCR.com (not registered yet)
	{sdcsvax,dcdwest,ihnp4}!ncr-sd!matt

gnu@hoptoad.uucp (John Gilmore) (10/11/86)

In article <1196@ncr-sd.UUCP>, matt@ncr-sd.UUCP (Matt Costello) writes:
>                         Why does mail go to so much trouble to preserve
> nulls in a mail file? ...                           Does anyone see any
> reason why stripping nulls would have a detrimental effect?

Yes.  Mail should just act as a transportation mechanism without imposing
any meaning on the data being transported.  In particular, making
assumptions like "nobody would want nulls in a message" is imposing
a meaning ("Nulls are useless in mail messages").

In point of fact, if mail and news would carry nulls without trouble,
we would not have to uuencode binary programs to mail them to each other,
post them to the net, etc.  Since people started mailing binaries
around, this has been noticed, and I applaud the System V maintenance
team for fixing this in their /bin/mail.  Berkeley hasn't fixed it,
to my knowledge, and if Sun has fixed it (they know about it), they
haven't shipped the fixed release yet.

There are also problems with bytes in which the top bit is set, at
least in Sun/Berkeley mail.  Further problems appear if you send text
which has long stretches without newlines.  If anyone wants specific
bug reports, ask me for a copy -- or try it yourself!
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa
(C) Copyright 1986 by John Gilmore.             May the Source be with you!

lee@chinet.UUCP (Lee Morehead) (10/23/86)

In article <1196@ncr-sd.UUCP> matt@ncr-sd.UUCP (Matt Costello) writes:
>I've found two bugs in the mail program recently, and thought
>I'd share them.
>[....] Description of first bug not being addressed here.
>
>The second (and more serious) bug comes about because of the trouble
>mail goes through to preserve null characters in mail.  Since it cannot
>use strlen to find the length of an input line it searches for the
>terminating newline that terminates the fgets function.  If the last
>character of the mail input is not a newline, then the last line will
>not have a newline to find.  In this case one or more bogus characters
>will be written out.  The code fragments in question are:
>
>[....] Examples of C code.
>
>Now for the questions.  Why does mail go to so much trouble to preserve
>nulls in a mail file?  Mailx aborts if it detects a null and vi strips nulls.
>Does anybody know why mail does not remove them?  Does anyone see any
>reason why stripping nulls would have a detrimental effect?
>-- 
>Matt Costello, matt@ncr-sd.SanDiego.NCR.com (not registered yet)
>	{sdcsvax,dcdwest,ihnp4}!ncr-sd!matt

Yes. Certain commercial programs such as Qoffice can create an internal
document format which will contain null characters. If these null
characters are removed then the document format will be corrupted and
the resulting document may no longer be readable at the receiving end.

I have mucho problems with my people trying to read Qoffice documents
with mail. It will always leave the mail file with a length of one
character. This one character happens to be a null. The existance of
this null character will usually cause the next mail message to be
eaten because mail gets confused. That is one of the main reasons that I
converted to mailx; it aborts on NULL characters. Qoffice can, of course,
read it's own document format and a pure ASCII file. I tell most people
to use Qoffice only to read mail to avoid confusion.
-- 

					Lee Morehead
					...!ihnp4!chinet!lee

"One size fits all."
Just who is this "all" person anyway,
and why is he wearing my clothes?