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

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

Re: HTTP shimmed to HTTPS

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

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

Contents

  Re: HTTP shimmed to HTTPS peter@easthope.ca - 2019-07-22 15:50 +0200
    Re: HTTP shimmed to HTTPS Reco <recoverym4n@enotuniq.net> - 2019-07-22 16:50 +0200
    Re: HTTP shimmed to HTTPS rhkramer@gmail.com - 2019-07-22 17:10 +0200
      Re: HTTP shimmed to HTTPS Andy Smith <andy@strugglers.net> - 2019-07-22 17:20 +0200
        Re: HTTP shimmed to HTTPS rhkramer@gmail.com - 2019-07-22 17:50 +0200
          Re: HTTP shimmed to HTTPS Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-22 18:00 +0200
            Re: HTTP shimmed to HTTPS Gene Heskett <gheskett@shentel.net> - 2019-07-22 19:10 +0200
              Re: HTTP shimmed to HTTPS Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-22 19:20 +0200
              Re: HTTP shimmed to HTTPS Cindy Sue Causey <butterflybytes@gmail.com> - 2019-07-22 22:30 +0200
            Re: HTTP shimmed to HTTPS rhkramer@gmail.com - 2019-07-22 21:50 +0200
              Re: HTTP shimmed to HTTPS Gene Heskett <gheskett@shentel.net> - 2019-07-22 23:30 +0200
              Re: HTTP shimmed to HTTPS David Wright <deblis@lionunicorn.co.uk> - 2019-07-23 02:10 +0200
      Re: HTTP shimmed to HTTPS Reco <recoverym4n@enotuniq.net> - 2019-07-22 17:30 +0200
        Re: HTTP shimmed to HTTPS <tomas@tuxteam.de> - 2019-07-22 18:00 +0200
          Re: HTTP shimmed to HTTPS Reco <recoverym4n@enotuniq.net> - 2019-07-22 19:00 +0200
            Re: HTTP shimmed to HTTPS Gene Heskett <gheskett@shentel.net> - 2019-07-22 19:20 +0200
              Re: HTTP shimmed to HTTPS Étienne Mollier <etienne.mollier@mailoo.org> - 2019-07-22 19:40 +0200

#211632 — Re: HTTP shimmed to HTTPS

*	From: Reco recoverym4n@enotuniq.net
*	Date: Sun, 21 Jul 2019 10:47:18 +0300
wget -O - http://<siet>

curl -vL http://<siet> >/dev/null

nmap -sT -p 80 <siet>

Before trying that I set "debug_options ALL,9" in /etc/squid/squid.conf.

Then "su /etc/init.d/squid restart"

This was delivered to /etc/log/syslog.

