Jump to content

sTunnel for modern email protocols in old email clients


Recommended Posts

> But (I know I'm repeating myself) if one simply inserts "https:" in front of the //'s at the start of those three URLs at the end of the .htm file...

or

> prefix buffer with "<base href=http:>" instead of filtering

and

> in fact, while at it, it could even, you know, block ads....

There are a number of easy solutions if we can just get a plugin to work. There isn't a code sample for simple filtering; there are inconsistencies across code samples; documentation is (too) detailed while lacking context.

Edited by jumper
Link to comment
Share on other sites


I tried using @jumper's experimental Eudora plugin package, but I'm not sure if I'm doing the right thing with it.
I already have quite a few Eudora plugins installed, including sort32.dll, which is the same as the default file in the package Plugins folder.
I've tried substituting it with all six of jumper's alternative sort32.dll files, but none of them make any difference to the slow display of the Sky e-mails.
BTW I have no .cpp files anywhere in Eudora, should I have?
I'm not sure why a customised sort plugin would have the desired effect anyway, isn't sort32.dll just a plugin to do an A>Z sort on the text in messages, invoked by an option on the right click menu on a displayed message body?
I wouldn't expect sort32.dll to change the way that they were displayed in the first place.
Cheers, Dave.
:)

Link to comment
Share on other sites

Thanks for testing the files. The .cpp files are the C++ source files I modified before building each .dll. I included them for anyone to compare the changes I made against the original. Only the .dll files need to be installed in the Plugins folder.

I found Eudora Light 3.0.5 on a backup CD from 2001, copied it to my HDD, removed the read-only attribute from all files, and fired it up. In two blink of an eye, it connected to my old NetZero account for the first time in over 17 years and displayed just one new service email--dated this morning!

The Plugins folder contains two of the samples: Sort, UpprLowr (plus several others). I will switch to modifying the UpprLowr (EMS_VERSION 3) and test as I go.

Link to comment
Share on other sites

Thanks @jumper!
If you'd like to test with my version of Eudora, you can find it here.
It's the whole program folder, less the actual mailbox files, and with my e-mail account information removed from the eudora.ini file.
If the folder is copied to C:\Program Files it should work, as the program is pretty self-contained and doesn't need any registry entries.
Cheers, Dave.
:)
 

Edited by Dave-H
Amendment
Link to comment
Share on other sites

On 2/16/2019 at 5:28 AM, jumper said:

> prefix buffer with "<base href=http:>" instead of filtering

I like this idea; it seems to fix the delay with minimal fuss. But keep in mind the <base ...> tag must appear between the <head> ... </head> tags, so you can't just prefix it; you need to insert it in the proper place. And some emails may already have a <base ...> tag; you need to insert it only if it doesn't exist.

Could scan up to </head> and insert a <base ...> tag in front if none were found

Edited by Mathwiz
Link to comment
Share on other sites

I've just had a thought.
There is a plugin for Eudora which I already use that I think might do the job here, with a bit of modification.
It's called "Bugscreen".
Have a look at its help file and see what you think.
It's designed to strip unwanted rubbish out of incoming e-mails, and crucially, it does it as soon as they're downloaded, but before they're displayed, which is I think is exactly what we need.
:)
 

bugscreen.chm

Link to comment
Share on other sites

@jumper

A plugin where the following style code would be removed where ".woff" is detected would be very helpful.

