Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #220496 > unrolled thread
| Started by | "Russell L. Harris" <russell@rlharris.org> |
|---|---|
| First post | 2020-03-26 05:00 +0100 |
| Last post | 2020-03-27 16:00 +0100 |
| Articles | 20 on this page of 73 — 21 participants |
Back to article view | Back to linux.debian.user
HTML mail + PDF attachments "Russell L. Harris" <russell@rlharris.org> - 2020-03-26 05:00 +0100
Re: HTML mail + PDF attachments David Christensen <dpchrist@holgerdanske.com> - 2020-03-26 06:00 +0100
Re: HTML mail + PDF attachments "Russell L. Harris" <russell@rlharris.org> - 2020-03-26 07:40 +0100
Re: HTML mail + PDF attachments Joe <joe@jretrading.com> - 2020-03-26 10:10 +0100
Re: HTML mail + PDF attachments Dan Purgert <dan@djph.net> - 2020-03-26 12:40 +0100
Re: HTML mail + PDF attachments Tixy <tixy@yxit.co.uk> - 2020-03-26 13:20 +0100
Re: HTML mail + PDF attachments Dan Purgert <dan@djph.net> - 2020-03-26 13:40 +0100
Re: HTML mail + PDF attachments Gene Heskett <gheskett@shentel.net> - 2020-03-26 06:10 +0100
Re: HTML mail + PDF attachments Andrei POPESCU <andreimpopescu@gmail.com> - 2020-03-26 09:30 +0100
Re: HTML mail + PDF attachments "Russell L. Harris" <russell@rlharris.org> - 2020-03-26 10:20 +0100
Re: HTML mail + PDF attachments <tomas@tuxteam.de> - 2020-03-26 10:50 +0100
Over-engineering, Libre Software and Open Source (was: HTML mail + PDF attachments) Nicolas George <george@nsup.org> - 2020-03-26 16:40 +0100
Re: Over-engineering, Libre Software and Open Source (was: HTML mail + PDF attachments) <tomas@tuxteam.de> - 2020-03-26 17:30 +0100
Re: HTML mail + PDF attachments "Russell L. Harris" <russell@rlharris.org> - 2020-03-26 18:50 +0100
Re: HTML mail + PDF attachments Dan Purgert <dan@djph.net> - 2020-03-26 12:50 +0100
Re: HTML mail + PDF attachments Dan Purgert <dan@djph.net> - 2020-03-26 12:50 +0100
Re: HTML mail + PDF attachments Reco <recoverym4n@enotuniq.net> - 2020-03-26 16:50 +0100
Re: HTML mail + PDF attachments Andrei POPESCU <andreimpopescu@gmail.com> - 2020-03-27 10:00 +0100
Re: HTML mail + PDF attachments Reco <recoverym4n@enotuniq.net> - 2020-03-27 12:50 +0100
Re: HTML mail + PDF attachments Andrei POPESCU <andreimpopescu@gmail.com> - 2020-03-27 13:30 +0100
Re: HTML mail + PDF attachments Richard Hector <richard@walnut.gen.nz> - 2020-03-27 14:50 +0100
Re: HTML mail + PDF attachments David Wright <deblis@lionunicorn.co.uk> - 2020-03-27 15:40 +0100
Re: HTML mail + PDF attachments Reco <recoverym4n@enotuniq.net> - 2020-03-27 15:40 +0100
Re: HTML mail + PDF attachments (with șurubelniță) David Wright <deblis@lionunicorn.co.uk> - 2020-03-27 17:20 +0100
Re: HTML mail + PDF attachments (with șurubelniță) Greg Wooledge <wooledg@eeg.ccf.org> - 2020-03-27 17:50 +0100
Re: HTML mail + PDF attachments (with șurubelniță) Andrei POPESCU <andreimpopescu@gmail.com> - 2020-03-27 18:10 +0100
Re: HTML mail + PDF attachments (with șurubelniță) Curt <curty@free.fr> - 2020-03-27 18:40 +0100
Re: HTML mail + PDF attachments (with șurubelniță) deloptes <deloptes@gmail.com> - 2020-03-27 21:20 +0100
Re: HTML mail + PDF attachments (with șurubelniță) Curt <curty@free.fr> - 2020-03-28 10:10 +0100
Re: HTML mail + PDF attachments (with șurubelniță) Curt <curty@free.fr> - 2020-03-28 10:40 +0100
Re: HTML mail + PDF attachments (with șurubelniță) <tomas@tuxteam.de> - 2020-03-28 11:10 +0100
Re: HTML mail + PDF attachments (with șurubelniță) Joe <joe@jretrading.com> - 2020-03-28 14:20 +0100
Re: HTML mail + PDF attachments (with șurubelniță) <tomas@tuxteam.de> - 2020-03-28 15:00 +0100
Re: HTML mail + PDF attachments (with șurubelniță) Curt <curty@free.fr> - 2020-03-28 15:40 +0100
Re: HTML mail + PDF attachments (with șurubelniță) <tomas@tuxteam.de> - 2020-03-28 16:10 +0100
Re: HTML mail + PDF attachments (with șurubelniță) <tomas@tuxteam.de> - 2020-03-28 10:40 +0100
Re: HTML mail + PDF attachments (with șurubelniță) Joe <joe@jretrading.com> - 2020-03-28 10:40 +0100
Re: HTML mail + PDF attachments (with șurubelniță) Curt <curty@free.fr> - 2020-03-28 10:50 +0100
Re: HTML mail + PDF attachments (with șurubelniță) Joe <joe@jretrading.com> - 2020-03-28 14:10 +0100
Re: HTML mail + PDF attachments (with șurubelniță) Brian <ad44@cityscape.co.uk> - 2020-03-27 20:40 +0100
Re: HTML mail + PDF attachments (with șurubelniță) David Wright <deblis@lionunicorn.co.uk> - 2020-03-28 05:20 +0100
Re: HTML mail + PDF attachments (with șurubelniță) Andrei POPESCU <andreimpopescu@gmail.com> - 2020-03-28 09:40 +0100
Re: HTML mail + PDF attachments (with șurubelniță) David Wright <deblis@lionunicorn.co.uk> - 2020-03-30 20:40 +0200
Re: HTML mail + PDF attachments (with șurubelniță) The Wanderer <wanderer@fastmail.fm> - 2020-03-31 01:30 +0200
Re: HTML mail + PDF attachments (with șurubelniță) Richard Hector <richard@walnut.gen.nz> - 2020-03-31 12:00 +0200
Re: HTML mail + PDF attachments (with șurubelniță) Joe <joe@jretrading.com> - 2020-03-28 09:50 +0100
Re: HTML mail + PDF attachments (with șurubelniță) <tomas@tuxteam.de> - 2020-03-28 09:50 +0100
Re: HTML mail + PDF attachments (with șurubelniță) Greg Wooledge <wooledg@eeg.ccf.org> - 2020-03-30 13:30 +0200
Re: HTML mail + PDF attachments (with șurubelniță) David Wright <deblis@lionunicorn.co.uk> - 2020-03-30 20:40 +0200
Re: HTML mail + PDF attachments (with ??urubelni????) "Russell L. Harris" <russell@rlharris.org> - 2020-03-27 21:10 +0100
Re: HTML mail + PDF attachments Dan Purgert <dan@djph.net> - 2020-03-27 13:30 +0100
Re: HTML mail + PDF attachments Dan Purgert <dan@djph.net> - 2020-03-27 13:30 +0100
Re: HTML mail + PDF attachments Andrei POPESCU <andreimpopescu@gmail.com> - 2020-03-28 10:00 +0100
Re: HTML mail + PDF attachments Jason <electron@emypeople.net> - 2020-04-13 19:40 +0200
Re: HTML mail + PDF attachments "Russell L. Harris" <russell@rlharris.org> - 2020-04-13 20:50 +0200
Re: HTML mail + PDF attachments Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-14 09:00 +0200
Re: HTML mail + PDF attachments "Russell L. Harris" <russell@rlharris.org> - 2020-04-14 09:30 +0200
Re: HTML mail + PDF attachments Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-14 10:20 +0200
Re: HTML mail + PDF attachments David Wright <deblis@lionunicorn.co.uk> - 2020-04-14 22:30 +0200
Re: HTML mail + PDF attachments "Russell L. Harris" <russell@rlharris.org> - 2020-04-14 23:20 +0200
Re: HTML mail + PDF attachments David Wright <deblis@lionunicorn.co.uk> - 2020-04-23 03:20 +0200
Re: HTML mail + PDF attachments Dan Purgert <dan@djph.net> - 2020-03-26 12:50 +0100
Re: HTML mail + PDF attachments Nate Bargmann <n0nb@n0nb.us> - 2020-03-26 12:50 +0100
Re: HTML mail + PDF attachments Erwan David <erwan@rail.eu.org> - 2020-03-26 15:00 +0100
Re: HTML mail + PDF attachments "Russell L. Harris" <russell@rlharris.org> - 2020-03-26 19:00 +0100
Re: HTML mail + PDF attachments Nate Bargmann <n0nb@n0nb.us> - 2020-03-27 02:30 +0100
Re: HTML mail + PDF attachments Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2020-03-26 13:30 +0100
Re: HTML mail + PDF attachments Reco <recoverym4n@enotuniq.net> - 2020-03-26 16:50 +0100
Re: HTML mail + PDF attachments David Wright <deblis@lionunicorn.co.uk> - 2020-03-26 17:20 +0100
Re: HTML mail + PDF attachments "Russell L. Harris" <russell@rlharris.org> - 2020-03-26 20:00 +0100
Re: HTML mail + PDF attachments David Wright <deblis@lionunicorn.co.uk> - 2020-03-27 04:30 +0100
[solved] Re: HTML mail + PDF attachments "Russell L. Harris" <russell@rlharris.org> - 2020-03-27 08:00 +0100
Re: [solved] Re: HTML mail + PDF attachments David Wright <deblis@lionunicorn.co.uk> - 2020-03-27 16:00 +0100
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2020-03-28 05:20 +0100 |
| Subject | Re: HTML mail + PDF attachments (with șurubelniță) |
| Message-ID | <zPb6V-72v-1@gated-at.bofh.it> |
| In reply to | #220569 |
On Fri 27 Mar 2020 at 12:42:17 (-0400), Greg Wooledge wrote: > On Fri, Mar 27, 2020 at 11:12:49AM -0500, David Wright wrote: > > On Fri 27 Mar 2020 at 17:35:19 (+0300), Reco wrote: > > > I'm not that familiar with the languages to qualify Romanian as a Latin > > > or a non-Latin language, > > > > I think we can agree that the Romans spoke Latin! > > Err... Romanian is not the language that was spoken in Rome. I don't think anyone has said that it was. The Romans (in the sense that I think we're also agreed on, ie those living in Rome a couple of millennia ago) spoke Latin. As deloptes has pointed out, they didn't speak the literary language, just as most English people don't speak literary English. They spoke Vulgar Latin, and that outlived the Empire, evolving and dividing into the Romance languages. But it's strange how an aside can kill the actual discussion of email headers. > It is, however, considered a "Romance language", meaning it has Latin > as one of its primary roots. > > That said, I think the actual question was which character set it > requires. The Romanian language only came up because Andrei used it to write an example of a filename. AIUI what's important in deciding whether to encode it is the type of Latin, ie Latin-1 vs anything else. Pointing out that it's been encoded here in Unicode is obvious (it's prefixed by utf-8), but AFAICT it could have been encoded in Latin-10 just as well. (Andrei would have to adjudicate on Latin-10's suitability for the 1st and 10th letters, which have comma below. I think Latin-2 has the cedilla form, and Andrei's utf-8 version avoided that.) (BTW I'm not sure about Reco's use of \uc899. Does \u mean that c899 is in utf-8, or should it be followed by a Unicode codepoint, as in U+c899? If the latter, then \uc899 is way off my charts.) However, the actual problem that Russell introduced was how a character set—any character set—should be encoded in the email header parameter's value. And the RFC answer is "not in Base64", which is for unstructured fields, as illustrated by the header of my previous post. Mutt, as expected, writes conformant values but can be instructed to decode particular non-conformant ones. > According to > <https://en.wikipedia.org/wiki/Romanian_alphabet#Digital_typography>, > it originally used ISO 8859-2. … aka Latin-2. Not being Romanian, I can't comment on the relative popularity of that and Latin-10 (ISO 8859-16) or whether the latter was still-born. And… > Of course, it would probably use UTF-8 > on most modern systems. Yes, that also seems more up-to-date and expressive, with support for distinguishing obscure (to me) variants like cedilla vs comma below. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Andrei POPESCU <andreimpopescu@gmail.com> |
|---|---|
| Date | 2020-03-28 09:40 +0100 |
| Subject | Re: HTML mail + PDF attachments (with șurubelniță) |
| Message-ID | <zPfax-10i-1@gated-at.bofh.it> |
| In reply to | #220580 |
[Multipart message — attachments visible in raw view] — view raw
On Vi, 27 mar 20, 23:15:12, David Wright wrote: > > However, the actual problem that Russell introduced was how a > character set—any character set—should be encoded in the email header > parameter's value. And the RFC answer is "not in Base64", which is for > unstructured fields, as illustrated by the header of my previous post. > Mutt, as expected, writes conformant values but can be instructed to > decode particular non-conformant ones. So any test involving mutt as source is irrelevant. > > According to > > <https://en.wikipedia.org/wiki/Romanian_alphabet#Digital_typography>, > > it originally used ISO 8859-2. > > … aka Latin-2. Not being Romanian, I can't comment on the relative > popularity of that and Latin-10 (ISO 8859-16) or whether the latter > was still-born. And… > > > Of course, it would probably use UTF-8 > > on most modern systems. > > Yes, that also seems more up-to-date and expressive, with support for > distinguishing obscure (to me) variants like cedilla vs comma below. Right. <rant> Apparently Microsoft (and Adobe?) had to come up with the support for Romanian by themselves, because the responsible Romanian entities didn't bother at the time. Unfortunately they got it wrong (not blaming them, just stating a fact). The wrong characters are still in use now (even though correct support was included in Windows 7 - for XP there was a language pack), also because many font creators got confused and didn't implement support correctly (missing characters, characters in wrong positions, etc). This (and the fact that many Romanians don't even bother to use any diacritics at all) makes searching for exact strings... challenging. </rant> Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2020-03-30 20:40 +0200 |
| Subject | Re: HTML mail + PDF attachments (with șurubelniță) |
| Message-ID | <zQ7ui-1Va-13@gated-at.bofh.it> |
| In reply to | #220581 |
On Sat 28 Mar 2020 at 10:30:07 (+0200), Andrei POPESCU wrote: > On Vi, 27 mar 20, 23:15:12, David Wright wrote: > > > > However, the actual problem that Russell introduced was how a > > character set—any character set—should be encoded in the email header > > parameter's value. And the RFC answer is "not in Base64", which is for > > unstructured fields, as illustrated by the header of my previous post. > > Mutt, as expected, writes conformant values but can be instructed to > > decode particular non-conformant ones. > > So any test involving mutt as source is irrelevant. Well, I'm not sure who's testing what. AIUI Russell is happy to switch to Thunderbird for those attachments from the cattle raisers association. Richard Hector was unable to save the empty Romanian attachment, so I posted a non-empty version to see whether it was the emptiness or the name that was the problem. No reply. > > > According to > > > <https://en.wikipedia.org/wiki/Romanian_alphabet#Digital_typography>, > > > it originally used ISO 8859-2. > > > > … aka Latin-2. Not being Romanian, I can't comment on the relative > > popularity of that and Latin-10 (ISO 8859-16) or whether the latter > > was still-born. And… > > > > > Of course, it would probably use UTF-8 > > > on most modern systems. > > > > Yes, that also seems more up-to-date and expressive, with support for > > distinguishing obscure (to me) variants like cedilla vs comma below. > > Right. > > <rant> > Apparently Microsoft (and Adobe?) had to come up with the support for > Romanian by themselves, because the responsible Romanian entities didn't > bother at the time. Unfortunately they got it wrong (not blaming them, > just stating a fact). > > The wrong characters are still in use now (even though correct support > was included in Windows 7 - for XP there was a language pack), also > because many font creators got confused and didn't implement support > correctly (missing characters, characters in wrong positions, etc). > > This (and the fact that many Romanians don't even bother to use any > diacritics at all) makes searching for exact strings... challenging. > </rant> Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2020-03-31 01:30 +0200 |
| Subject | Re: HTML mail + PDF attachments (with șurubelniță) |
| Message-ID | <zQc0V-4KN-1@gated-at.bofh.it> |
| In reply to | #220705 |
[Multipart message — attachments visible in raw view] — view raw
On 2020-03-30 at 14:32, David Wright wrote: > On Sat 28 Mar 2020 at 10:30:07 (+0200), Andrei POPESCU wrote: > >> On Vi, 27 mar 20, 23:15:12, David Wright wrote: >> >>> However, the actual problem that Russell introduced was how a >>> character set—any character set—should be encoded in the email >>> header parameter's value. And the RFC answer is "not in Base64", >>> which is for unstructured fields, as illustrated by the header of >>> my previous post. Mutt, as expected, writes conformant values but >>> can be instructed to decode particular non-conformant ones. >> >> So any test involving mutt as source is irrelevant. > > Well, I'm not sure who's testing what. AIUI Russell is happy to > switch to Thunderbird for those attachments from the cattle raisers > association. Richard Hector was unable to save the empty Romanian > attachment, so I posted a non-empty version to see whether it was the > emptiness or the name that was the problem. No reply. FWIW, as another Thunderbird user, I likewise couldn't save the empty attachment (it didn't give an error, when I was using "save as", but the file never showed up in the filesystem), but saving the non-empty one by the exact same method produced a file just fine. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
[toc] | [prev] | [next] | [standalone]
| From | Richard Hector <richard@walnut.gen.nz> |
|---|---|
| Date | 2020-03-31 12:00 +0200 |
| Subject | Re: HTML mail + PDF attachments (with șurubelniță) |
| Message-ID | <zQlQC-2gO-9@gated-at.bofh.it> |
| In reply to | #220705 |
On 31/03/20 7:32 am, David Wright wrote: > Richard Hector was unable to save the empty Romanian attachment, so > I posted a non-empty version to see whether it was the emptiness or > the name that was the problem. No reply. Apologies; that (or at least the intent of it) slipped past me. I can save that one. Cheers, Richard
[toc] | [prev] | [next] | [standalone]
| From | Joe <joe@jretrading.com> |
|---|---|
| Date | 2020-03-28 09:50 +0100 |
| Subject | Re: HTML mail + PDF attachments (with șurubelniță) |
| Message-ID | <zPfkd-13Q-9@gated-at.bofh.it> |
| In reply to | #220580 |
On Sat, 28 Mar 2020 09:41:01 +0100 <tomas@tuxteam.de> wrote: > On Fri, Mar 27, 2020 at 11:15:12PM -0500, David Wright wrote: > > > [Romans] They spoke Vulgar Latin, and that outlived the > > Empire, evolving and dividing into the Romance languages. > > > > But it's strange how an aside can kill the actual discussion of > > email headers. > > :-) > > Yet in some way the topics are strangely intertwined. Vulgar > Latin and rfc822. Big, Bad Empires (in a slow process of decay) > and the power of the network effect. And so on. > > (OK, OK, I'll shut up now ;-) > > Anyway, an interesting discussion. Thanks, y'all. > A good job it didn't attract any of the list topic enforcers, or perhaps they've all moved to a moderated web forum... -- Joe
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2020-03-28 09:50 +0100 |
| Subject | Re: HTML mail + PDF attachments (with șurubelniță) |
| Message-ID | <zPfkd-13Q-7@gated-at.bofh.it> |
| In reply to | #220580 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Mar 27, 2020 at 11:15:12PM -0500, David Wright wrote: > [Romans] They spoke Vulgar Latin, and that outlived the > Empire, evolving and dividing into the Romance languages. > > But it's strange how an aside can kill the actual discussion of > email headers. :-) Yet in some way the topics are strangely intertwined. Vulgar Latin and rfc822. Big, Bad Empires (in a slow process of decay) and the power of the network effect. And so on. (OK, OK, I'll shut up now ;-) Anyway, an interesting discussion. Thanks, y'all. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2020-03-30 13:30 +0200 |
| Subject | Re: HTML mail + PDF attachments (with șurubelniță) |
| Message-ID | <zQ0M9-6gU-1@gated-at.bofh.it> |
| In reply to | #220580 |
On Fri, Mar 27, 2020 at 11:15:12PM -0500, David Wright wrote: > (BTW I'm not sure about Reco's use of \uc899. Does \u mean that > c899 is in utf-8, or should it be followed by a Unicode codepoint, > as in U+c899? If the latter, then \uc899 is way off my charts.) It's a notation used in some programming tools/environments to denote a Unicode code point. E.g. bash's printf and $'...' accept \unnnn or \Unnnnnnnn to denote Unicode code points using either 4 or 8 hex digits. $ printf '\u00f1\n' ñ
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2020-03-30 20:40 +0200 |
| Subject | Re: HTML mail + PDF attachments (with șurubelniță) |
| Message-ID | <zQ7ui-1Va-15@gated-at.bofh.it> |
| In reply to | #220695 |
On Mon 30 Mar 2020 at 07:26:06 (-0400), Greg Wooledge wrote:
> On Fri, Mar 27, 2020 at 11:15:12PM -0500, David Wright wrote:
> > (BTW I'm not sure about Reco's use of \uc899. Does \u mean that
> > c899 is in utf-8, or should it be followed by a Unicode codepoint,
> > as in U+c899? If the latter, then \uc899 is way off my charts.)
>
> It's a notation used in some programming tools/environments to denote
> a Unicode code point.
>
> E.g. bash's printf and $'...' accept \unnnn or \Unnnnnnnn to denote
> Unicode code points using either 4 or 8 hex digits.
>
> $ printf '\u00f1\n'
> ñ
Of course! With well over a decade of using Unicode natively, I had
forgotten that people would want to do that. And refreshing bash's
prompt escape syntax last December (\D{}, \u etc) completely wiped
it from my mind.
So one has to be careful not to translate
Content-Disposition: attachment; filename*=utf-8''%C8%99urubelni%C8%9B%C4%83_empty%2Etxt
into Unicode codepoints like \uc899 because it's utf-8, not utf-32.
Cheers,
David.
[toc] | [prev] | [next] | [standalone]
| From | "Russell L. Harris" <russell@rlharris.org> |
|---|---|
| Date | 2020-03-27 21:10 +0100 |
| Subject | Re: HTML mail + PDF attachments (with ??urubelni????) |
| Message-ID | <zP3sJ-2ft-3@gated-at.bofh.it> |
| In reply to | #220567 |
>On Fri 27 Mar 2020 at 17:35:19 (+0300), Reco wrote: >I think we can agree that the Romans spoke Latin! Actually, Latin was the official, legal language of Rome. The previous conquests of Alexander the Great established the Koine dialect of Greek as the "lingua franca" of the Ancient World. Koine (meaning "common") was the language of commerce and trade. Because both Latin and Koine were in constant use, there are many "exact equivalents" between Latin and Koine words and phrases. I expect that, for Romans in general, fluency in Koine may have been more common that fluency in Latin. RLH
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2020-03-27 13:30 +0100 |
| Message-ID | <zOWhz-66d-5@gated-at.bofh.it> |
| In reply to | #220546 |
[Multipart message — attachments visible in raw view] — view raw
On Mar 27, 2020, Andrei POPESCU wrote: > On Jo, 26 mar 20, 18:41:10, Reco wrote: > > On Thu, Mar 26, 2020 at 08:53:35AM +0000, Russell L. Harris wrote: > > > > > > I understand. But some of the stuff I receive does not work as > > > expected. What do I do with the following PDF: > > > > > > =?utf-8?B?QkhfODU0MDk2MjMwLnBkZg==?= > > > > Read muttrc(5), insert "rfc2047_parameters=true" in your .muttrc. > > Nice one, added. Wondering why it's not the default though... Hmm, I must have an old version of Mutt (not surprising ...); I needed to use "rfc2047_parameters=yes". -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2020-03-27 13:30 +0100 |
| Message-ID | <zOWhA-66d-21@gated-at.bofh.it> |
| In reply to | #220557 |
[Multipart message — attachments visible in raw view] — view raw
On Mar 27, 2020, Dan Purgert wrote: > On Mar 27, 2020, Andrei POPESCU wrote: > > On Jo, 26 mar 20, 18:41:10, Reco wrote: > > > On Thu, Mar 26, 2020 at 08:53:35AM +0000, Russell L. Harris wrote: > > > > > > > > I understand. But some of the stuff I receive does not work as > > > > expected. What do I do with the following PDF: > > > > > > > > =?utf-8?B?QkhfODU0MDk2MjMwLnBkZg==?= > > > > > > Read muttrc(5), insert "rfc2047_parameters=true" in your .muttrc. > > > > Nice one, added. Wondering why it's not the default though... > > Hmm, I must have an old version of Mutt (not surprising ...); I needed > to use "rfc2047_parameters=yes". Scratch that, I tacked on 'set' to the beginning, which requires the 'yes/no' syntax. -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
[toc] | [prev] | [next] | [standalone]
| From | Andrei POPESCU <andreimpopescu@gmail.com> |
|---|---|
| Date | 2020-03-28 10:00 +0100 |
| Message-ID | <zPftT-178-9@gated-at.bofh.it> |
| In reply to | #220546 |
[Multipart message — attachments visible in raw view] — view raw
On Vi, 27 mar 20, 10:51:46, Andrei POPESCU wrote: > On Jo, 26 mar 20, 18:41:10, Reco wrote: > > On Thu, Mar 26, 2020 at 08:53:35AM +0000, Russell L. Harris wrote: > > > > > > I understand. But some of the stuff I receive does not work as > > > expected. What do I do with the following PDF: > > > > > > =?utf-8?B?QkhfODU0MDk2MjMwLnBkZg==?= > > > > Read muttrc(5), insert "rfc2047_parameters=true" in your .muttrc. > > Nice one, added. Wondering why it's not the default though... Filled as #955198 (wishlist). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
[toc] | [prev] | [next] | [standalone]
| From | Jason <electron@emypeople.net> |
|---|---|
| Date | 2020-04-13 19:40 +0200 |
| Message-ID | <zVbdT-19m-1@gated-at.bofh.it> |
| In reply to | #220506 |
On Thu, Mar 26, 2020 at 08:53:35AM +0000, Russell L. Harris composed: > All things considered, I am thinking that the best solution is to set > up a POP account on another domain and configure Thunderbird to fetch > mail from that location. Then all I need to do in mutt is to forward > troublesome messages to that account. > As another option, both getmail and thunderbird can be configured to leave messages on the server and then delete them a certain number of days after retrieval. Using that feature in getmail, you could access the same messages in thunderbird, and tell thunderbird to not delete messages. As for PDF attachments, I use getmail to deliver to maildrop, which then runs a copy of the email through ripmime to automatically save the attachments to a directory. -- Jason
[toc] | [prev] | [next] | [standalone]
| From | "Russell L. Harris" <russell@rlharris.org> |
|---|---|
| Date | 2020-04-13 20:50 +0200 |
| Message-ID | <zVcjD-1MJ-1@gated-at.bofh.it> |
| In reply to | #221430 |
On Mon, Apr 13, 2020 at 12:01:47PM -0500, Jason wrote: > >As another option, both getmail and thunderbird can be configured to >leave messages on the server and then delete them a certain number of >days after retrieval. Using that feature in getmail, you could access >the same messages in thunderbird, and tell thunderbird to not delete >messages. Thanks for jogging my memory. It has been so long since I configured getmail that I forgot that getmail can serve unrelated accounts and deliver to multiple locations, each with its own structure (mbox or maildir). I suppose I need to reduce the limit of the number of messages downloaded in a sesson, so as to enable more frequent checks for incoming messages. At present getmail runs every three minutes. But I do not have a feel for the load imposed on a mail server by frequent checks. Would an ISP frown on a check every minute? >As for PDF attachments, I use getmail to deliver to maildrop, which >then runs a copy of the email through ripmime to automatically save >the attachments to a directory. And I keep forgetting about maildrop, which I have used in the past. RLH
[toc] | [prev] | [next] | [standalone]
| From | Andrei POPESCU <andreimpopescu@gmail.com> |
|---|---|
| Date | 2020-04-14 09:00 +0200 |
| Message-ID | <zVnI5-KH-3@gated-at.bofh.it> |
| In reply to | #221437 |
[Multipart message — attachments visible in raw view] — view raw
On Lu, 13 apr 20, 18:43:53, Russell L. Harris wrote: > On Mon, Apr 13, 2020 at 12:01:47PM -0500, Jason wrote: > > > > As another option, both getmail and thunderbird can be configured to > > leave messages on the server and then delete them a certain number of > > days after retrieval. Using that feature in getmail, you could access > > the same messages in thunderbird, and tell thunderbird to not delete > > messages. > > Thanks for jogging my memory. It has been so long since I configured > getmail that I forgot that getmail can serve unrelated accounts and > deliver to multiple locations, each with its own structure (mbox or > maildir). > > I suppose I need to reduce the limit of the number of messages > downloaded in a sesson, so as to enable more frequent checks for > incoming messages. What benefit would this bring? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
[toc] | [prev] | [next] | [standalone]
| From | "Russell L. Harris" <russell@rlharris.org> |
|---|---|
| Date | 2020-04-14 09:30 +0200 |
| Message-ID | <zVob8-1a0-7@gated-at.bofh.it> |
| In reply to | #221474 |
On Tue, Apr 14, 2020 at 09:51:38AM +0300, Andrei POPESCU wrote: >> I suppose I need to reduce the limit of the number of messages >> downloaded in a sesson, so as to enable more frequent checks for >> incoming messages. > >What benefit would this bring? Perhaps once a month or once every other month, I am on the telephone with a party who is sending me an email, typically with an attachment. And typically I have been "on hold" on the phone for a half hour to reach that individual. So the other guy says, "I just sent the message; tell me when you receive it." And I must reply, "My system checks for new messages only every three minutes." And then three minutes pass as we discuss the weather, and still the message has not arrived. So the other guy sends the message again, and we wait another three minutes, and sometimes longer. For some reason, messages from one of the larger domain registration outfits routinely take twelve hours to reach me; that was the case two or three times within the past few months. So in such instances, it would be nice to check for new mail once a minute. Even better would be a check made immediately upon demand; I know how to do that, and I have done it before. But most of the time, a check every half hour would be adequate. RLH
[toc] | [prev] | [next] | [standalone]
| From | Andrei POPESCU <andreimpopescu@gmail.com> |
|---|---|
| Date | 2020-04-14 10:20 +0200 |
| Message-ID | <zVoXv-1FM-5@gated-at.bofh.it> |
| In reply to | #221476 |
[Multipart message — attachments visible in raw view] — view raw
On Ma, 14 apr 20, 07:25:28, Russell L. Harris wrote: > On Tue, Apr 14, 2020 at 09:51:38AM +0300, Andrei POPESCU wrote: > > > I suppose I need to reduce the limit of the number of messages > > > downloaded in a sesson, so as to enable more frequent checks for > > > incoming messages. > > > > What benefit would this bring? > > Perhaps once a month or once every other month, I am on the telephone > with a party who is sending me an email, typically with an attachment. > And typically I have been "on hold" on the phone for a half hour to > reach that individual. So the other guy says, "I just sent the > message; tell me when you receive it." And I must reply, "My system > checks for new messages only every three minutes." Ah, the classic (ab)use of e-mail as instant messaging and/or file transfer. > And then three minutes pass as we discuss the weather, and still the > message has not arrived. So the other guy sends the message again, > and we wait another three minutes, and sometimes longer. For some > reason, messages from one of the larger domain registration outfits > routinely take twelve hours to reach me; that was the case two or > three times within the past few months. Increasing check frequency wouldn't help with this. It could be some anti-spam measure (greylisting). Maybe your provider allows some mechanism to whitelist a domain and/or e-mail address, likely via the web interface (if there is one). > So in such instances, it would be nice to check for new mail once a > minute. Even better would be a check made immediately upon demand; I > know how to do that, and I have done it before. But most of the time, > a check every half hour would be adequate. For an instant-like experience with e-mail you need push, not pull (e.g. like the IMAP IDLE extension). You would have to replace getmail with something like offlineimap or interimap (not familiar with either, so can't tell if they would actually work for that and/or fit your needs). If you want to explore this path I suggest you start a new thread and explain what such a system would need to achieve (e.g. full offline copy of all messages, sorting/filtering), *not how*, and if there are any objective or subjective constraints (e.g. e-mail provider that can't be changed, e-mail client you won't part with, etc.) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2020-04-14 22:30 +0200 |
| Message-ID | <zVAlX-bB-1@gated-at.bofh.it> |
| In reply to | #221476 |
On Tue 14 Apr 2020 at 07:25:28 (+0000), Russell L. Harris wrote: > On Tue, Apr 14, 2020 at 09:51:38AM +0300, Andrei POPESCU wrote: > > > I suppose I need to reduce the limit of the number of messages > > > downloaded in a sesson, so as to enable more frequent checks for > > > incoming messages. > > > > What benefit would this bring? > > Perhaps once a month or once every other month, I am on the telephone > with a party who is sending me an email, typically with an attachment. > And typically I have been "on hold" on the phone for a half hour to > reach that individual. So the other guy says, "I just sent the > message; tell me when you receive it." And I must reply, "My system > checks for new messages only every three minutes." > > And then three minutes pass as we discuss the weather, and still the > message has not arrived. So the other guy sends the message again, > and we wait another three minutes, and sometimes longer. For some > reason, messages from one of the larger domain registration outfits > routinely take twelve hours to reach me; that was the case two or > three times within the past few months. > > So in such instances, it would be nice to check for new mail once a > minute. Even better would be a check made immediately upon demand; I > know how to do that, and I have done it before. But most of the time, > a check every half hour would be adequate. Have you examined the timestamps in the email header of such emails in order to see where the holdup is occurring. It may or may not be in the last hop. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | "Russell L. Harris" <russell@rlharris.org> |
|---|---|
| Date | 2020-04-14 23:20 +0200 |
| Message-ID | <zVB8m-Nc-1@gated-at.bofh.it> |
| In reply to | #221555 |
On Tue, Apr 14, 2020 at 03:19:57PM -0500, David Wright wrote: >Have you examined the timestamps in the email header of such emails in >order to see where the holdup is occurring. It may or may not be in >the last hop. You embarrass me, David! It did not occur to me that the header would contain time stamps, so I did not examine them. The messages already are deleted. RLH
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | linux.debian.user
csiph-web