Re: (Not-so) hypothetical question: What to do about NULs?
Thus said Ken Hornstein on Wed, 22 Feb 2023 20:59:31 -0500: > I had an inkling popular MTAs would DTRT. Well, qmail's hardly "popular" these days, but Professor Bernstein had a penchant to make string handling robust to avoid exploits, so he got NUL handling as a benefit. I run minority MTA with minority MUA (at least for as long as the email cartel continues to permit legitimate email). Andy
Re: (Not-so) hypothetical question: What to do about NULs?
>While POP's LIST does actually include the size of the message in bytes, >that's prior to any CRLF mangling that happens so it cannot be used >reliably as a method for determining when to stop reading. Unfortunate. Right, but that's mostly because of the way multiline responses are handled in POP. It's never "read X bytes", it's "read lines until you get a line that is just .\r\n". With IMAP, it's "the next X bytes are the data you asked for". So you're used to dealing with "lines" and that lends itself to C strings. >I notice however, that some components of my email infrastructure pass >NULs through without problems and some do not. qmail successfully queued >a message with a NUL in both the header and the body, but other parts >(e.g. recipient validation tools) did not fare as well, and of course we >knew that inc would truncate (and it did because the lines with NUL were >truncated). I had an inkling popular MTAs would DTRT. --Ken
Re: (Not-so) hypothetical question: What to do about NULs?
Thus said Ken Hornstein on Tue, 21 Feb 2023 21:29:16 -0500: > So you're told "I am sending this many bytes exactly", and you don't > have to deal with "lines", so the implementations I've seen tend to > call read() (or the equivalent) until they get the correct number of > bytes, and because you're not dealing with "lines" you don't treat > them as C strings. While POP's LIST does actually include the size of the message in bytes, that's prior to any CRLF mangling that happens so it cannot be used reliably as a method for determining when to stop reading. Unfortunate. I notice however, that some components of my email infrastructure pass NULs through without problems and some do not. qmail successfully queued a message with a NUL in both the header and the body, but other parts (e.g. recipient validation tools) did not fare as well, and of course we knew that inc would truncate (and it did because the lines with NUL were truncated). I suspect that qmail worked for the most part because of stralloc: http://cr.yp.to/lib/stralloc.html Andy
Re: (Not-so) hypothetical question: What to do about NULs?
> > I wonder if it would be better to use fwrite instead of write, to > > avoid mixing stdio and Posix-style output? (It would also avoid an > > unbuffered write of 1 byte.) > Good point. How about the attached? Looks sensible to me! David.
