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

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

HTTP shimmed to HTTPS; was Re: stunnel as transparent proxy.

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

  HTTP shimmed to HTTPS; was Re: stunnel as transparent proxy. peter@easthope.ca - 2019-07-18 00:20 +0200
    Re: HTTP shimmed to HTTPS; was Re: stunnel as transparent proxy. Reco <recoverym4n@enotuniq.net> - 2019-07-18 09:20 +0200
      Re: Shimming HTTP to HTTPS. peter@easthope.ca - 2019-07-28 18:40 +0200
        Re: Shimming HTTP to HTTPS. Reco <recoverym4n@enotuniq.net> - 2019-07-28 19:00 +0200
          Re: Shimming HTTP to HTTPS. David Wright <deblis@lionunicorn.co.uk> - 2019-07-29 02:50 +0200
          Re: Shimming HTTP to HTTPS. peter@easthope.ca - 2019-08-22 18:10 +0200
            Re: Shimming HTTP to HTTPS. Reco <recoverym4n@enotuniq.net> - 2019-08-22 19:40 +0200
          Re: Shimming HTTP to HTTPS. peter@easthope.ca - 2019-08-23 19:30 +0200
        Re: Shimming HTTP to HTTPS. David Wright <deblis@lionunicorn.co.uk> - 2019-07-29 02:50 +0200
          Re: Shimming HTTP to HTTPS. Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-29 08:30 +0200
            Re: Shimming HTTP to HTTPS. David Wright <deblis@lionunicorn.co.uk> - 2019-07-29 18:50 +0200
          Re: Shimming HTTP to HTTPS. peter@easthope.ca - 2019-08-14 05:10 +0200
            Re: Shimming HTTP to HTTPS. David Wright <deblis@lionunicorn.co.uk> - 2019-08-15 00:10 +0200

#211488 — HTTP shimmed to HTTPS; was Re: stunnel as transparent proxy.

Jul 16 11:25:16 joule stunnel: LOG5[4]: Service [https] accepted connection from 127.0.0.1:36140

*	From: Reco recoverym4n@enotuniq.net
*	Date: Wed, 17 Jul 2019 11:01:32 +0300
> No, you're incorrect. A client application has connected to
> localhost:443 using source IP 127.0.0.1 and a destination port 36140.

OK, thanks.  Can you tell me how "36140" originates?  Not immediately 
obvious that this application produces it.  Also not listed here.
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

> stunnel(1) mentions helpfully that you're required to have  a certain
> netfilter setup (mainly involving DNAT in your case), ... 
> If you need to transform outbound HTTP requests to HTTPS to multiple
> hosts ...

Yes, I have a Web browser capable of HTTP and not HTTPS. The immediate 
objective is that the browser requests 
https://en.wikipedia.org/wiki/Network_socket , for example, the 
communication is TLS encrypted and issued to the original address.  
The returned packets should be decrypted.  Should work for any address 
of course but no address translation.  Shim might describe the action 
better than proxy.
                                                                                                                                                       
> you'll probably need squid/haproxy/nginx/whatever.

Never used any of these.  "/" means "or"?  Shorewall is working here.  
If that can apply TLS, good.  What is the simplest package that can 
provide this?

Thanks,              ... Peter E.
                               




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

[toc] | [next] | [standalone]

#211500

On Wed, Jul 17, 2019 at 02:32:28PM -0700, peter@easthope.ca wrote:
> > stunnel(1) mentions helpfully that you're required to have  a certain
> > netfilter setup (mainly involving DNAT in your case), ... 
> > If you need to transform outbound HTTP requests to HTTPS to multiple
> > hosts ...
> 
> Yes, I have a Web browser capable of HTTP and not HTTPS. The immediate 
> objective is that the browser requests 
> https://en.wikipedia.org/wiki/Network_socket , for example, the 
> communication is TLS encrypted and issued to the original address.  
> The returned packets should be decrypted.  Should work for any address 
> of course but no address translation.  Shim might describe the action 
> better than proxy.

stunnel is unsuitable for such task.

>                                                                                                                                                        
> > you'll probably need squid/haproxy/nginx/whatever.
> 
> Never used any of these.  "/" means "or"?

