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

Re: buster, ekiga.



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. 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.


Reply to: