Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #211673 > unrolled thread

Re: buster, ekiga.

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: buster, ekiga. peter@easthope.ca - 2019-07-23 17:00 +0200
    Re: buster, ekiga. Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-23 17:10 +0200
      Re: buster, ekiga. <tomas@tuxteam.de> - 2019-07-23 18:40 +0200
      Odd character, was Re: buster, ekiga. David Wright <deblis@lionunicorn.co.uk> - 2019-07-23 21:20 +0200
        Re: Odd character, was Re: buster, ekiga. <tomas@tuxteam.de> - 2019-07-23 21:30 +0200
        Re: Odd character, was Re: buster, ekiga. <tomas@tuxteam.de> - 2019-07-23 21:40 +0200
          Re: Odd character, was Re: buster, ekiga. Michael Stone <mstone@debian.org> - 2019-07-23 23:00 +0200
        Re: Odd character, was Re: buster, ekiga. Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-23 21:40 +0200
          Re: Odd character, was Re: buster, ekiga. <tomas@tuxteam.de> - 2019-07-23 22:10 +0200
        Re: Odd character, was Re: buster, ekiga. Michael Stone <mstone@debian.org> - 2019-07-23 21:40 +0200
          Re: Odd character, was Re: buster, ekiga. David Wright <deblis@lionunicorn.co.uk> - 2019-07-25 18:40 +0200
      Re: buster, ekiga. rhkramer@gmail.com - 2019-07-24 13:20 +0200
        Re: buster, ekiga. David Wright <deblis@lionunicorn.co.uk> - 2019-07-24 16:40 +0200
          Re: buster, ekiga. Michael Stone <mstone@debian.org> - 2019-07-24 19:20 +0200
            Re: buster, ekiga. <tomas@tuxteam.de> - 2019-07-24 19:30 +0200
              Re: buster, ekiga. Michael Stone <mstone@debian.org> - 2019-07-24 20:00 +0200
                Re: buster, ekiga. Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-24 23:00 +0200
                Re: buster, ekiga. Sven Joachim <svenjoac@gmx.de> - 2019-07-24 23:00 +0200
                  Re: buster, ekiga. <tomas@tuxteam.de> - 2019-07-24 23:10 +0200
                Re: buster, ekiga. David Wright <deblis@lionunicorn.co.uk> - 2019-07-24 23:00 +0200
                  Re: buster, ekiga. <tomas@tuxteam.de> - 2019-07-24 23:10 +0200
                    Re: buster, ekiga. Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-24 23:20 +0200
                      Re: buster, ekiga. <tomas@tuxteam.de> - 2019-07-24 23:30 +0200
                      Re: buster, ekiga. David Wright <deblis@lionunicorn.co.uk> - 2019-07-25 18:40 +0200
                    Re: buster, ekiga. Michael Stone <mstone@debian.org> - 2019-07-25 13:40 +0200
    Re: buster, ekiga. Brad Rogers <brad@fineby.me.uk> - 2019-07-23 17:30 +0200

Page 1 of 2  [1] 2  Next page →

#211673 — Re: buster, ekiga.

*	From: Brad Rogers brad@fineby.me.uk
*	Date: Fri, 19 Jul 2019 19:32:46 +0100
> It was replaced by Empathy.

Thanks.  Empathy is installed now.  Appears it  uses a keyring to 
store the password for a PSTN gateway account. So I've installed 
seahorse.

Have yet to succeed in making the gateway password available from a 
keyring.

Provided the PSTN password is typed ( =8~| ), the gatway is opened.  
=8~) Empathy's "Add Contact" remains disabled; the button and menu 
item are pale gray.  Ideas about contacts? 

Thanks again,         ... P.





-- 
https://en.wikibooks.org/wiki/Oberon
Tel: +1 604 670 0140            Bcc: peter at easthope. ca

[toc] | [next] | [standalone]

#211674

On Tue, Jul 23, 2019 at 07:41:20AM -0700, peter@easthope.ca wrote:
> *	From: Brad Rogers 

Oh, it's this guy again.

/me looks at the raw mail message with less(1)

*       From: Brad Rogers ^@brad@fineby.me.uk^@

Yup.  Two NUL bytes in the body of the message.  How completely bizarre.

Apparently what mutt does is truncate that *line* at the first NUL
byte, but then show all the other lines after that just fine.

Other people are seeing the entire message truncated at that point, not
just one line truncated.

Peter, whatever you're doing with your outgoing mail is really strange,
and if possible, you should try to stop it.  Embedding raw NUL characters
in the body of an email is a problem.

[toc] | [prev] | [next] | [standalone]

#211682

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jul 23, 2019 at 11:07:37AM -0400, Greg Wooledge wrote:
> On Tue, Jul 23, 2019 at 07:41:20AM -0700, peter@easthope.ca wrote:
> > *	From: Brad Rogers 
> 
> Oh, it's this guy again.
> 
> /me looks at the raw mail message with less(1)
> 
> *       From: Brad Rogers ^@brad@fineby.me.uk^@
> 
> Yup.  Two NUL bytes in the body of the message.  How completely bizarre.

FWIW, I'm seeing those two null bytes too. OTOH I use the same MUA
as you (Mutt), but on the other hand this is a sample of a different
MTA path, at least from the Debian mailing list servers to each of
us.

Whatever...

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#211687 — Odd character, was Re: buster, ekiga.

On Tue 23 Jul 2019 at 11:07:37 (-0400), Greg Wooledge wrote:
> On Tue, Jul 23, 2019 at 07:41:20AM -0700, peter@easthope.ca wrote:
> > *	From: Brad Rogers 
> 
> Oh, it's this guy again.
> 
> /me looks at the raw mail message with less(1)
> 
> *       From: Brad Rogers ^@brad@fineby.me.uk^@
> 
> Yup.  Two NUL bytes in the body of the message.  How completely bizarre.
> 
> Apparently what mutt does is truncate that *line* at the first NUL
> byte, but then show all the other lines after that just fine.
> 
> Other people are seeing the entire message truncated at that point, not
> just one line truncated.
> 
> Peter, whatever you're doing with your outgoing mail is really strange,
> and if possible, you should try to stop it.  Embedding raw NUL characters
> in the body of an email is a problem.

I don't see any NUL characters, but x80 as shown below. I'm reading
the cached message that mutt downloaded from an IMAP server. Is that
different from you?

000017C0 64 2D 73 65 │ 61 72 63 68 │ 2F 45 31 68 │ 70 76 79 69 │ 2D 30 30 30  d-search/E1hpvyi-000
000017D4 31 6E 78 2D │ 4B 6C 40 64 │ 61 6C 74 6F │ 6E 2E 69 6E │ 76 61 6C 69  1nx-Kl@dalton.invali
000017E8 64 0A 52 65 │ 73 65 6E 74 │ 2D 44 61 74 │ 65 3A 20 54 │ 75 65 2C 20  d.Resent-Date: Tue,
000017FC 32 33 20 4A │ 75 6C 20 32 │ 30 31 39 20 │ 31 34 3A 35 │ 37 3A 32 30  23 Jul 2019 14:57:20
00001810 20 2B 30 30 │ 30 30 20 28 │ 55 54 43 29 │ 0A 0A 2A 09 │ 46 72 6F 6D   +0000 (UTC)..*.From
00001824 3A 20 42 72 │ 61 64 20 52 │ 6F 67 65 72 │ 73 20 80 62 │ 72 61 64 40  : Brad Rogers .brad@
00001838 66 69 6E 65 │ 62 79 2E 6D │ 65 2E 75 6B │ 80 0A 2A 09 │ 44 61 74 65  fineby.me.uk..*.Date
0000184C 3A 20 46 72 │ 69 2C 20 31 │ 39 20 4A 75 │ 6C 20 32 30 │ 31 39 20 31  : Fri, 19 Jul 2019 1
00001860 39 3A 33 32 │ 3A 34 36 20 │ 2B 30 31 30 │ 30 0A 3E 20 │ 49 74 20 77  9:32:46 +0100.> It w
00001874 61 73 20 72 │ 65 70 6C 61 │ 63 65 64 20 │ 62 79 20 45 │ 6D 70 61 74  as replaced by Empat
00001888 68 79 2E 0A │ 0A 54 68 61 │ 6E 6B 73 2E │ 20 20 45 6D │ 70 61 74 68  hy...Thanks.  Empath

Well, here's what I think is going on. The OP wrote "The links are
from the debian mailing list software.  128270(9) =
1F50E(E) or 128270(decimal) = 1F50E(hexadecimal).  U+1F50E is beyond
the list in …"

So it would appear the OP has pasted the Unicode "RIGHT-POINTING
MAGNIFYING GLASS" character into their postings, which seems somewhat
reasonable as it's used on the Debian web pages to mark all the
Message-IDs and references thereto.

Where that gets mangled along the way, I can't guess. but it would see
that 0x80 is a reasonable choice as that's a Latin-1 Control Character
with the meaning PAD.
https://en.wikipedia.org/wiki/Latin-1_Supplement_(Unicode_block)

Converting it to NUL seems hazardous to me, almost asking for trouble.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#211688 — Re: Odd character, was Re: buster, ekiga.

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jul 23, 2019 at 02:19:27PM -0500, David Wright wrote:

[...]

> I don't see any NUL characters, but x80 as shown below [...]

Oh, that's cute :-)

If I followed along correctly, the questionable mails have
neither Content-Type nor Content-Transfer-Encoding. So the
content type defaults to text/plain; charset=us-ascii, right?

If you kill the high bit in x80 you're left with x00.

Hmmm...

Cheers
-- tomás

[toc] | [prev] | [next] | [standalone]

#211689 — Re: Odd character, was Re: buster, ekiga.

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jul 23, 2019 at 03:31:12PM -0400, Michael Stone wrote:
> On Tue, Jul 23, 2019 at 02:19:27PM -0500, David Wright wrote:
> >I don't see any NUL characters, but x80 as shown below. I'm reading
> >the cached message that mutt downloaded from an IMAP server. Is that
> >different from you?
> 
> I see it as x80 in mutt and x00 in the raw file on the imap server.
> I assume mutt is trying to defang the nul, similar to java's
> conversion to 0xc0 0x80, but I haven't actually looked through the
> code to confirm.

Heh. that is strange: with mutt ("edit raw") I do see an x00 (shown
by vim as ^@).

My message doesn't go through an IMAP server, fwiw. Dunno what exim
does to it, though :-)

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#211694 — Re: Odd character, was Re: buster, ekiga.

On Tue, Jul 23, 2019 at 09:35:59PM +0200, tomas@tuxteam.de wrote:
>On Tue, Jul 23, 2019 at 03:31:12PM -0400, Michael Stone wrote:
>> On Tue, Jul 23, 2019 at 02:19:27PM -0500, David Wright wrote:
>> >I don't see any NUL characters, but x80 as shown below. I'm reading
>> >the cached message that mutt downloaded from an IMAP server. Is that
>> >different from you?
>>
>> I see it as x80 in mutt and x00 in the raw file on the imap server.
>> I assume mutt is trying to defang the nul, similar to java's
>> conversion to 0xc0 0x80, but I haven't actually looked through the
>> code to confirm.
>
>Heh. that is strange: with mutt ("edit raw") I do see an x00 (shown
>by vim as ^@).
>
>My message doesn't go through an IMAP server, fwiw. Dunno what exim
>does to it, though :-)

I guess it's the imapd defanging then, before it gets to mutt. 

[toc] | [prev] | [next] | [standalone]

#211691 — Re: Odd character, was Re: buster, ekiga.

On Tue, Jul 23, 2019 at 02:19:27PM -0500, David Wright wrote:
> On Tue 23 Jul 2019 at 11:07:37 (-0400), Greg Wooledge wrote:
> > Yup.  Two NUL bytes in the body of the message.  How completely bizarre.
> > 
> > Apparently what mutt does is truncate that *line* at the first NUL
> > byte, but then show all the other lines after that just fine.

