Jump to content

sTunnel for modern email protocols in old email clients


Recommended Posts

I found the SDK and have developed some test plugins. I'm just now seeing the last 27 hours of posts, so my tests are a bit dated. Here is the readme from the package I'm preparing:

For the context of these mods, please read:
 https://msfn.org/board/topic/178007-stunnel-for-modern-email-protocols-in-old-email-clients/

These DLLs have NOT been tested! I have limited experience with C++ and MFC, but I'm hoping for the best. :^)

Contents:
 Plugins - subset of emsv4a4.zip (including original SortTran.cpp and sort32.dll)

 Sort mod 1 - SortTran.cpp and sort32.dll
  qsort commented out so no more sorting!
  "text", "plain" -> "text", "html" (twice)
  filter buffer replacing all "// with "x/
  EMSF_ON_REQUEST -> EMSF_ON_ARRIVAL | EMSF_ON_DISPLAY (as in PseudoSq:SqshTran.cpp)

 Sort mod 2 - SortTran.cpp and sort32.dll
  removed most code related to sorting

 Sort mod 3 - SortTran.cpp and sort32.dll
  prefix buffer with "<base href=http:>" instead of filtering

 Sort mod 1a, 2a, 3a - SortTran.cpp and sort32.dll
  <! outFileData->info = make_mime_type("text", "html", "1.0");
  !> outFileData->info = inFileData->info;


emsv4a4.zip is:
 Eudora Extended Messaging Services Software Developer's Kit
 Windows Version 4 / February 12, 1998

Find emsv4a4.zip at:
 https://ftp.sunet.se/mirror/archive/ftp.sunet.se/pub/pc/mail/eudora/developers/emsapi/


-jumper

February 11, 2019


And here is the package (finally!):
http://www.geocities.ws/jumper/EudoraPlugins.7z - 39KB

Edited by jumper
Zzz....
Link to comment
Share on other sites


19 hours ago, dencorso said:

You rock, thanks! :thumbup  I transposed it directly from the Portuguese "incontroversível", instead of looking it up at a dictionary, so I deserved the fail...  :blushing:

JFYI, one of the reasons why Italians do it incontrovertibly better :w00t: is that it is already "incontrovertibile/incontrovertibilmente" in Italian ;).

In this case we are nearer to Latin:

https://it.wiktionary.org/wiki/incontrovertibile

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

On 2/11/2019 at 1:10 PM, heinoganda said:

Because you did not forward the original e-mail, but added the comment "Sent from my smartphone", the HTML code was taken from the smartphone where the
Web Open Font Format was processed. Of course Eudora has no problems with this e-mail. 

:)

@heinoganda

Did the second attempt at forwarding the e-mail work?
:dubbio:

Link to comment
Share on other sites

@Dave-H

The e-mails have arrived, we are waiting for @jumper  if he can create a plugin where from the e-mails of Sky corresponding style code can remove, then it should first be over with these loading delays at Eudora. 

Then I will first devote myself to the updates, some are more like last month.

:)

Edited by heinoganda
Link to comment
Share on other sites

52 minutes ago, heinoganda said:

@Dave-H

The e-mails have arrived, we are waiting for @jumper  if he can create a plugin where from the e-mails of Sky corresponding style code can remove, then it should first be over with these loading delays at Eudora. 

Then I will first devote myself to the updates, some are more like last month.

:)

Ah, so the e-mail I forwarded came through the second time without being corrupted by the addition of my signature?
That's good to know!
As a matter of interest @heinoganda, did you get a page with just the header in IE8, or indeed in any other browser, when you opened the source file I posted?
It didn't display in Firefox 52 ESR for me either, which really puzzled me!
:dubbio:

Link to comment
Share on other sites

1 hour ago, Dave-H said:

Ah, so the e-mail I forwarded came through the second time without being corrupted by the addition of my signature?
That's good to know!

There were no problems with these e-mails.

1 hour ago, Dave-H said:

As a matter of interest @heinoganda, did you get a page with just the header in IE8, or indeed in any other browser, when you opened the source file I posted?

This code was broken, this does not matter anymore, if there is a suitable Eudora plugin.

Preferably a plugin where this modern style code from the source code of the e-mail removed,
since this is not processed as so, as would be possible as from IE9.

:)

Edited by heinoganda
Link to comment
Share on other sites

On 2/11/2019 at 11:41 PM, Mathwiz said:

But if you instead change