Yes, it meant "or".
You need a specific kind of forward proxy, capable of transforming
HTTP to HTTPS (to do actual requests) and back (to send'em to a
browser).

> Shorewall is working here. If that can apply TLS, good.

No it cannot. Shorewall is a frontend to netfilter kernel subsystem.
It can do all kinds of things as long as they do not exceed L4 (as in
OSI L4, transport layer). What you want to do is to apply a
transformation to L7 (application layer), and that's something that
netfilter cannot do.

> What is the simplest package that can provide this?

For a bunch of sites - apache or nginx.
For the whole Internet - *maybe* (and that's a big one) squid can do the
job. Most probably you'll need a very creative usage of ProxHTTPSProxy
(not in Debian) or its equivalent.

Reco

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

#211833 — Re: Shimming HTTP to HTTPS.

Appears that the less-than and greater-than signs were replaced with 
the null character.  I'm not sure why but will try to prevent henceforth.

The In-reply-to and References above should be right except that there 
is no magnifying glass link.  This is email.  Not HTML.

*	From: Reco 
*	Date: Thu, 18 Jul 2019 10:13:58 +0300
> Shorewall is a frontend to netfilter kernel subsystem.
> It can do all kinds of things as long as they do not exceed L4 (as in
> OSI L4, transport layer). What you want to do is to apply a
> transformation to L7 (application layer), and that's something that
> netfilter cannot do.

OK, good.  In case anyone is interested, this is from  
https://en.wikipedia.org/wiki/Transport_Layer_Security .
"TLS and SSL do not fit neatly into any single layer of the OSI model 
or the TCP/IP model.[8][9] TLS runs "on top of some reliable transport 
protocol (e.g., TCP),"[10] which would imply that it is above the 
transport layer. It serves encryption to higher layers, which is 
normally the function of the presentation layer. However, applications 
generally use TLS as if it were a transport layer,[8][9] even though 
applications using TLS must actively control initiating TLS handshakes 
and handling of exchanged authentication certificates.[10]"

There are two kinds of browser here.  (1) Firefox and dillo which handle 
HTTP and HTTPS properly.  (2) The Oberon browser which currently handles 
only HTTP.

So this is the problem which interests me.
When firefox or dillo requests any URL, process it as usual.
When the Oberon browser requests a HTTP URL, process it as usual.
When the Oberon browser requests a HTTPS URL, divert it and apply TLS.

Not obvious how these three cases should be separated but this is an 
idea. For Oberon HTTPS I choose a private port which won't interfere 
with anything else.  65535 for example.  To open a HTTPS page with 
Oberon, request this URL: HTTP://<domain>:65535/<path>.  In the host 
system, where the Oberon browser is running, set up a proxy to 
intercept traffic to 65535 and apply TLS.  

Any sense in that?  Further tips welcome of course.

Thanks,                            ... P.

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

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

#211834 — Re: Shimming HTTP to HTTPS.

	Hi.

On Sun, Jul 28, 2019 at 09:17:21AM -0700, peter@easthope.ca wrote:
> The In-reply-to and References above should be right except that there 
> is no magnifying glass link.  This is email.  Not HTML.

It may sound boring, but there's no "In-reply-to". There's "In-Reply-To".
Yes, case matters. "References" header seems good though.


> > Shorewall is a frontend to netfilter kernel subsystem.
> > It can do all kinds of things as long as they do not exceed L4 (as in
> > OSI L4, transport layer). What you want to do is to apply a
> > transformation to L7 (application layer), and that's something that
> > netfilter cannot do.
> 
> There are two kinds of browser here.
> (1) Firefox and dillo which handle HTTP and HTTPS properly.

You may be surprised. Contrary to what they tell at Mozilla, NSS is not
the best TLS implementation. There's some hope for dillo depending on if
it uses openssl or gnutls.

> (2) The Oberon browser which currently handles only HTTP.
> 
> So this is the problem which interests me.
> When firefox or dillo requests any URL, process it as usual.

Ok. Sounds simple.

> When the Oberon browser requests a HTTP URL, process it as usual.

Ok, any conventional HTTP forward proxy should do here.

> When the Oberon browser requests a HTTPS URL, divert it and apply TLS.

Have you meant "Oberon sends HTTP request that should be transformed to
HTTPS"? That's where that hypothetical proxy comes in.


If yes, you forgot at least two other interesting cases:

Oberon browser sends HTTP request, but gets HTTPS redirect (301/302) in
result.
Oberon browser sends HTTP request, proxy transforms it into HTTPS, gets
HTTPS reply, transforms it back into HTTP reply ... only to send Oberon
browser a huge pile of HTTPS links to pictures, css, js and whatnot.


Putting some thought into this, you need [1].
It may sound strange, but why bother reimplementing half of a browser
inside of a proxy, if you can make a browser serve a proxy role?

Reco

[1] https://github.com/tenox7/wrp

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

#211842 — Re: Shimming HTTP to HTTPS.

On Sun 28 Jul 2019 at 19:57:19 (+0300), Reco wrote:
> On Sun, Jul 28, 2019 at 09:17:21AM -0700, peter@easthope.ca wrote:
> > The In-reply-to and References above should be right except that there 
> > is no magnifying glass link.  This is email.  Not HTML.
> 
> It may sound boring, but there's no "In-reply-to". There's "In-Reply-To".
> Yes, case matters. "References" header seems good though.

Case matters inside the <string>, but not for the Header Field Name itself.

Cheers,
David.

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

#213111 — Re: Shimming HTTP to HTTPS.

*	From: Reco 
*	Date: Sun, 28 Jul 2019 19:57:19 +0300
> ... NSS is not the best TLS implementation. There's some hope for 
> dillo depending on if it uses openssl or gnutls.

How do you evaluate these?  Published review?  Study of sources?

> Have you meant "Oberon sends HTTP request that should be transformed to
> HTTPS"? That's where that hypothetical proxy comes in.

OK, yes.  If http://en.wikipedia.org/wiki/Linux is put in the URL bar 
of dillo, it opens https://en.wikipedia.org/wiki/Linux. If 
https://en.wikipedia.org/wiki/Linux is put in the URL bar,  dillo 
opens it.  I imagine similar behaviour in Oberon.

> Oberon browser sends HTTP request, but gets HTTPS redirect (301/302) in
> result.

Yes; ideally, redirection is handled gracefully.

> Oberon browser sends HTTP request, proxy transforms it into HTTPS, gets
> HTTPS reply, transforms it back into HTTP reply ... only to send Oberon
> browser a huge pile of HTTPS links to pictures, css, js and whatnot.

For now I'd be happy if Oberon could open the text in a 
simple page.  https://en.wikibooks.org/wiki/Oberon/S3/2003-01-05/Mail.Mod
for example.

> [1] https://github.com/tenox7/wrp

Appears that a X86-64 or ARM system is required.  Or possibly compile 
the source for the old 32 system here; athough, if this could work the 
binary would probably be available.

Probably better to forget this approach and work on SSL/TLS for 
Oberon. Dillo works quite well.  No reason Oberon can't.

Thanks,                                     ... P.

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

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

#213118 — Re: Shimming HTTP to HTTPS.

	Hi.

On Thu, Aug 22, 2019 at 08:23:06AM -0700, peter@easthope.ca wrote:
> *	From: Reco 
> *	Date: Sun, 28 Jul 2019 19:57:19 +0300
> > ... NSS is not the best TLS implementation. There's some hope for 
> > dillo depending on if it uses openssl or gnutls.
> 
> How do you evaluate these?  Published review?  Study of sources?

Easy. Take a server software that's intended to be used in Internet
environment. Look at its dependencies. Observe that it's either openssl
or gnutls or (very rare) mbedtls.
NSS is a popular choice for client software, relative ease of use being
its only redeeming quality.


> > Have you meant "Oberon sends HTTP request that should be transformed to
> > HTTPS"? That's where that hypothetical proxy comes in.
> 
> OK, yes.  If http://en.wikipedia.org/wiki/Linux is put in the URL bar 
> of dillo, it opens https://en.wikipedia.org/wiki/Linux. If 
> https://en.wikipedia.org/wiki/Linux is put in the URL bar,  dillo 
> opens it.  I imagine similar behaviour in Oberon.

Relatively simple, but see below.


> > Oberon browser sends HTTP request, but gets HTTPS redirect (301/302) in
> > result.
> 
> Yes; ideally, redirection is handled gracefully.

That's two different cases, this and the previous one.
The difference being - in this case a hypothetical proxy should
intercept a redirect, make HTTPS request on its own, get HTTP response
and present it to the browser as if redirect never happened.
And I can count at least three different ways of doing such redirect -
classic 301/302 HTTP code, <meta> redirect in HTML page, and Javascript
one. But again, see below.


> > Oberon browser sends HTTP request, proxy transforms it into HTTPS, gets
> > HTTPS reply, transforms it back into HTTP reply ... only to send Oberon
> > browser a huge pile of HTTPS links to pictures, css, js and whatnot.
> 
> For now I'd be happy if Oberon could open the text in a 
> simple page.  https://en.wikibooks.org/wiki/Oberon/S3/2003-01-05/Mail.Mod
> for example.

Your link is a good example of case 3 - HTTP response peppered with
multiple HTTPS links. Hence, [1] is about the only reasonable choice you
have.

If you need an example of easy page, pardon the obscene lyrics, you need
this:

https://evenbettermotherfucking.website/


> > [1] https://github.com/tenox7/wrp
> 
> Appears that a X86-64 or ARM system is required.

So? There's no law that requires a proxy to be on the same host as a
browser.

Reco

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

#213157 — Re: Shimming HTTP to HTTPS.

*	From: Reco 
*	Date: Sun, 28 Jul 2019 19:57:19 +0300
> ... NSS is not the best TLS implementation. 

OK!  An assertion from an authority.  Probably true but I'd want 
to corroborate before restating under oath.  =8~))

> There's some hope for dillo depending on if it uses openssl or gnutls.

Not sure of your meaning.  I don't know which TLS dillo uses.
In my understanding there are two possibilities:
(1) dillo uses openssl or gnutls.  Good.  Both are better than NSS;
or 
(2) one of openssl and gnutls is significantly better than the other.
If dillo uses the "right one"--good.  If dillo uses the "wrong one"--bad.

*	From: Reco 
*	Date: Thu, 22 Aug 2019 20:32:33 +0300
> Your link is a good example of case 3 - HTTP response peppered with
> multiple HTTPS links.

The links are in the Wikimedia boilerplate.  Few or zero links 
in the textual content.

> Hence, [1] is about the only reasonable choice you have.

Low maintenance solution: http://www.loband.org/

> If you need an example of easy page, pardon the obscene lyrics, you need
> this:
> 
> https://evenbetter ...

Interesting.  Firefox displays a tidy page.  Dillo displays nothing. 
Yah, the WWW has become a gong show.  I appreciate the exasperation 
expressed in parody.  Some pages are still worth attention.  I wonder 
whether a winnowing could be automated.  Detect pages where the 
content isn't obscured by the icing or find such pages.

A good solution for Oberon S3 would be to make TLS work.  Not sure I 
want to tackle it.

Thanks for the replies,                  ... P.

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

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

#211841 — Re: Shimming HTTP to HTTPS.

On Sun 28 Jul 2019 at 09:17:21 (-0700), peter@easthope.ca wrote:
> Appears that the less-than and greater-than signs were replaced with 
> the null character.  I'm not sure why but will try to prevent henceforth.
> 
> The In-reply-to and References above should be right except that there 
> is no magnifying glass link.  This is email.  Not HTML.

Yes, that's looking good, thanks.

The following scenario, where I write "you do this&that", is all
guesswork because it's not easy to divine exactly what you do
when you reply to a post.

You read postings on the web with a browser. When you want to reply,
you open a composition window and paste in the To/Cc/Subject headers
from the web page.¹

I can't determine what happens when you cut and paste the Message-ID
± References lines but I suspect the exotic characters may be
causing odd effects as you delete them. In particular, you may find
some terminals/editors miscalculate the position of the cursor,
displaying it on a neighbouring character.² (This may be why you
could think you deleted the NUL/magnifier, leaving the <, but
actually delete the <, leaving the NUL.)

You've mentioned "magnifying glass link" before, and I get the
impression that you think the magnifying glass *is* the link.
Actually it's just a symbol character enclosed in [], and needn't
appear on the page at all (because the [] characters are just as
good for clicking on).