> I don't see any NUL characters, but x80 as shown below. I'm reading
> the cached message that mutt downloaded from an IMAP server. Is that
> different from you?

In my case, the email is sent first to a Debian 9 system running qmail +
magic-smtpd (with possible interference from corporate firewall products
over which I have no control), and from there to my Debian 10 desktop
system, also running qmail, with qmail-smtpd as the receiver.  Mail is
delivered locally on the Debian 10 system to a Maildir in my home
directory, and mutt reads it directly from there.  No IMAP or POP3 for me.

I'll try to remember to keep a copy of the next one for hex-dumping.

Meanwhile, as a test, I ran the following from my home system outside
the workplace firewall:

printf 'Testing \0nul\0\nDid it work?\n' | mailx -s test wooledg@eeg.ccf.org

Here's what hd shows (last few lines only):

00000370  38 22 0a 43 6f 6e 74 65  6e 74 2d 54 72 61 6e 73  |8".Content-Trans|
00000380  66 65 72 2d 45 6e 63 6f  64 69 6e 67 3a 20 38 62  |fer-Encoding: 8b|
00000390  69 74 0a 0a 54 65 73 74  69 6e 67 20 0a 44 69 64  |it..Testing .Did|
000003a0  20 69 74 20 77 6f 72 6b  3f 0a                    | it work?.|
000003aa

Which probably means mailx on my sender truncates the line with the
raw NUL bytes, and the test is inconclusive.

So, next test:

printf 'Test two \0nul\0\nDid it work?\n' | mutt -s test wooledg@eeg.ccf.org

Here's what I got:

000003b0  73 66 65 72 2d 45 6e 63  6f 64 69 6e 67 3a 20 71  |sfer-Encoding: q|
000003c0  75 6f 74 65 64 2d 70 72  69 6e 74 61 62 6c 65 0a  |uoted-printable.|
000003d0  58 2d 4f 70 65 72 61 74  69 6e 67 2d 53 79 73 74  |X-Operating-Syst|
000003e0  65 6d 3a 20 4c 69 6e 75  78 20 34 2e 31 39 2e 30  |em: Linux 4.19.0|
000003f0  2d 35 2d 61 6d 64 36 34  0a 55 73 65 72 2d 41 67  |-5-amd64.User-Ag|
00000400  65 6e 74 3a 20 4d 75 74  74 2f 31 2e 31 30 2e 31  |ent: Mutt/1.10.1|
00000410  20 28 32 30 31 38 2d 30  37 2d 31 33 29 0a 0a 54  | (2018-07-13)..T|
00000420  65 73 74 20 74 77 6f 20  3d 30 30 6e 75 6c 3d 30  |est two =00nul=0|
00000430  30 0a 44 69 64 20 69 74  20 77 6f 72 6b 3f 0a     |0.Did it work?.|
0000043f

... well, that's self-explanatory, isn't it.  I don't feel like writing
a script to send raw NUL bytes through /usr/sbin/sendmail or through
netcat mxhost 25 at this time, so I'll just leave it at that.

[toc] | [prev] | [next] | [standalone]

#211693 — Re: Odd character, was Re: buster, ekiga.

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jul 23, 2019 at 03:38:33PM -0400, Greg Wooledge wrote:
> On Tue, Jul 23, 2019 at 02:19:27PM -0500, David Wright wrote:
> > On Tue 23 Jul 2019 at 11:07:37 (-0400), Greg Wooledge wrote:
> > > Yup.  Two NUL bytes in the body of the message.  How completely bizarre.
> > > 
> > > Apparently what mutt does is truncate that *line* at the first NUL
> > > byte, but then show all the other lines after that just fine.
> 
> > I don't see any NUL characters, but x80 as shown below. I'm reading
> > the cached message that mutt downloaded from an IMAP server. Is that
> > different from you?
> 
> In my case, the email is sent first to a Debian 9 system running qmail +
> magic-smtpd [...]