@import "//helpforum.sky.com/html/assets/toolkit.css"
url("//www.sky.com/assets/fonts/sky-regular.woff")
url("//www.sky.com/assets/fonts/sky-medium.woff")

to


@import "https://helpforum.sky.com/html/assets/toolkit.css"
url("https://www.sky.com/assets/fonts/sky-regular.woff")
url("https://www.sky.com/assets/fonts/sky-medium.woff")

merely adding "https:" in front of each double-slash, IE8 will now open the file without the progress bar stalling, even though you loaded unsupported .woff files!

Seems obvious that the delay is caused by protocol-relative URLs, not by unsupported font files.

In my case, CSS does not open in IE8, but in Notepad. And WOFF doesn't download at all, crashing with the "Internet Explorer cannot display the webpage" error. Perhaps something like this happens in Eudora, but with the proper handling of erroneous events.

Edited by -SnooPY-
Link to comment
Share on other sites

I hope @jumper can come up with something!

On 2/13/2019 at 11:35 AM, -SnooPY- said:

In my case, CSS does not open in IE8, but in Notepad.

That's probably best. A .css file by itself would probably be just a blank screen in IE8.

But if you open any of the HTML email files @Dave-H has posted, you can open them in IE8. If it's not your default browser (which it probably isn't these days), right-click the file and select "Open With..." and Internet Explorer should be listed as an option.

When IE8 opens a .htm[l] file, there are often links in the file which cause it to download more stuff from the Internet, such as .css files linked in the .htm[l] file. I use ProxHTTPSProxyMII in "debug" mode to monitor what it's doing. Here are the config.ini settings I use:

[GENERAL]
...
LogLevel = DEBUG

### Bypass Proxomitron and the Rear Server, Proxy setting still effective
### This section supports URL matching
[BYPASS URL]
http://*
...

An http: request will then look something like this:

[08:25] 032 [BP] "GET http://update.microsoft.com/microsoftupdate" 301 167

(The [BP] stands for "Bypass Proxy")

... while an https: request will look something like this:

[10:53] 006 [P] "GET https://otm.xpo.com/images/mail/xpo_logo.gif" 200 2256

(The [P] stands for Proxy, of course)

The two numbers at the end are the server's response code and the length of the data returned.

If IE8 pauses, but you don't see either of the above, it must be attempting a protocol other than http(s), such as file:. Unfortunately I know of no way to proxy these requests; otherwise it'd be a simple matter of failing them immediately instead of having to wait for them to time out.

Edited by Mathwiz
Link to comment
Share on other sites

18 hours ago, Mathwiz said:

A .css file by itself would probably be just a blank screen in IE8.

I always thought that the CSS file would be displayed as a text file in any browser, including IE8. And WOFF files would simply be downloaded like any other binary files. In this case, neither is happening. Given that Eudora uses the IE8 engine, I believe that this is the reason for all the delays. It takes time to correctly handle errors.

Link to comment
Share on other sites

In FF or any of its forks, that's exactly what happens: if you enter the URL of a .css file, it gets displayed as text (and if you enter the URL of a .woff file, it gets saved to disk). But for some reason IE8 always seems to interpret .css files as styles, even if you just type the URL in yourself.

That's not a problem for Eudora though; when displaying an email, any .css files it downloads are supposed to be interpreted as styles, otherwise the email wouldn't display properly!

As for .woff files, IE8 does not support them (and doesn't even form the URL to download them correctly, due to a bug). If it can't download a supported .eot font file, it uses the fall-back font specified in the .css (happens to be Arial in sky.com's case).

Since .woff files are unsupported, it would be reasonable to strip any @font-face rules specifying .woff files (or any font file other than .eot format, for that matter) from the HTML, so IE8 doesn't waste time trying to download them.

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, it then opens without any long delays, even though (as can be seen from the ProxHTTPSProxyMII window) IE8 is still trying (and failing) to download those unsupported .woff files.

Link to comment
Share on other sites

6 hours ago, Mathwiz said:

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, it then opens without any long delays, even though (as can be seen from the ProxHTTPSProxyMII window) IE8 is still trying (and failing) to download those unsupported .woff files.

I apologize that I also repeat, but I meant that even with the prefix "https:" these direct links do not open in the address bar of the browser. Obviously, when these links are at the end of the .htm file, there are no delays, because the letter is already fully downloaded at this point. But how to change the behavior of the browser is a much more interesting question for me.

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...