|
Apparently the venn diagram of Yahoo mail users and webOS users does not have significant overlap. I probably wouldn't have found any cycles for this, except for the fact that Yahoo won't be alone much longer in cutting off support for TLS 1.0 and 1.1 -- Microsoft has been warning they would do this for more than a year. They delayed their plans to give organizations more time during the pandemic, but it will likely drop the hammer by April. So we're going to need a solution...
The problem is not unlike the encryption change in HTTPS that started leaving us without certain websites. Although HTTPS was supported in webOS, the specify encryption algorithm within the HTTPS channel has been improved and webOS doesn't support the newer algorithm. The exact same situation is true for encrypted email. Like with HTTPS, we need a way to route or proxy the encryption webOS supports through some channel that can speak the encryption that the newer server supports. Unfortunately, the webOS proxy capabilities do not seem to support routing email traffic, so the solutions we have for web do not apply.
There are three approaches I've found, that might be workable, but at varying levels of abstraction...
- At the highest level, mail forwarding can do the trick. Find a host that does not use newer encryption, and setup Yahoo (or Exchange, or Office365) to forward mail to that host. A copy of your inbound mail is forwarded to that server. Outbound mail will not come from your preferred host -- but you can set the "Reply To" field to specific your Yahoo account. If your ISP still provides email (both Spectrum and Comcast do) it likely has crappy security, and can be pressed into service for this. This is pretty low-tech -- no programming required and its easy to do. Unfortunately, Yahoo made this a paid feature effective January 2021.
- Moving to lower-level is going to require an intermediate server and some configuration. The next step down appears to be an e-mail relay, that can run on Windows/Mac/Linux. I haven't tried this yet, but it functions similar to forwarding, except that it doesn't depend on Yahoo to forward -- the relay should be able to log-in to your Yahoo account, grab your mail, then present it to you as if it were the POP3 host that originally got the mail. It can do the same in reverse with SMTP. Check out E-mailRelay here: E-MailRelay
- The lowest level is something more like a real mail proxy or tunnel. This might be able to re-shape traffic enroute, interceding on behalf of webOS in a transparent fashion -- like Squid does for web traffic, but without the cooperation of webOS. This would be most challenging to implement, but would be the most seamless solution. A couple options I found for further investigation are ghostunnel and NGINX.
Unfortunately, it doesn't look like any of these solutions could be deployed in a multi-user-multi-mail-provider fashion -- meaning I couldn't offer them "as a service" like the Squid proxy, or even the MeTube service (which is effectively a service-specific proxy.) So everyone would need to run this for themselves. A Raspberry Pi makes a great "helper" device for retro gear, and could probably run most of these solutions at a very low cost (a Pi can be had for less than $50.)
The other unfortunate probability is that services will eventually move away from offering POP/IMAP mail access in favor of more secure protocols and OAuth2-style authentication. OAuth is tricky to implement even using modern tech, requiring a lot of back-and-forth with different servers. While I can probably figure out how to get one of the above solutions working, and documented for others to implement, once we're in an OAuth-only world, it will be beyond my capabilities -- there's a reason I pay people to do development in the real-world: my time and skillz are limited!
|
|
|