Jul 22 06:10:41 dalton systemd[1]: Stopping Squid Web Proxy Server...
Jul 22 06:10:41 dalton squid[2966]: Preparing for shutdown after 0 requests
Jul 22 06:10:41 dalton squid[2966]: Waiting 30 seconds for active connections to finish
Jul 22 06:10:41 dalton squid[2966]: Closing HTTP(S) port [::]:3128
Jul 22 06:10:41 dalton squid[2966]: Closing Pinger socket on FD 14
Jul 22 06:11:12 dalton squid[2966]: Shutdown: NTLM authentication.
Jul 22 06:11:12 dalton squid[2966]: Shutdown: Negotiate authentication.
Jul 22 06:11:12 dalton squid[2966]: Shutdown: Digest authentication.
Jul 22 06:11:12 dalton squid[2966]: Shutdown: Basic authentication.
Jul 22 06:11:12 dalton squid[2966]: Shutting down...
Jul 22 06:11:12 dalton squid[2966]: storeDirWriteCleanLogs: Starting...
Jul 22 06:11:12 dalton squid[2966]:   Finished.  Wrote 0 entries.
Jul 22 06:11:12 dalton squid[2966]:   Took 0.00 seconds (  0.00 entries/sec).
Jul 22 06:11:12 dalton squid[2966]: Logfile: closing log daemon:/var/log/squid/access.log
Jul 22 06:11:12 dalton squid[2966]: Logfile Daemon: closing log daemon:/var/log/squid/access.log
Jul 22 06:11:12 dalton squid[2966]: Open FD UNSTARTED    10 IPC UNIX STREAM Parent
Jul 22 06:11:12 dalton squid[2966]: Squid Cache (Version 4.6): Exiting normally.
Jul 22 06:11:13 dalton squid[2964]: Squid Parent: squid-1 process 2966 exited with status 0
Jul 22 06:11:13 dalton squid[2964]: Removing PID file (/var/run/squid.pid)
Jul 22 06:11:13 dalton systemd[1]: squid.service: Succeeded.
Jul 22 06:11:13 dalton systemd[1]: Stopped Squid Web Proxy Server.
Jul 22 06:11:13 dalton systemd[1]: Starting Squid Web Proxy Server...
Jul 22 06:11:13 dalton squid[3044]: 2019/07/22 06:11:13.461| Created PID file (/var/run/squid.pid)
Jul 22 06:11:13 dalton squid[3044]: Squid Parent: will start 1 kids
Jul 22 06:11:13 dalton squid[3044]: Squid Parent: (squid-1) process 3046 started
Jul 22 06:11:13 dalton squid[3044]: 2019/07/22 06:11:13.571 kid1| Set Current Directory to /var/spool/squid
Jul 22 06:11:13 dalton squid[3044]: 2019/07/22 06:11:13.572 kid1| Creating missing swap directories
Jul 22 06:11:13 dalton squid[3044]: 2019/07/22 06:11:13.572 kid1| No cache_dir stores are configured.
Jul 22 06:11:13 dalton squid[3044]: 2019/07/22 06:11:13.595 kid1| 24,8| SBuf.cc(70) ~SBuf: SBuf2 destructed
Jul 22 06:11:13 dalton squid[3044]: 2019/07/22 06:11:13.596 kid1| 24,9| MemBlob.cc(82) ~MemBlob: destructed, this=0x1c34790 id=blob2 capacity=36 size=12
Jul 22 06:11:13 dalton squid[3044]: 2019/07/22 06:11:13.597 kid1| 24,8| SBuf.cc(70) ~SBuf: SBuf1 destructed
Jul 22 06:11:13 dalton squid[3044]: Squid Parent: squid-1 process 3046 exited with status 0
Jul 22 06:11:13 dalton squid[3044]: 2019/07/22 06:11:13.615| Removing PID file (/var/run/squid.pid)
Jul 22 06:11:13 dalton squid[3044]: 2019/07/22 06:11:13.657| 24,8| SBuf.cc(70) ~SBuf: SBuf2 destructed
Jul 22 06:11:13 dalton squid[3044]: 2019/07/22 06:11:13.658| 24,9| MemBlob.cc(82) ~MemBlob: destructed, this=0xdb5790 id=blob2 capacity=36 size=12
Jul 22 06:11:13 dalton squid[3044]: 2019/07/22 06:11:13.659| 24,8| SBuf.cc(70) ~SBuf: SBuf1 destructed
Jul 22 06:11:13 dalton squid[3048]: Created PID file (/var/run/squid.pid)
Jul 22 06:11:13 dalton squid[3048]: Squid Parent: will start 1 kids
Jul 22 06:11:13 dalton squid[3048]: Squid Parent: (squid-1) process 3050 started
Jul 22 06:11:13 dalton squid[3047]: 2019/07/22 06:11:13.838| 24,8| SBuf.cc(70) ~SBuf: SBuf2 destructed
Jul 22 06:11:13 dalton squid[3047]: 2019/07/22 06:11:13.848| 24,9| MemBlob.cc(82) ~MemBlob: destructed, this=0x24fb790 id=blob2 capacity=36 size=12
Jul 22 06:11:13 dalton squid[3047]: 2019/07/22 06:11:13.849| 24,8| SBuf.cc(70) ~SBuf: SBuf1 destructed
Jul 22 06:11:13 dalton systemd[1]: Started Squid Web Proxy Server.
Jul 22 06:11:14 dalton squid[3050]: Set Current Directory to /var/spool/squid
Jul 22 06:11:14 dalton squid[3050]: Starting Squid Cache version 4.6 for i686-pc-linux-gnu...
Jul 22 06:11:14 dalton squid[3050]: Service Name: squid
Jul 22 06:11:14 dalton squid[3050]: Process ID 3050
Jul 22 06:11:14 dalton squid[3050]: Process Roles: worker
Jul 22 06:11:14 dalton squid[3050]: With 1024 file descriptors available
Jul 22 06:11:14 dalton squid[3050]: Initializing IP Cache...
Jul 22 06:11:14 dalton squid[3050]: DNS Socket created at [::], FD 5
Jul 22 06:11:14 dalton squid[3050]: DNS Socket created at 0.0.0.0, FD 9
Jul 22 06:11:14 dalton squid[3050]: Adding domain pathology.ubc.ca from /etc/resolv.conf
Jul 22 06:11:14 dalton squid[3050]: Adding nameserver 127.0.0.1 from /etc/resolv.conf
Jul 22 06:11:14 dalton squid[3050]: Logfile: opening log daemon:/var/log/squid/access.log
Jul 22 06:11:14 dalton squid[3050]: Logfile Daemon: opening log /var/log/squid/access.log
Jul 22 06:11:14 dalton squid[3050]: Local cache digest enabled; rebuild/rewrite every 3600/3600 sec
Jul 22 06:11:14 dalton squid[3050]: Store logging disabled
Jul 22 06:11:14 dalton squid[3050]: Swap maxSize 0 + 262144 KB, estimated 20164 objects
Jul 22 06:11:14 dalton squid[3050]: Target number of buckets: 1008
Jul 22 06:11:14 dalton squid[3050]: Using 8192 Store buckets
Jul 22 06:11:14 dalton squid[3050]: Max Mem  size: 262144 KB
Jul 22 06:11:14 dalton squid[3050]: Max Swap size: 0 KB
Jul 22 06:11:14 dalton squid[3050]: Using Least Load store dir selection
Jul 22 06:11:14 dalton squid[3050]: Set Current Directory to /var/spool/squid
Jul 22 06:11:15 dalton squid[3050]: Finished loading MIME types and icons.
Jul 22 06:11:15 dalton squid[3050]: HTCP Disabled.
Jul 22 06:11:15 dalton squid[3050]: Pinger socket opened on FD 14
Jul 22 06:11:15 dalton squid[3050]: Squid plugin modules loaded: 0
Jul 22 06:11:15 dalton squid[3050]: Adaptation support is off.
Jul 22 06:11:15 dalton squid[3050]: Accepting HTTP Socket connections at local=[::]:3128 remote=[::] FD 12 flags=9
Jul 22 06:11:15 dalton squid[3050]: storeLateRelease: released 0 objects