> I'll try to remember to keep a copy of the next one for hex-dumping.

Looking forward :-)

> Meanwhile, as a test, I ran the following from my home system outside
> the workplace firewall:

[...]

Interesting. Note that both your tests have a Content-Transfer-Encoding
(first: 8bit, second: quoted-printable; the first one gets a slight
indigestion, the second not).

The original messages have no Content-Type, much less Content-Transfer-Encoding
(so x00 as well as x80 should be both a no-no anyway).

Cheers
-- t 

[toc] | [prev] | [next] | [standalone]

#211692 — Re: Odd character, was Re: buster, ekiga.

On Tue, Jul 23, 2019 at 02:19:27PM -0500, David Wright wrote:
>I don't see any NUL characters, but x80 as shown below. I'm reading
>the cached message that mutt downloaded from an IMAP server. Is that
>different from you?

I see it as x80 in mutt and x00 in the raw file on the imap server. I 
assume mutt is trying to defang the nul, similar to java's conversion to 
0xc0 0x80, but I haven't actually looked through the code to confirm.

>So it would appear the OP has pasted the Unicode "RIGHT-POINTING
>MAGNIFYING GLASS" character into their postings, which seems somewhat
>reasonable as it's used on the Debian web pages to mark all the
>Message-IDs and references thereto.
>
>Where that gets mangled along the way, I can't guess. but it would see
>that 0x80 is a reasonable choice as that's a Latin-1 Control Character
>with the meaning PAD.
>https://en.wikipedia.org/wiki/Latin-1_Supplement_(Unicode_block)

I'm not entirely surprised that an MUA that is unaware of the changes to 
internet mail that have happened since the early 80s (codified back in 
2001) is also unaware of unicode. 

[toc] | [prev] | [next] | [standalone]

#211731 — Re: Odd character, was Re: buster, ekiga.

On Tue 23 Jul 2019 at 15:31:12 (-0400), Michael Stone wrote:
> On Tue, Jul 23, 2019 at 02:19:27PM -0500, David Wright wrote:
> > I don't see any NUL characters, but x80 as shown below. I'm reading
> > the cached message that mutt downloaded from an IMAP server. Is that
> > different from you?
> 
> I see it as x80 in mutt and x00 in the raw file on the imap server. I
> assume mutt is trying to defang the nul, similar to java's conversion
> to 0xc0 0x80, but I haven't actually looked through the code to
> confirm.

I don't think mutt is doing that. I downloaded a message directly from
my hosting service's IMAP server¹ and that shows <80>, not <00>,
just as mutt does. My experience with mutt is that if a NUL is sent in
a "legitimate"² manner within an email, it causes truncation. I don't
know whether mutt does it or the pager, but as I said elsewhere
it doesn't make me happy.

I'm not sure whether I can get any "closer" to my IMAP server than
that, in order to find whether there's a NUL there; perhaps by
logging in using my credentials? That would require some research
as I don't normally access the service in that way.

One thing we don't know is whether the routes being used by the MTAs
to communicate with each other are 8-bit transparent or not. As
pointed out by tomás, <80> and <00> only differ in the top bit.

> > So it would appear the OP has pasted the Unicode "RIGHT-POINTING
> > MAGNIFYING GLASS" character into their postings, which seems somewhat
> > reasonable as it's used on the Debian web pages to mark all the
> > Message-IDs and references thereto.
> > 
> > Where that gets mangled along the way, I can't guess. but it would see
> > that 0x80 is a reasonable choice as that's a Latin-1 Control Character
> > with the meaning PAD.
> > https://en.wikipedia.org/wiki/Latin-1_Supplement_(Unicode_block)
> 
> I'm not entirely surprised that an MUA that is unaware of the changes
> to internet mail that have happened since the early 80s (codified back
> in 2001) is also unaware of unicode.

My last paragraph wasn't necessarily limited to the behaviour of the
OP's MUA. It's likely the MTAs are more up-to-date that what is
alleged to be a very old MUA.