The link itself is a URL as usual. For the message I'm replying to
now, the Message-ID is <E1hrlrN-0002IM-Cf@joule.invalid> and the
corresponding link³ on the web page (under the magnifier) is
https://lists.debian.org/msgid-search/E1hrlrN-0002IM-Cf@joule.invalid

But the point is that Message-ID:s, In-Reply-To:s and References:
in *emails* are not URLs, but <strings>, even though their text
is used to mark links on the web page.

Apologies if these guesses are off the mark.

¹ I had assumed you'd be cut-and-pasting from an email header, not
  the web page.

² Eg,  emacs -nw  in an xterm does this.

³ I must admit that I've never discovered a use for that style of link:
  the https://lists.debian.org/debian-user/2019/07/msg01334.html URL
  seems much more useful for citations in posts.

Cheers,
David.

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

#211843 — Re: Shimming HTTP to HTTPS.

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

On Du, 28 iul 19, 19:40:04, David Wright wrote:
> 
> The link itself is a URL as usual. For the message I'm replying to
> now, the Message-ID is <E1hrlrN-0002IM-Cf@joule.invalid> and the
> corresponding link³ on the web page (under the magnifier) is
> https://lists.debian.org/msgid-search/E1hrlrN-0002IM-Cf@joule.invalid
 
[...]

> ³ I must admit that I've never discovered a use for that style of link:
>   the https://lists.debian.org/debian-user/2019/07/msg01334.html URL
>   seems much more useful for citations in posts.

One can construct the link just with information available in the mail 
to be referenced, including off-line and possibly even in advance if one 
can convince the mail client to generate the Msg-ID before sending.


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#211879 — Re: Shimming HTTP to HTTPS.

On Mon 29 Jul 2019 at 09:22:24 (+0300), Andrei POPESCU wrote:
> On Du, 28 iul 19, 19:40:04, David Wright wrote:
> > 
> > The link itself is a URL as usual. For the message I'm replying to
> > now, the Message-ID is <E1hrlrN-0002IM-Cf@joule.invalid> and the
> > corresponding link³ on the web page (under the magnifier) is
> > https://lists.debian.org/msgid-search/E1hrlrN-0002IM-Cf@joule.invalid
>  
> [...]
> 
> > ³ I must admit that I've never discovered a use for that style of link:
> >   the https://lists.debian.org/debian-user/2019/07/msg01334.html URL
> >   seems much more useful for citations in posts.
> 
> One can construct the link just with information available in the mail 
> to be referenced, including off-line and possibly even in advance if one 
> can convince the mail client to generate the Msg-ID before sending.

I suppose I can see that that might be useful in some circumstances.
But even so, it seems an odd way to present them on the web page,
*inside* the <> of the Message-ID/In-Reply-To/References. While
admitting that the post displayed on the web is not *actually* an
email, I would say that inserting extraneous junk between the <>
characters goes against the spirit of RFC2822:

3.6.4. Identification fields

   Though optional, every message SHOULD have a "Message-ID:" field.
   Furthermore, reply messages SHOULD have "In-Reply-To:" and
   "References:" fields as appropriate, as described below.

   The "Message-ID:" field contains a single unique message identifier.
   The "References:" and "In-Reply-To:" field each contain one or more
   unique message identifiers, optionally separated by CFWS.

   The message identifier (msg-id) is similar in syntax to an angle-addr
   construct without the internal CFWS.
             ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑                             ← my addition

message-id      =       "Message-ID:" msg-id CRLF
in-reply-to     =       "In-Reply-To:" 1*msg-id CRLF
references      =       "References:" 1*msg-id CRLF
msg-id          =       [CFWS] "<" id-left "@" id-right ">" [CFWS]
id-left         =       dot-atom-text / no-fold-quote / obs-id-left
id-right        =       dot-atom-text / no-fold-literal / obs-id-right
no-fold-quote   =       DQUOTE *(qtext / quoted-pair) DQUOTE
no-fold-literal =       "[" *(dtext / quoted-pair) "]"