Anything remarkable?

Does the 2nd to last line mean it's accepting only IPv6 connections?  Not IPv4?

Thanks,                       ... P.

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

[toc] | [next] | [standalone]

#211635

	Hi.

You're breaking threading. Just a friendly note.


> On Mon, Jul 22, 2019 at 06:32:36AM -0700, peter@easthope.ca wrote:
> Anything remarkable?

Nope, but that's expected.
Squid never logged served connections into the syslog.
Also note you either need to configure Squid as a transparent proxy, or
set an appropriate $http_proxy environment variable before the tests.


> Does the 2nd to last line mean it's accepting only IPv6 connections?  Not IPv4?

The best answer to this is "/sbin/sysctl net.ipv6.bindv6only".
1 means "yes", 0 means "no".

"ss -nptl" or "netstat -nplt" should answer it too.

Reco

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

#211638

Anybody know what these no content messagess are about?  Just spam?

On Monday, July 22, 2019 09:32:36 AM peter@easthope.ca wrote:
> *	From: Reco

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

#211639

Hello,

On Mon, Jul 22, 2019 at 11:00:20AM -0400, rhkramer@gmail.com wrote:
> Anybody know what these no content messagess are about?  Just spam?

I haven't seen one without content, but I haven't read them as the
quoting is so broken it's too hard to read. Maybe check with the archives
and see if your mailer is showing differently?

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

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

#211641

On Monday, July 22, 2019 11:11:42 AM Andy Smith wrote:
> Hello,
> 
> On Mon, Jul 22, 2019 at 11:00:20AM -0400, rhkramer@gmail.com wrote:
> > Anybody know what these no content messagess are about?  Just spam?
> 
> I haven't seen one without content, but I haven't read them as the
> quoting is so broken it's too hard to read. Maybe check with the archives
> and see if your mailer is showing differently?

Thanks for the reply -- interesting:

   * the archive definitely shows a lot more

   * but when I view source in my email client (kmail 3.n), I see just the "*       
From: Reco" that I see when viewing the email "normally".