<style type="text/css">@import "//helpforum.sky.com/html/assets/toolkit.css";@font-face{font-family: "Sky Text"; src: url("//www.sky.com/assets/fonts/sky-regular.woff") format("woff")}@font-face{font-family: "Sky Text"; src: url("//www.sky.com/assets/fonts/sky-medium.woff") format("woff"); font-weight: bold}html, body, #MessageContainer{font-family: 'Sky Text', Arial;margin: 0;padding: 0;box-sizing: border-box;filter: progid: DXImageTransform.Microsoft.gradient(startColorstr="#c9c7d1", endColorstLOGNULL NowTransReader::ReadIt() JJFileMT::Truncate(122991)
r="#fefefe", GradientType=1);background-image: -webkit-linear-gradient(left, #c9c7d1 0%, #e5e5ea 6%, #fefefe 20%, #fefefe 80%, #e5e5ea 94%, #c9c7d1 100%);background-image: -moz-linear-gradient(left, #c9c7d1 0%, #e5e5ea 6%, #fefefe 20%, #fefefe 80%, #e5e5ea 94%, #c9c7d1 100%);background-image: -o-linear-gradient(left, #c9c7d1 0%, #e5e5ea 6%, #fefefe 20%, #fefefe 80%, #e5e5ea 94%, #c9c7d1 100%);background-image: linear-gradient(to right, #c9c7d1 0%, #e5e5ea 6%, #fefefe 20%, #fefefe 80%, #e5e5ea 94%, #c9c7d1 100%);}.header-row{padding: 10px; -webkit-box-shadow: 0 1px 10px 0 rgba(0, 0, 0, 0.2); -moz-box-shadow: 0 1px 10px 0 rgba(0, 0, 0, 0.2);box-shadow: 0 1px 10px 0 rgba(0, 0, 0, .2);background-color: #fff;}<!--if[mso]>.footer-links table{float: left; width: auto !important;}<![end if]-->.footer-links table{float: left; width: auto !important;}.footer-links a:link, .footer-links a:visited, .footer-links a:active, .footer-links a:hover{font-size: 18px;}</style>

 

:)

Link to comment
Share on other sites

Replacing ".woff" with ".woxx" will prevent the font file download.
Replacing '"//' with '"x/' will prevent the delay but also the style sheet from downloading.

In my experience, a "<base href=...>" tag works anywhere until EOF or overridden. Prefixing should work just fine unless maybe there is a MIME multipart embedded image. Something to test.

I stumbled upon a description of Bugscreen two days ago and it did look very promising, but there was no download link. I choose sleep over search. Unfortunately, the file bugscreen_killist.txt seems to be the only configurable option of interest. Can you post that file?

Link to comment
Share on other sites

7 hours ago, jumper said:

Replacing ".woff" with ".woxx" will prevent the font file download.
Replacing '"//' with '"x/' will prevent the delay but also the style sheet from downloading.

In the HTML source code of the e-mail the style code itself is not processed and leads to delay, therefore my question, it is possible in the line (style) ".woff" to recognize and remove this line.

:)

Link to comment
Share on other sites

> In the HTML source code of the e-mail the style code itself is not processed and leads to delay
I think this is not cause-effect, but rather two effects of the "//" cause. The "x/" substitution fixes that.

> is possible in the line (style) ".woff" to recognize and remove this line[?]
Yes, but it might not be desirable to lose all other formatting in that style tag.

I think the "x/" substitution alone will solve the server-delay problem but at the cost of lost external formatting and/or content. In the Sky case, it also avoids the woff font format issue as an added bonus.
The base-prefix method or inserting "http:" before each "//" are better solutions. If the woff font format really is a problem for IE8, we can fix that next (Bugscreen may already consider it "crud").

Link to comment
Share on other sites

23 minutes ago, jumper said:

> In the HTML source code of the e-mail the style code itself is not processed and leads to delay
I think this is not cause-effect, but rather two effects of the "//" cause. The "x/" substitution fixes that.

At this point I have adapted the code, that does not change the problem with the delayed display of the e-mail.

24 minutes ago, jumper said:

> is possible in the line (style) ".woff" to recognize and remove this line[?]
Yes, but it might not be desirable to lose all other formatting in that style tag.

A test with Thunderbird shows the correct style of the e-mail, this style is generally not displayed with Eudora and the display on IE basis also fails in addition to the delayed display. If the style code associated with ".woff" is eliminated in the HTML code, this does not change how the e-mail is displayed in Eudora or IE.

:)

Link to comment
Share on other sites

Thanks guys.
I should say at this point that I'm not too worried about how the messages actually end up looking, as long as the delay goes away. If they end up looking as they do without using the "Microsoft Viewer" option in Eudora I'll be quite happy with that! I'm not expecting them to look like they should do with the viewer working properly, as long as they're readable.
When I get home tomorrow I'll post up a couple of screen grabs showing how they look with the MS Viewer on (after the long display delay) and when using Eudora's own viewer (when they display immediately). They then lose their proper formatting, but are still perfectly readable, at least in the case of the Sky ones. The Marks and Spencer ones look more of a mess, but I'm not so worried about them as I get relatively few of them.
I'll zip up the Bugscreen plugin files too in case anyone still needs them.
:)

