Re: Re: buster, ekiga.
On Fri, 2020-01-03 at 18:03 -0800, Ernesto Alfonso wrote: > I was able to use linphone, which is available in buster. > > Ernesto Linphone is also available from a Flatpak. The newer version is much better than the one in the Debian main repository.
Re: Re: buster, ekiga.
I was able to use linphone, which is available in buster. Ernesto
Re: buster, ekiga.
From: Robin Krahl , Fri, 19 Jul 2019 20:12:58 +0200 > Ekiga has been removed as the last upstream release was in 2013, see: > https://tracker.debian.org/pkg/ekiga > https://tracker.debian.org/news/1004860/removed-401-9-from-unstable/ > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911593 > Most likely it wont come back to Debian. You might want to have a > look > at alternatives, for example empathy. OK, thanks. Empathy is installed in Debian 10 here but still fails to recognize the contact list. Also https://wiki.gnome.org/Apps/Empathy has this sentence. "Empathy is currently no longer in development (see also Attic/Unmaintained)." In gnome-contacts-l...@gnome.org was a comment that Empathy is being removed from GNOME but I can't offer a reference for that. gnome-contacts-list is no longer listed in https://mail.gnome.org/mailman/listinfo . Conclusion: no VoIP application is working in Debian 10 here. New information is welcome of course. Regards, ... Peter E. -- https://en.wikibooks.org/wiki/Medical_Machines Tel: +1 604 670 0140Bcc: peter at easthope. ca
Re: buster, ekiga.
On Wed 24 Jul 2019 at 17:12:39 (-0400), Greg Wooledge wrote: > On Wed, Jul 24, 2019 at 11:02:33PM +0200, to...@tuxteam.de wrote: > > 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. > > > > Vim and Emacs both qualify. Are there other editors? (yes, a bit > > tongue-in-cheek ;-P > > I was curious, so I generated a "text" file with a NUL in it, and opened > it in nano. To my surprise, nano actually handled it extremely well. > The NUL was rendered as the two characters ^@ in the terminal, and > the cursor only "rested" on one of the two characters when moving > left-to-right across that line. Ctrl-D (with the cursor on one of the ^@ > characters) removed both characters from the terminal display, and after > saving, the NUL byte was gone from the file. > > It was basically identical to how vim handles it, just with different > key bindings. Yes, it's a good editor, and it's the only one I use as root. However, it does have its failings with some characters, generally in the more distant parts of the character code chart. For example, you can't see anything special about NO-BREAK SPACE 0xa0, whereas emacs marks it in various ways (cyan underscore when windowed, purple block when non-windowed). And its behaviour with SOFT HYPHEN 0xad is really odd, particularly when at the beginning of a line. (Soft hyphens are coloured cyan in emacs. These colours may depend on themes and suchlike in DEs.) Cheers, David.
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.
Re: buster, ekiga.
On Wed, Jul 24, 2019 at 11:02:33PM +0200, to...@tuxteam.de wrote: FWIW, I (somewhat strongly) disagree with Michael here. I'm a strong proponent of Postel's principle (both sides!). That's fine, it was a lovely ideal for a different and simpler time.
Re: buster, ekiga.
On Wed, Jul 24, 2019 at 05:12:39PM -0400, Greg Wooledge wrote: > On Wed, Jul 24, 2019 at 11:02:33PM +0200, to...@tuxteam.de wrote: > > 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. > > > > Vim and Emacs both qualify. Are there other editors? (yes, a bit > > tongue-in-cheek ;-P > > I was curious, so I generated a "text" file with a NUL in it, and opened > it in nano. To my surprise, nano actually handled it extremely well. Phew :-) Thanks -- t signature.asc Description: Digital signature
Re: buster, ekiga.
On Wed, Jul 24, 2019 at 11:02:33PM +0200, to...@tuxteam.de wrote: > 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. > > Vim and Emacs both qualify. Are there other editors? (yes, a bit > tongue-in-cheek ;-P I was curious, so I generated a "text" file with a NUL in it, and opened it in nano. To my surprise, nano actually handled it extremely well. The NUL was rendered as the two characters ^@ in the terminal, and the cursor only "rested" on one of the two characters when moving left-to-right across that line. Ctrl-D (with the cursor on one of the ^@ characters) removed both characters from the terminal display, and after saving, the NUL byte was gone from the file. It was basically identical to how vim handles it, just with different key bindings.
Re: buster, ekiga.
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 signature.asc Description: Digital signature
Re: buster, ekiga.
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. Vim and Emacs both qualify. Are there other editors? (yes, a bit tongue-in-cheek ;-P FWIW, I (somewhat strongly) disagree with Michael here. I'm a strong proponent of Postel's principle (both sides!). But I do know theres the exactly opposite position. That's life. Cheers -- t signature.asc Description: Digital signature
Re: buster, ekiga.
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
Re: buster, ekiga.
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.
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, to...@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.
Re: buster, ekiga.
On Wed, Jul 24, 2019 at 07:28:11PM +0200, to...@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.
Re: buster, ekiga.
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 signature.asc Description: Digital signature
Re: buster, ekiga.
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.)
Re: buster, ekiga.
On Wed 24 Jul 2019 at 07:10:14 (-0400), rhkra...@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, pe...@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 ^@b...@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.
Re: buster, ekiga.
On Tuesday, July 23, 2019 11:07:37 AM Greg Wooledge wrote: > On Tue, Jul 23, 2019 at 07:41:20AM -0700, pe...@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 ^@b...@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
Re: Odd character, was Re: buster, ekiga.
On Tue, Jul 23, 2019 at 09:35:59PM +0200, to...@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.
Re: Odd character, was Re: buster, ekiga.
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 signature.asc Description: Digital signature
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 wool...@eeg.ccf.org Here's what hd shows (last few lines only): 0370 38 22 0a 43 6f 6e 74 65 6e 74 2d 54 72 61 6e 73 |8".Content-Trans| 0380 66 65 72 2d 45 6e 63 6f 64 69 6e 67 3a 20 38 62 |fer-Encoding: 8b| 0390 69 74 0a 0a 54 65 73 74 69 6e 67 20 0a 44 69 64 |it..Testing .Did| 03a0 20 69 74 20 77 6f 72 6b 3f 0a| it work?.| 03aa 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 wool...@eeg.ccf.org Here's what I got: 03b0 73 66 65 72 2d 45 6e 63 6f 64 69 6e 67 3a 20 71 |sfer-Encoding: q| 03c0 75 6f 74 65 64 2d 70 72 69 6e 74 61 62 6c 65 0a |uoted-printable.| 03d0 58 2d 4f 70 65 72 61 74 69 6e 67 2d 53 79 73 74 |X-Operating-Syst| 03e0 65 6d 3a 20 4c 69 6e 75 78 20 34 2e 31 39 2e 30 |em: Linux 4.19.0| 03f0 2d 35 2d 61 6d 64 36 34 0a 55 73 65 72 2d 41 67 |-5-amd64.User-Ag| 0400 65 6e 74 3a 20 4d 75 74 74 2f 31 2e 31 30 2e 31 |ent: Mutt/1.10.1| 0410 20 28 32 30 31 38 2d 30 37 2d 31 33 29 0a 0a 54 | (2018-07-13)..T| 0420 65 73 74 20 74 77 6f 20 3d 30 30 6e 75 6c 3d 30 |est two =00nul=0| 0430 30 0a 44 69 64 20 69 74 20 77 6f 72 6b 3f 0a |0.Did it work?.| 043f ... 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.
Re: Odd character, was Re: buster, ekiga.
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
signature.asc
Description: Digital signature
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.
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 [...] 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 signature.asc Description: Digital signature
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, pe...@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 ^@b...@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? 17C0 64 2D 73 65 │ 61 72 63 68 │ 2F 45 31 68 │ 70 76 79 69 │ 2D 30 30 30 d-search/E1hpvyi-000 17D4 31 6E 78 2D │ 4B 6C 40 64 │ 61 6C 74 6F │ 6E 2E 69 6E │ 76 61 6C 69 1nx-Kl@dalton.invali 17E8 64 0A 52 65 │ 73 65 6E 74 │ 2D 44 61 74 │ 65 3A 20 54 │ 75 65 2C 20 d.Resent-Date: Tue, 17FC 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 1810 20 2B 30 30 │ 30 30 20 28 │ 55 54 43 29 │ 0A 0A 2A 09 │ 46 72 6F 6D + (UTC)..*.From 1824 3A 20 42 72 │ 61 64 20 52 │ 6F 67 65 72 │ 73 20 80 62 │ 72 61 64 40 : Brad Rogers .brad@ 1838 66 69 6E 65 │ 62 79 2E 6D │ 65 2E 75 6B │ 80 0A 2A 09 │ 44 61 74 65 fineby.me.uk..*.Date 184C 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 1860 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 1874 61 73 20 72 │ 65 70 6C 61 │ 63 65 64 20 │ 62 79 20 45 │ 6D 70 61 74 as replaced by Empat 1888 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.
Re: buster, ekiga.
On Tue, Jul 23, 2019 at 11:07:37AM -0400, Greg Wooledge wrote: > On Tue, Jul 23, 2019 at 07:41:20AM -0700, pe...@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 ^@b...@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 signature.asc Description: Digital signature
Re: buster, ekiga.
On Tue, 23 Jul 2019 07:41:20 -0700 pe...@easthope.ca wrote: Hello pe...@easthope.ca, >* From: Brad Rogers * Date: Fri, 19 Jul 2019 19:32:46 >> It was replaced by Empathy. ... >item are pale gray. Ideas about contacts? All I know about Empathy is that it replaced Ekiga. I've never used either package. Sorry. >Thanks again, ... P. YW. I'm just sorry that I can't be of more help. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" I'll tell you something, I think that you should know Rich Kids - Rich Kids pgpyD0lHLmvAo.pgp Description: OpenPGP digital signature
Re: buster, ekiga.
On Tue, Jul 23, 2019 at 07:41:20AM -0700, pe...@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 ^@b...@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.
Re: buster, ekiga.
* From: Brad Rogers
Re: buster, ekiga.
On Fri, 19 Jul 2019 09:43:46 -0700 pe...@easthope.ca wrote: Hello pe...@easthope.ca, >ekiga is absent from buster. It was replaced by Empathy. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" Every single one of us Devil Inside - INXS pgpTFOANZxnjJ.pgp Description: OpenPGP digital signature
Re: buster, ekiga.
On 2019-07-19 09:43:46, pe...@easthope.ca wrote: > ekiga is absent from buster. Something involving ssl/tls? Ekiga has been removed as the last upstream release was in 2013, see: https://tracker.debian.org/pkg/ekiga https://tracker.debian.org/news/1004860/removed-401-9-from-unstable/ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911593 Most likely it won’t come back to Debian. You might want to have a look at alternatives, for example empathy. /Robin signature.asc Description: PGP signature
buster, ekiga.
Hello again, ekiga is absent from buster. Something involving ssl/tls? I guess it will surface sooner or later. Any suggestions for the interim? Add stretch to /etc/apt/sources.list and try that? Thanks, ... P. -- https://en.wikibooks.org/wiki/Oberon Tel: +1 604 670 0140Bcc: peter at easthope. ca