So, it seems, something is filtering out a lot of the content of the email 
before it gets to me (I don't think anything else in my system would be 
filtering anything out -- emails come directly from my ISP to my email client.

A mystery that I won't dig into any deeper for now.

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

#211643

On Mon, Jul 22, 2019 at 11:40:59AM -0400, rhkramer@gmail.com wrote:
>    * but when I view source in my email client (kmail 3.n), I see just the "*       
> From: Reco" that I see when viewing the email "normally".
> 
> So, it seems, something is filtering out a lot of the content of the email 
> before it gets to me (I don't think anything else in my system would be 
> filtering anything out -- emails come directly from my ISP to my email client.
> 
> A mystery that I won't dig into any deeper for now.

Well, there are two possibilities.  One is that the messages are actually
being truncated during transmission.  The other is that your email user
agent is not showing you the full message text.

The obvious way to figure out which one it is would be to read the email
in a different way (cat, less, mutt, mailx, ...).

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

#211647

On Monday 22 July 2019 11:52:59 Greg Wooledge wrote:

> On Mon, Jul 22, 2019 at 11:40:59AM -0400, rhkramer@gmail.com wrote:
> >    * but when I view source in my email client (kmail 3.n), I see
> > just the "* From: Reco" that I see when viewing the email
> > "normally".
> >
> > So, it seems, something is filtering out a lot of the content of the
> > email before it gets to me (I don't think anything else in my system
> > would be filtering anything out -- emails come directly from my ISP
> > to my email client.
> >
> > A mystery that I won't dig into any deeper for now.
>
> Well, there are two possibilities.  One is that the messages are
> actually being truncated during transmission.  The other is that your
> email user agent is not showing you the full message text.
>
> The obvious way to figure out which one it is would be to read the
> email in a different way (cat, less, mutt, mailx, ...).

I'm using kmail from TDE. R14.0.7. It has a view raw message mode.  And 
the msg ends with "From Reco"

But the barracuda spam report just above it says there's a null byte in 
the body.  That might be being taken as "EOF" by kmail.

There are several header lines proclaiming:
From:  peter@easthope.ca
X-Source-IP: 142.103.107.137

I've also never seen this header line before:

X-Mailer: Oberon Mail (ejz) on LinuxA2 Gen. 32-bit, rev.8586

And I've been online one way or another since the middle 80's.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#211649

On Mon, Jul 22, 2019 at 01:04:29PM -0400, Gene Heskett wrote:
> I'm using kmail from TDE. R14.0.7. It has a view raw message mode.  And 
> the msg ends with "From Reco"
> 
> But the barracuda spam report just above it says there's a null byte in 
> the body.  That might be being taken as "EOF" by kmail.

Yeah, that might do it.  I could imagine a mail user agent reacting
to that in exactly the way some people have described.

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

#211655

On 7/22/19, Gene Heskett <gheskett@shentel.net> wrote:
> I've also never seen this header line before:
>
> X-Mailer: Oberon Mail (ejz) on LinuxA2 Gen. 32-bit, rev.8586


I've been following this partially in between some other things. A
super quick search that led to a few more where pieces of that were
DELETED... kept finding very few references online..

I thought you all were talking about a different email. That one's
source says it purely contains one HTML "br" line break line inside a
"div" container. The email's content reference string, whatever else
those might be called, is "different" from the expected variations
that other emails like it contain.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

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

#211652

On Monday, July 22, 2019 11:52:59 AM Greg Wooledge wrote:
> On Mon, Jul 22, 2019 at 11:40:59AM -0400, rhkramer@gmail.com wrote:
> >    * but when I view source in my email client (kmail 3.n), I see just
> >    the "*
> > 
> > From: Reco" that I see when viewing the email "normally".
> > 
> > So, it seems, something is filtering out a lot of the content of the
> > email before it gets to me (I don't think anything else in my system
> > would be filtering anything out -- emails come directly from my ISP to
> > my email client.
> > 
> > A mystery that I won't dig into any deeper for now.
> 
> Well, there are two possibilities.  One is that the messages are actually
> being truncated during transmission.  The other is that your email user
> agent is not showing you the full message text.
> 
> The obvious way to figure out which one it is would be to read the email
> in a different way (cat, less, mutt, mailx, ...).

Ok, that fooled me -- I expected that the kmail command "view source" would 
let me see the entire email regardless of how it might be "rendered" in the 
kmail text box, but I was wrong.

When I view that email in kwrite, I see all of the content, and, then around 
the email address (recoverym4n@enotuniq.net, after the *	From: Reco in the 
body of the email I see two characters that look like triangles -- I'll try 
looking at those in hexedit...

Ok, it looks like there is a 0x00 in the byte before the email address (which 
is presumably disabling all further rendering in this version of kmail 
(1.13.7, on kde 4.8.4), and a 0x09 in the byte after the email address.

So, I guess I have a way to send secret messages (to, at least, myself ;-)

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

#211658

On Monday 22 July 2019 15:48:08 rhkramer@gmail.com wrote:

> On Monday, July 22, 2019 11:52:59 AM Greg Wooledge wrote:
> > On Mon, Jul 22, 2019 at 11:40:59AM -0400, rhkramer@gmail.com wrote:
> > >    * but when I view source in my email client (kmail 3.n), I see
> > > just the "*
> > >
> > > From: Reco" that I see when viewing the email "normally".
> > >
> > > So, it seems, something is filtering out a lot of the content of
> > > the email before it gets to me (I don't think anything else in my
> > > system would be filtering anything out -- emails come directly
> > > from my ISP to my email client.
> > >
> > > A mystery that I won't dig into any deeper for now.
> >
> > Well, there are two possibilities.  One is that the messages are
> > actually being truncated during transmission.  The other is that
> > your email user agent is not showing you the full message text.
> >
> > The obvious way to figure out which one it is would be to read the
> > email in a different way (cat, less, mutt, mailx, ...).
>
> Ok, that fooled me -- I expected that the kmail command "view source"
> would let me see the entire email regardless of how it might be
> "rendered" in the kmail text box, but I was wrong.
>
> When I view that email in kwrite, I see all of the content, and, then
> around the email address (recoverym4n@enotuniq.net, after the *	From:
> Reco in the body of the email I see two characters that look like
> triangles -- I'll try looking at those in hexedit...
>
> Ok, it looks like there is a 0x00 in the byte before the email address
> (which is presumably disabling all further rendering in this version
> of kmail (1.13.7, on kde 4.8.4), and a 0x09 in the byte after the
> email address.
>
> So, I guess I have a way to send secret messages (to, at least, myself
> ;-)

Me too.  That make 3 bugs in V1.9.1 that need some tlc. And one of them 
is a major PITA to fix, it can occasionally scramble the indexes. But, 
its still an old friend.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#211661

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

On Mon 22 Jul 2019 at 15:48:08 (-0400), rhkramer@gmail.com wrote:
> On Monday, July 22, 2019 11:52:59 AM Greg Wooledge wrote:
> > On Mon, Jul 22, 2019 at 11:40:59AM -0400, rhkramer@gmail.com wrote:
> > >    * but when I view source in my email client (kmail 3.n), I see just
> > >    the "*
> > > 
> > > From: Reco" that I see when viewing the email "normally".
> > > 
> > > So, it seems, something is filtering out a lot of the content of the
> > > email before it gets to me (I don't think anything else in my system
> > > would be filtering anything out -- emails come directly from my ISP to
> > > my email client.
> > > 
> > > A mystery that I won't dig into any deeper for now.
> > 
> > Well, there are two possibilities.  One is that the messages are actually
> > being truncated during transmission.  The other is that your email user
> > agent is not showing you the full message text.
> > 
> > The obvious way to figure out which one it is would be to read the email
> > in a different way (cat, less, mutt, mailx, ...).
> 
> Ok, that fooled me -- I expected that the kmail command "view source" would 
> let me see the entire email regardless of how it might be "rendered" in the 
> kmail text box, but I was wrong.
> 
> When I view that email in kwrite, I see all of the content, and, then around 
> the email address (recoverym4n@enotuniq.net, after the *	From: Reco in the 
> body of the email I see two characters that look like triangles -- I'll try 
> looking at those in hexedit...
> 
> Ok, it looks like there is a 0x00 in the byte before the email address (which 
> is presumably disabling all further rendering in this version of kmail 
> (1.13.7, on kde 4.8.4), and a 0x09 in the byte after the email address.
> 
> So, I guess I have a way to send secret messages (to, at least, myself ;-)

Here's what I see in mutt:

  Date: Mon, 22 Jul 2019 06:32:36 -0700
  From: peter@easthope.ca
  Subject: Re: HTTP shimmed to HTTPS
  X-Original-To: deblis@lionunicorn.co.uk
  X-Original-To: lists-debian-user@bendel.debian.org

  *       From: Reco \200recoverym4n@enotuniq.net\200
  *       Date: Sun, 21 Jul 2019 10:47:18 +0300
  wget -O - http://<siet>

  curl -vL http://<siet> >/dev/null

  nmap -sT -p 80 <siet>

Running emacs on the cached message, you can of course get help on
that that \200 actually is. I attach the result because it probably
has raw occurrences of the problematical character within it.

Cheers,
David.

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

#211640

	Hi.

On Mon, Jul 22, 2019 at 11:00:20AM -0400, rhkramer@gmail.com wrote:
> Anybody know what these no content messagess are about?  Just spam?

Mutt does show the contents to me. A text/plain with an unconventional
quoting style.
Threading is borken, though.


And this:

> X-Mailer: Oberon Mail (ejz) on LinuxA2 Gen. 32-bit, rev.8586

Looks rather unusual to me.

Reco

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

#211642

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

On Mon, Jul 22, 2019 at 06:08:32PM +0300, Reco wrote:
> 	Hi.
> 
> On Mon, Jul 22, 2019 at 11:00:20AM -0400, rhkramer@gmail.com wrote:
> > Anybody know what these no content messagess are about?  Just spam?
> 
> Mutt does show the contents to me. A text/plain with an unconventional
> quoting style.
> Threading is borken, though.
> 
> 
> And this:
> 
> > X-Mailer: Oberon Mail (ejz) on LinuxA2 Gen. 32-bit, rev.8586

Wow. This [1] one? The elder among us stand in awe. Oberon still
alive...

> Looks rather unusual to me.

Yes, but of historical significance. Kinda like someone running
her web server on a PDP-11 (no, no irony meant!).

Cheers

[1] http://ssw.jku.at/Teaching/Projects/OberonMail/

-- t

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

#211646

On Mon, Jul 22, 2019 at 05:50:30PM +0200, tomas@tuxteam.de wrote:
> > And this:
> > 
> > > X-Mailer: Oberon Mail (ejz) on LinuxA2 Gen. 32-bit, rev.8586
> 
> Wow. This [1] one? The elder among us stand in awe. Oberon still
> alive...
> 
> > Looks rather unusual to me.
> 
> Yes, but of historical significance. Kinda like someone running
> her web server on a PDP-11 (no, no irony meant!).

I'm a youngster compared to other people in this maillist. My first MUA
was pine (not *al*pine) at late '90s. This one clearly predates it.

Reco

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

#211650

On Monday 22 July 2019 12:43:43 Reco wrote:

> On Mon, Jul 22, 2019 at 05:50:30PM +0200, tomas@tuxteam.de wrote:
> > > And this:
> > > > X-Mailer: Oberon Mail (ejz) on LinuxA2 Gen. 32-bit, rev.8586
> >
> > Wow. This [1] one? The elder among us stand in awe. Oberon still
> > alive...
> >
> > > Looks rather unusual to me.
> >
> > Yes, but of historical significance. Kinda like someone running
> > her web server on a PDP-11 (no, no irony meant!).

I don't think so, the only pdp-11, I ever tangled with crashed a dozen 
times a day so I refuse to even capitalize the model name. The factory 
field techs changed everything in it but the frame rail with the serial 
number, never fixed it.  After a couple years of that, I managed to 
convince CBS to trade me their test mule, which worked fine. But that 
left CBS w/o a test mule, so they couldn't even test software changes. 
So they wound up buying all the affiliates new IBM's with an ARTIC card. 
And that worked well as long as I didn't give it a phone line.  But 
thats a different story...

> I'm a youngster compared to other people in this maillist. My first
> MUA was pine (not *al*pine) at late '90s. This one clearly predates
> it.
>
> Reco


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#211651

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

Gene, on 2019-07-22 :
> I don't think so, the only pdp-11, I ever tangled with crashed a dozen
> times a day so I refuse to even capitalize the model name.

Hi Gene,

That is a bit off-topic, but in my (somewhat small) world,
lowercase are glorifying in themselves, see dmr, or rms.

Uppercase is so FORTRAN IV...  :)

Kind Regards,
-- 
Étienne Mollier <etienne.mollier@mailoo.org>
               5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d

[toc] | [prev] | [standalone]

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

csiph-web