Link to comment
Share on other sites

19 hours ago, jumper said:

In my experience, a "<base href=...>" tag works anywhere until EOF or overridden. Prefixing should work just fine unless maybe there is a MIME multipart embedded image. Something to test.

Just tested, and it works; apparently mshtml.dll is a bit more "forgiving" than the IETF standards supposedly allow.

19 hours ago, jumper said:

Replacing ".woff" with ".woxx" will prevent the font file download.

Yes, but that's not really necessary. Due to an IE8 bug, the .woff font files aren't downloaded anyway. Take a look at this ProxHTTPSProxyMII log:

[13:23] 021 [BP] "GET http://helpforum.sky.com/html/assets/toolkit.css" 304 -
[13:23] 022 [BP] "GET http://helpforum.sky.com/html/assets/toolkit.css" 304 -
[13:23] 027 [BP] "GET http://www.sky.com/assets/fonts/sky-medium.woff%22)%20format(%22woff" 301 0
[13:23] 028 [BP] "GET http://www.sky.com/assets/fonts/sky-regular.woff%22)%20format(%22woff" 301 0
[13:23] 026 [BP] "GET http://assets.sky.com/fonts/sky_medium.woff%22)%20format(%22woff%22),%20url(%22//assets.sky.com/fonts/sky_medium.ttf%22)%20format(%22truetype%22),%20url(%22//assets.sky.com/fonts/sky_medium.svg" 404 18
[13:23] 025 [BP] "GET http://assets.sky.com/fonts/sky_regular.woff%22)%20format(%22woff%22),%20url(%22//assets.sky.com/fonts/sky_regular.ttf%22)%20format(%22truetype%22),%20url(%22//assets.sky.com/fontssky_regular.svg" 404 18
[13:23] Using Proxy - http://127.0.0.1:8080
[13:23] 024 [P] "GET https://helpforum.sky.com/i/smilies/16x16_smiley-happy.gif" 200 414
[13:23] Using Proxy - http://127.0.0.1:8080
[13:23] 029 [P] "GET https://www.sky.com/assets/fonts/sky-regular.woff%22)%20format(%22woff" 404 24353
[13:23] Using Proxy - http://127.0.0.1:8080
[13:23] 030 [P] "GET https://www.sky.com/assets/fonts/sky-medium.woff%22)%20format(%22woff" 404 24353

This is with <base href=http:> prepended to Dave-H's "OriginalSource.htm" file, so the protocol-relative URLs use the http: protocol.

The first two lines show the toolkit.css being downloaded, twice. (The first download comes from the <link ...> tag in the header of the .htm file; the second comes from the @import rule near the bottom. Toolkit.css only needs to be downloaded once; the @import rule is redundant and unneeded in this particular email.)

The next two lines show IE8 trying to download the .woff font files as result of the @font-face rules. Notice the extra garbage following the characters ".woff": %22)%20format(%22woff. This garbage is already preventing the files from downloading. The http: requests are first redirected to https: requests (server returns 301), then retried (see the text at the bottom), at which point the server returns a 404 error for each.

Finally, IE8 tries to download both .woff files from a different server (assets.sky.com) specified within toolkit.css itself, and again gets 404 errors due to (a lot of) extra garbage that was added to each file name.

19 hours ago, jumper said:

Replacing '"//' with '"x/' will prevent the delay but also the style sheet from downloading.

In the case of this particular email, this would work because the style sheet was already downloaded by the <link ...> tag. But that may not be true of other emails, so that probably isn't the best option.

All things considered, it appears prepending <base href=http:> is the safest option. It prevents the delay without breaking anything that wasn't already broken ;)

 

Edited by Mathwiz
Link to comment
Share on other sites

The "something to test" that still hasn't been tested is an image embedded as multipart MIME. It is probably referenced locally and prefixing a base href--even just a protocol--might break the reference. If so, then each "//" will need to be individually prefixed with "http:".

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...