¹$ curl --url 'imaps://my-hosting-service:993/INBOX;UID=1234' --user 'my-username:my-password' -o Documents/raw-message

²eg as =00 in a quoted-printable encoded message.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#211699

On Tuesday, July 23, 2019 11:07:37 AM Greg Wooledge wrote:
> On Tue, Jul 23, 2019 at 07:41:20AM -0700, peter@easthope.ca wrote:
> > *	From: Brad Rogers
> 
> Oh, it's this guy again.
> 
> /me looks at the raw mail message with less(1)
> 
> *       From: Brad Rogers ^@brad@fineby.me.uk^@
> 
> Yup.  Two NUL bytes in the body of the message.  How completely bizarre.
> 
> Apparently what mutt does is truncate that *line* at the first NUL
> byte, but then show all the other lines after that just fine.
> 
> Other people are seeing the entire message truncated at that point, not
> just one line truncated.
> 
> Peter, whatever you're doing with your outgoing mail is really strange,
> and if possible, you should try to stop it.  Embedding raw NUL characters
> in the body of an email is a problem.

+1

[toc] | [prev] | [next] | [standalone]

#211702

On Wed 24 Jul 2019 at 07:10:14 (-0400), rhkramer@gmail.com wrote:
> On Tuesday, July 23, 2019 11:07:37 AM Greg Wooledge wrote:
> > On Tue, Jul 23, 2019 at 07:41:20AM -0700, peter@easthope.ca wrote:
> > > *	From: Brad Rogers
> > 
> > Oh, it's this guy again.
> > 
> > /me looks at the raw mail message with less(1)
> > 
> > *       From: Brad Rogers ^@brad@fineby.me.uk^@
> > 
> > Yup.  Two NUL bytes in the body of the message.  How completely bizarre.
> > 
> > Apparently what mutt does is truncate that *line* at the first NUL
> > byte, but then show all the other lines after that just fine.
> > 
> > Other people are seeing the entire message truncated at that point, not
> > just one line truncated.
> > 
> > Peter, whatever you're doing with your outgoing mail is really strange,
> > and if possible, you should try to stop it.  Embedding raw NUL characters
> > in the body of an email is a problem.
> 
> +1

Well, since Greg's message was posted, the OP has explained their
actions, which were made with good intentions. I hope my reply in
the other thread will save the OP some time and effort as well as
benefitting us all here.

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. If the MUA is outputting Unicode,
there exists a REPLACEMENT CHARACTER (U+FFFD) for replacing an
unknown, unrecognized or unrepresentable character. But if the
MUA decides that it's valid, but unprintable, it should just
escape it as is usual.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#211704

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

[toc] | [prev] | [next] | [standalone]

#211705

[Multipart message — attachments visible in raw view] — view raw

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 ;-)

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#211706

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.

[toc] | [prev] | [next] | [standalone]

#211711

On Wed, Jul 24, 2019 at 03:49:38PM -0500, David Wright wrote:
> 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.

If you feel strongly about this issue, then you probably need to take
it up with the mutt maintainers, on their mailing list or however they
track bugs and problems.  I don't want to speak for the Debian developers
here, but this seems like the kind of bug report that would just get
forwarded upstream anyway.

[toc] | [prev] | [next] | [standalone]

#211712

On 2019-07-24 15:49 -0500, David Wright wrote:

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

In the design of the C language, where NUL is the end of the string as
we know it.

Cheers,
       Sven

[toc] | [prev] | [next] | [standalone]

#211715

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jul 24, 2019 at 10:57:09PM +0200, Sven Joachim wrote:
> On 2019-07-24 15:49 -0500, David Wright wrote:
> 
> > Where is the definition of NUL as "ignore everything following this
> > character"? AFAICT the mutt manual says nothing about NUL at all.
> 
> In the design of the C language, where NUL is the end of the string as
> we know it.

But you don't read (in C) off a random file (or worse, off The
Intertubes!) and expect well-formed strings. Because then, you're
in hot water anyway (or shouldn't be doing C, perhaps).

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#211713

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web