Why not put the link outside, say after, the <> and dress it up as a comment
(the C in CFWS).

Cheers,
David.

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

#212769 — Re: Shimming HTTP to HTTPS.

Sorry for the late reply.

From: David Wright
Date: Sun, 28 Jul 2019 19:40:04 -0500
> You read postings on the web with a browser. When you want to reply,
> you open a composition window and paste in the To/Cc/Subject headers
> from the web page.

Correct.

> But the point is that Message-ID:s, In-Reply-To:s and References:
> in *emails* are not URLs, but <strings>, even though their text
> is used to mark links on the web page.

OK, thanks.  For the In-Reply-To above I omitted the link string.
Hopefully I got the right message.

> Bingo. Then it looks as if all my guesses in
> https://lists.debian.org/debian-user/2019/07/msg01343.html
> were basically correct.

Yes.  My worst error, which spoiled the References, was to omit < and >. 

> > https://en.wikibooks.org/wiki/Oberon#Getting_Started and references 
> > there.
> 
> I looked at that page some while back. Without seeing it in action,
> I think I'd have difficulty in recommending any software suitable
> for it ...

It's self contained.  The entire MUA in one module.
Nothing to add; just install and use.

> If you're typing (or pasting) the references, ...

One mouse action does copy and paste.

> I would just add
> the In-Reply-To instead. That way, you can Cut/Copy the original's
> 
>   Message-ID: <bla bla bla>
> 
> Paste the line untouched, then edit *just* these characters:
> 
>   Message-ID:    change into    In-Reply-To:
> 
> which will make your message thread correctly.

OK.  Will see the result with In-Reply-To only for this message.

Thanks,              ... Peter E.



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

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

#212822 — Re: Shimming HTTP to HTTPS.

On Tue 13 Aug 2019 at 18:55:15 (-0700), peter@easthope.ca wrote:
> Sorry for the late reply.
> 
> From: David Wright
> Date: Sun, 28 Jul 2019 19:40:04 -0500
> > You read postings on the web with a browser. When you want to reply,
> > you open a composition window and paste in the To/Cc/Subject headers
> > from the web page.
> 
> Correct.
> 
> > But the point is that Message-ID:s, In-Reply-To:s and References:
> > in *emails* are not URLs, but <strings>, even though their text
> > is used to mark links on the web page.
> 
> OK, thanks.  For the In-Reply-To above I omitted the link string.
> Hopefully I got the right message.

Yes, the right message, and it's threaded correctly in my mailbox.
We can't be certain on the web because the month has changed.

> > Bingo. Then it looks as if all my guesses in
> > https://lists.debian.org/debian-user/2019/07/msg01343.html
> > were basically correct.
> 
> Yes.  My worst error, which spoiled the References, was to omit < and >. 
> 
> > > https://en.wikibooks.org/wiki/Oberon#Getting_Started and references 
> > > there.
> > 
> > I looked at that page some while back. Without seeing it in action,
> > I think I'd have difficulty in recommending any software suitable
> > for it ...
> 
> It's self contained.  The entire MUA in one module.
> Nothing to add; just install and use.

I wasn't referring to the MUA that you're using in Oberon, but to the
whole Oberon System itself. From your reference, I'm assuming you're
using the Oberon Mail MUA on the Oberon System, the latter described at
https://www.inf.ethz.ch/personal/wirth/ProjectOberon/UsingOberon.pdf

> > If you're typing (or pasting) the references, ...
> 
> One mouse action does copy and paste.
> 
> > I would just add
> > the In-Reply-To instead. That way, you can Cut/Copy the original's
> > 
> >   Message-ID: <bla bla bla>
> > 
> > Paste the line untouched, then edit *just* these characters:
> > 
> >   Message-ID:    change into    In-Reply-To:
> > 
> > which will make your message thread correctly.
> 
> OK.  Will see the result with In-Reply-To only for this message.

It's fine. Don't get hung up on the Capitalisation, but just
concentrate on an unadorned <message-id-string> taken from the
post being replied to, copied into your post's in-reply-to
field and/or into the last item in your references field.

Cheers,
David.

[toc] | [prev] | [standalone]

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

csiph-web