[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: buster, ekiga.



On Wed 24 Jul 2019 at 13:51:22 (-0400), Michael Stone wrote:
> On Wed, Jul 24, 2019 at 07:28:11PM +0200, tomas@tuxteam.de wrote:
> > On Wed, Jul 24, 2019 at 01:10:49PM -0400, Michael Stone wrote:
> > > On Wed, Jul 24, 2019 at 09:29:47AM -0500, David Wright wrote:
> > > >However, I would not award +1 to the MUAs that, we are told,
> > > >truncate the message, or even just the line, at the first
> > > >NUL byte. That could yield a message with a very different sense
> > > >from what the sender wrote.
> > > 
> > > And that is what happens when you do something that is out of spec
> > > for the protocol--the recipient's behavior is undefined and possibly
> > > suboptimal. (A NUL is specifically disallowed per RFC 2822.)
> > 
> > But never forget the Postel Principle. In RFC land, nasal daemons
> > are frowned upon ;-)
> 
> The reason it was specifically disallowed in RFC2822 is because it
> broke things and gave unexpected results. Just arguing that things
> should be other than they are rarely changes anything. Raw NULs are
> going to cause problems for software that uses NUL-terminated strings.

If I read a file that has an embedded NUL into an editor, I would
consider it suboptimal if the editor ceased reading any more of the
file when it hit a NUL.

In the same way, I expect mutt and its pager to behave much the
likewise. The only debate would be how/whether to display the NUL
itself. It could just ignore it entirely, as if it wasn't there, or
it could escape it in various ways. Having no indication of the
*existence* of the characters following the NUL is suboptimal in
my book.

Where is the definition of NUL as "ignore everything following this
character"? AFAICT the mutt manual says nothing about NUL at all.

All this ignores how the NUL got into the message: accidentally placed
there, or accidentally converted from 0x80, or deliberately included
(correctly encoded in, say, quoted-printable).

> There are ways around that, and some of those techiniques have already
> been implemented such that there are standard mechanisms for sending
> binary data in email. Insisting that everybody also handle
> non-compliant input from people who chose not to implement those
> standards in the past 20+ years, and to do so in a particular way, is
> a waste of time because it simply won't happen. The Postel approach is
> why some MTAs actually accepted the message even though it was
> noncompliant, and on the modern internet it's quite likely that many
> recipients never saw it because their MTA simply threw it away. (And
> many recipients who did see it also saw that it got a bump in its spam
> score because it contained bogus content.) The idea that everyone must
> accept anything is obsolete on the modern internet, and while sending
> noncompliant data out of sheer cussedness may be satisfying, it's also
> likely to leave you shouting to an empty room. A better implementation
> of the robustness principle would have bounced the message early so
> the sender would know that there was a problem with the message which
> would likely interfere with recipients' ability to read
> it.

Cheers,
David.


Reply to: