Hello all,

About two weeks ago I was asking good, simple email program for XP, as my
ISP is switching to SSL only access. After having gone to a few I decided
that Sylpheed v3.7 looks best.


However, yesterday I realized that there is a possible another solution : a standard-connection-to-SSL conversion program (also called a tunnel?)

A bit of googeling resulted in "stunnel". Its a bit heavy though. Are
there better/simpeler programs that do just SSL wrapping (for a pop3 and
smtp connection)?

By the way : I have little wish to have such a SSL-tunnel program running
all the time, so something that can easily be started and terminated would
be preferred.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/05/2023 18:49, R.Wieser wrote:

Hello all,

About two weeks ago I was asking good, simple email program for XP, as my
ISP is switching to SSL only access. After having gone to a few I decided that Sylpheed v3.7 looks best.

However, yesterday I realized that there is a possible another solution : a standard-connection-to-SSL conversion program (also called a tunnel?)

A bit of googeling resulted in "stunnel". Its a bit heavy though. Are there better/simpeler programs that do just SSL wrapping (for a pop3 and
smtp connection)?

By the way : I have little wish to have such a SSL-tunnel program running
all the time, so something that can easily be started and terminated would
be preferred.

Regards,
Rudy Wieser

So you want a simple email program but you also want to go through all
the hassle of another SSL conversion program!

Have you always been so stupid all your life? Email is supposed to be
the easiest thing in this world but you have struggled for the past 2 weeks!

Can you just fuck off and continue taking drugs or whatever you are
consuming.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec porta non
felis non pellentesque. Mauris sed rutrum nibh. Cras sed elit quis
tellus aliquam suscipit ultrices non tortor. Phasellus hendrerit ornare facilisis. Fusce quis libero in nulla lacinia dignissim. Curabitur
hendrerit metus id pellentesque tincidunt. Praesent ullamcorper mi in
sem blandit, sed vulputate arcu condimentum.

Vivamus commodo facilisis accumsan. Etiam vel malesuada libero. Nam a
suscipit felis. Morbi fermentum nunc justo, quis cursus urna aliquam
elementum. Quisque interdum eleifend venenatis. Maecenas vitae justo eu
tellus hendrerit maximus vitae ut felis. Vivamus commodo felis mi, vel sollicitudin libero maximus at. Nam arcu felis, vestibulum imperdiet consectetur at, laoreet ac enim. Nulla sit amet ullamcorper est. Duis sollicitudin arcu ac nisl finibus interdum. Sed eget tristique turpis,
eu viverra lectus. Praesent accumsan aliquet neque eget sollicitudin.
Duis id viverra magna. Vivamus non dignissim risus. Cras quam nisl,
consequat gravida semper sit amet, bibendum sit amet metus. Aenean
feugiat, dolor vel tristique maximus, massa eros eleifend erat, sed
rhoncus enim diam eu ex.

Phasellus sodales felis enim, eu eleifend libero laoreet nec. Praesent
sodales nec ligula non commodo. Vestibulum et placerat lorem. Aliquam condimentum odio nec nulla ultrices, mattis vehicula lectus tempor.
Maecenas quis hendrerit erat. Pellentesque at pretium sapien. Donec id
sodales dolor. Fusce vulputate enim vitae tempor efficitur. Sed eget
dignissim risus, ac blandit ipsum. Donec ultrices odio a ultricies
sodales. Aenean placerat hendrerit placerat. Nunc iaculis dictum purus,
sit amet condimentum erat commodo sit amet. Morbi dapibus dolor quis
mauris lacinia dapibus. Fusce sem dui, ultricies eget luctus id, rutrum ultrices metus.

Sed odio mi, tempor eu mi vitae, convallis viverra nibh. Duis feugiat
orci erat, at pellentesque neque maximus et. Fusce aliquet rhoncus sem
ut elementum. In volutpat condimentum magna sed cursus. Donec elit
justo, tempus quis lobortis vel, cursus id nibh. Donec dignissim turpis
in magna tristique, gravida aliquam purus interdum. Maecenas tristique
diam tortor. Pellentesque et risus et ligula vestibulum facilisis ut non
metus.

Duis a dignissim diam, pulvinar cursus sapien. Quisque aliquam, dui in
cursus sollicitudin, ipsum odio iaculis nibh, et pharetra purus nunc ut
felis. Quisque vitae augue non orci molestie porttitor. Cras nec ante id
erat ullamcorper auctor. Proin vel egestas velit. Etiam condimentum ante
vitae maximus suscipit. Aliquam porta tempor aliquam. Duis cursus purus
ex, eget convallis justo commodo ut. Aliquam erat volutpat. Pellentesque gravida augue sit amet erat varius imperdiet. Donec id magna ut ante
ornare fermentum.

Sed fringilla viverra nisl vel efficitur. In pulvinar justo enim, eu
consequat lectus aliquet a. Aenean viverra eros nec tortor vulputate, a
dapibus enim facilisis. Ut lacinia fringilla velit. Donec molestie, sem
at consequat placerat, ligula orci condimentum lorem, quis feugiat
sapien sem consectetur ligula. Ut vestibulum est eget dui placerat
mollis. Morbi auctor laoreet magna ac condimentum. Quisque ipsum quam,
porta facilisis nibh ac, commodo ultrices lectus. Praesent maximus mi
quis libero luctus, maximus gravida nunc ultricies.

Nam in mi urna. Sed dignissim, dolor vitae pharetra pulvinar, ipsum quam condimentum neque, sed consequat urna orci vitae orci. Donec congue
malesuada sapien, at varius urna ultricies quis. Quisque bibendum neque
ac magna vestibulum pulvinar. Proin vitae tempus nulla. Morbi eu felis
vitae lacus dignissim fermentum a sed nisl. Praesent congue nunc ut urna molestie, ac euismod libero blandit.

Suspendisse quis tincidunt leo. Maecenas interdum tellus id urna
fermentum pretium. Nunc pretium felis in tellus pellentesque, et
pellentesque mi pharetra. Sed at mattis risus. Nullam interdum metus
turpis, non pharetra nulla ultricies eu. Cras elit sapien, pellentesque
at imperdiet quis, dignissim a quam. Suspendisse rhoncus nunc vitae
tellus lobortis, vitae pharetra dui pulvinar. Aenean ultrices ac quam
vitae auctor. Ut a turpis diam. Morbi bibendum tincidunt ipsum, quis
faucibus nibh facilisis ut. Curabitur pellentesque eleifend elit sit
amet tempor.

Maecenas ornare porta mi ultrices tempus. Cras et lorem quis dolor
efficitur pulvinar at vestibulum arcu. Nam et erat sed tellus pretium
iaculis. Sed varius gravida orci, vel varius tellus dictum eu. Aenean
tincidunt erat sed magna rhoncus rutrum. Cras viverra ut nulla nec
bibendum. Phasellus risus lacus, porta at sem ut, dictum vulputate
lectus. In felis risus, semper accumsan purus ut, efficitur dignissim
velit. Integer sed diam et justo malesuada congue. Cras ac laoreet ante. Pellentesque a ornare nisi. Proin imperdiet vestibulum dui at sodales.

In hac habitasse platea dictumst. Ut vitae metus nibh. Sed hendrerit
aliquam neque vitae placerat. Nunc sed mauris eget risus dapibus
scelerisque id ut tortor. In eu lectus ornare, convallis dui vitae,
suscipit lacus. Donec gravida nibh non quam feugiat, sed accumsan nunc suscipit. Morbi semper eget purus eu venenatis. Sed nulla nulla, euismod
vel diam at, tincidunt elementum mi. Proin sed malesuada diam. Integer
maximus, purus eu aliquam condimentum, ipsum sapien feugiat est, at
eleifend purus nibh sed enim. Vestibulum non dictum mi. Vivamus vitae
interdum mi, sed bibendum quam. Etiam sodales lobortis maximus. Integer
ornare consectetur neque, in sagittis mauris accumsan ut. In tellus leo, suscipit pharetra molestie tincidunt, pulvinar quis tortor. Sed non
pharetra ligula, vel fermentum augue.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Jack <[email protected]> wrote:

Have you always been so stupid all your life? Email is supposed to be
the easiest thing in this world but you have struggled for the past 2 weeks!

Can you just fuck off and continue taking drugs or whatever you are consuming.

Obvious what Jack does with his right hand all day long.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"R.Wieser" <[email protected]d> wrote:

About two weeks ago I was asking good, simple email program for XP, as
my ISP is switching to SSL only access. After having gone to a few I
decided that Sylpheed v3.7 looks best.

However, yesterday I realized that there is a possible another
solution : a standard-connection-to-SSL conversion program (also
called a tunnel?)

A bit of googeling resulted in "stunnel". Its a bit heavy though.
Are there better/simpeler programs that do just SSL wrapping (for a
pop3 and smtp connection)?

By the way : I have little wish to have such a SSL-tunnel program
running all the time, so something that can easily be started and
terminated would be preferred.

2 weeks ago I mentioned sTunnel in my first reply to you. It adds
SSL/TLS encryption. It does not add support for OAUTH2. The e-mail
client has to negotiate with the OAUTH2 server to get and store a token
it uses thereafter, along with a renew token since OAUTH2 tokens expire,
and the e-mail client is suppose to renegotiate for a new OAUTH2 token
before it expires using the renew token. sTunnel is just an encrypting product. No OAUTH2 support. If you're using Gmail, Google requires you
use a OAUTH2 capable e-mail client. They used to have an option in the
account settings to allow "less secure" clients, but they took away that option, so now you must use an OAUTH2 capable client to connect to
Gmail. There are other e-mail providers that use OAUTH2, so sTunnel may
not be your solution. Only if you need to add SSL/TLS encryption will
sTunnel solve your problem of using an antiquated e-mail client that
does not have SSL/TLS encryption support (which often is only to protect
the login credentials, not the content of your e-mails).

The only of sTunnel that I remember was a bit difficult was writing up
the mapping in the config file. You told on which ports sTunnel would
listen: one for SMTP, one for IMAP, and one for POP. You told sTunnel
which of its input ports connected to which server. Which input port
(from your client to sTunnel) dictated to which output port (of sTunnel)
would connect to which mail server. If you have one mail server, you
defined input ports in sTunnel were used for SMTP, IMAP, and POP from
your client, and those ports were mapped to one mail server's SMTP,
IMAP, and POP ports. For a 2nd account, you defined another set of
input ports in sTunnel went to which other mail server's ports.

Basically you take your mail server settings from your client, and
transfer them to sTunnel's config as to where it connects. You then reconfigure your e-mail client to connect to sTunnel's ports, not to the
mail server ports. I don't recall sTunnel as some "heavy" proxy
consuming lots of resources when left running in the background.

I think you get an example config file (stunnel.conf) with examples how
to define the mappings. An example page is shown at:

https://www.stunnel.org/config_windows.html

It would be a lot easier and more reliable (less clients in the chain)
if you went with an e-mail client that already has SSL/TLS support for encrypted connections along with OAUTH2 support if your e-mail provider
demands OAUTH2 authentication.

Why would you want to unload sTunnel just because you weren't using your
e-mail client? How big is the file size for sTunnel? When you load
sTunnel, how much memory does its process consume? If you are so tight
on RAM that you cannot afford to leave sTunnel running then you have far
more severe problems due to lack of RAM. Similarly, why wouldn't you
leave your e-mail client always running, so it can inform you when new
messages arrive? If the client also does calendaring, like Thunderbird,
you'd want the client always running to also remind you of appointments.
E-mail is something you always leave running in the background, and
sTunnel if you're incorporating it with your e-mail client. If you keep unloading your e-mail client (and sTunnel) then you might as well dump
using a local e-mail client, and move to using the webmail client
offered by your e-mail provider where you would also have to keep
loading your web browser to manually check if you have new messages.

No e-mail client, and no encryption proxy, that is missing OAUTH2
support is going to get e-mail working with an e-mail provider that
demands the client support OAUTH2. If your e-mail provider requires
OAUTH2, you are wasting time hunting for and trialing e-mail clients or
proxies that add SSL/TLS support but do not add support for OAUTH2.

https://sylpheed.sraoss.jp/en/news.html
OAUTH2 support added in 3.7 circa Sep 2022.
TLS 1.1/1.2 support added in 3.4.3 circa Jan 2016.

So why the hell are you wasting time looking for SSL/TLS tunneling
proxies (e.g., sTunnel) to add to Sylpheed?

I didn't see they have peer forums at https://sylpheed.sraoss.jp/en/,
but maybe you're supposed to use their mailing list to get community
help (https://sylpheed.sraoss.jp/en/ml.html). I suspect configuring
e-mail accounts in Sylpheed is no more difficult than it was in your old
e-mail client (Outlook Express).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 16 May 2023 19:35:26 +0100, Jack wrote:
[snip]

Can you just... [SNIP]

*plonk*
Yes. I can just do that.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

VanguardLH,

2 weeks ago I mentioned sTunnel in my first reply to you.

I must have missed it (probably because it did not attempt to answer my thanwhile question). I've become weird like that (skipping posts).
Probably because of how Google throws a lot of crap at you and you need to filter the "results" on the likelyhood of being related, if ever so
slighltly, to what you where searching for. :-\

It adds SSL/TLS encryption. It does not add support for OAUTH2.

That was the idea, yes.

Some info : my googeling returned some info that seems to indicate that, for smtp, port 587 is the one which does it the old way (using starttls etc.), while port 465 just (presumably) expects a standard "port 110" connection,
just wrapped in an SSL layer.

The only of sTunnel that I remember was a bit difficult was writing
up the mapping in the config file.

Yeah, I saw that being mentioned too. Hence my current question to see if
ther eare others available.

You told on which ports sTunnel would listen: one for SMTP, one for
IMAP, and one for POP

Just SMTP and POP3. I have zero use for IMAP.

It probably doesn't make a difference though, as a simple SSL tunneling
program should be fully agnostic to the data going over it.

Basically you take your mail server settings from your client,
and transfer them to sTunnel's config as to where it connects.

Yep, that's what I thought it (sh|w)ould be be doing too.

I think you get an example config file (stunnel.conf) with examples
how to define the mappings. An example page is shown at:

https://www.stunnel.org/config_windows.html

Thanks. Will take a peek.

If your e-mail provider requires OAUTH2, you are wasting time
hunting for and trialing e-mail clients or proxies that add
SSL/TLS support but do not add support for OAUTH2.

And if my e-mail provider *doesn't* require oauth2 than I would be wasting
time by searching from e-mail clients that specifically support it, wouldn't
I ? :-)

But don't worry. I did not only test the e-mail clients on how easy they
where to configure, when that went right I also tried to send and receive
some test emails with them. Sylpheed had no problems with it - even though
I did not bother with setting anything up beyond basic configuration (the
pop3 and smtp server adress, email adress, username and password).

So why the hell are you wasting time looking for SSL/TLS tunneling
proxies (e.g., sTunnel) to add to Sylpheed?

What makes you think its an "and" thing ? <puzzeled> I mean, it doesn't
make any sense to add an SSL tunnel to a program which itself already
supports SSL.

No, its an "or" : If I can use a SSL tunnel than I can keep using the email client I've been using for the past years. Which is what I prefer.

I suspect configuring e-mail accounts in Sylpheed is no more difficult
than
it was in your old e-mail client (Outlook Express).

I would suspect that for /any/ email program. Alas, even just the few I've tried out in the last few weeks shows that thats not the case (as I've mentioned in that thread).

But if you're asking if Sylpheed was easy to configure ? I honestly can't remember having had any (serious) problems with it, so I guess it was (for
me).

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"R.Wieser" <[email protected]d> wrote:

VanguardLH,

2 weeks ago I mentioned sTunnel in my first reply to you.

I must have missed it (probably because it did not attempt to answer my thanwhile question). I've become weird like that (skipping posts).
Probably because of how Google throws a lot of crap at you and you need to filter the "results" on the likelyhood of being related, if ever so slighltly, to what you where searching for. :-\

It adds SSL/TLS encryption. It does not add support for OAUTH2.

That was the idea, yes.

Some info : my googeling returned some info that seems to indicate that, for smtp, port 587 is the one which does it the old way (using starttls etc.), while port 465 just (presumably) expects a standard "port 110" connection, just wrapped in an SSL layer.

The only of sTunnel that I remember was a bit difficult was writing
up the mapping in the config file.

Yeah, I saw that being mentioned too. Hence my current question to see if ther eare others available.

You told on which ports sTunnel would listen: one for SMTP, one for
IMAP, and one for POP

Just SMTP and POP3. I have zero use for IMAP.

It probably doesn't make a difference though, as a simple SSL tunneling program should be fully agnostic to the data going over it.

Basically you take your mail server settings from your client,
and transfer them to sTunnel's config as to where it connects.

Yep, that's what I thought it (sh|w)ould be be doing too.

I think you get an example config file (stunnel.conf) with examples
how to define the mappings. An example page is shown at:

https://www.stunnel.org/config_windows.html

Thanks. Will take a peek.

If your e-mail provider requires OAUTH2, you are wasting time
hunting for and trialing e-mail clients or proxies that add
SSL/TLS support but do not add support for OAUTH2.

And if my e-mail provider *doesn't* require oauth2 than I would be wasting time by searching from e-mail clients that specifically support it, wouldn't I ? :-)

But don't worry. I did not only test the e-mail clients on how easy they where to configure, when that went right I also tried to send and receive some test emails with them. Sylpheed had no problems with it - even though
I did not bother with setting anything up beyond basic configuration (the pop3 and smtp server adress, email adress, username and password).

So why the hell are you wasting time looking for SSL/TLS tunneling
proxies (e.g., sTunnel) to add to Sylpheed?

What makes you think its an "and" thing ? <puzzeled> I mean, it doesn't make any sense to add an SSL tunnel to a program which itself already supports SSL.

No, its an "or" : If I can use a SSL tunnel than I can keep using the email client I've been using for the past years. Which is what I prefer.

I suspect configuring e-mail accounts in Sylpheed is no more difficult
than
it was in your old e-mail client (Outlook Express).

I would suspect that for /any/ email program. Alas, even just the few I've tried out in the last few weeks shows that thats not the case (as I've mentioned in that thread).

But if you're asking if Sylpheed was easy to configure ? I honestly can't remember having had any (serious) problems with it, so I guess it was (for me).

Regards,
Rudy Wieser

This thread asks about using a tunneling proxy to add SSL/TLS encryption
to connects from some e-mail client. You also mentioned slypheed looks
like what you'll use. Yet sylpheed's doc pages says it supports
SSL/TLS. So, yes, I got confused in this thread, because you're asking
about using sTunnel with sylpheed, but sTunnel would be superfluous.
You didn't mention when discussing sTunnel that you intended to use it
with your old client, Outlook Express.

Okay, now that the topic has changed to "Looking for tunneling proxy to
add SSL/TLS to Outlook Express", yep, that'll work. As far as other
proxies to do the same work, nope, I don't know fo any. Back when I
used OE, sTunnel was the solution I found, and that everyone else still
using OE went to.

The mapping in sTunnel isn't that difficult. Your e-mail client is
already configured to connect to mail servers at a port there using a
protocol. You just transfer those definitions to stunnel.conf: you
define input ports in sTunnel that match those you specified in your
e-mail client, and you change the account definitions to use the same
ports but specify localhost as the server name (sTunnel is running on
your localhost). Alas, you have to use different ports when you have
more than 1 account to map through sTunnel.

I remember using IANA's port number assignments to figure out which
ports I should not step on just in case I later use software that
defaults to those other ports. IANA only assigns well-known ports from
0 to 1023, and registered ports from 1024 to 49151. Processes might use ethereal ports (49152 to 65535), but you won't know which are used
unless you check what current processes are using which ports. I don't remember which ones I used, but (as an example), I'd probably start by
using 65xxx for the sTunnel in ports.

https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

You can also use SysInternals' TCPview to see which local ports are
already in use by existing processes.

Account 1:
client: SMTP port 587 ---> stunnel in: 587
stunnel out: servername1, port 587
client: POP port 995 ---> stunnel in: 995
stunnel out: servername1, port 995

Account 2:
client: SMTP port 65587 ---> stunnel in: 65587
stunnel out: servername2, port 587
client: POP port 65995 ---> stunnel in: 65995
stunnel out: servername2, port 995

Account 3:
client: SMTP port 65687 ---> stunnel in: 65687
stunnel out: servername3, port 587
client: POP port 65996 ---> stunnel in: 65996
stunnel out: servername3, port 995

You're doing the mapping in stunnel.conf to connect an input port on
which sTunnel will listen to an output port that specifies where to go
(just like when you define accounts in an e-mail client to where it
goes). Others might suggest other input ports for sTunnel when using
multiple e-mail accounts. Since the e-mail client will be specifying
localhost for every e-mail account, the sTunnel input ports is how you differentiate one account from another.

So, I take it that whomever are your unidentified e-mail providers do
*not* require OAUTH2 to authenticate to their servers; else, all this
sTunnel business is wasted time and effort. I haven't researched it
much, but looks like there's another proxy to add OAUTH2 support to
incapable e-mail clients, and is at:

https://github.com/simonrob/email-oauth2-proxy

However, that adds another link in the chain:

client --> stunnel --> server
to
client --> stunnel --> oauthproxy --> server

The longer the chain, the more fragile it gets. Then remember that any anti-virus program is going to insert its transparent proxy into the
chain making the chain even more fragile.

client --> stunnel --> oauthproxy --> AVproxy --> server

Also, when there is an error in e-mail access, which proxy's log do you
review: client's log, stunnel's log, or oauth2 proxy's log? You have
more chain links that can fail, and it'll be up to you to determine
which one broke. That's why I eventually dumped OE and went to a client
that supports SSL/TLS connections, and later when OAUTH2 was required by
some providers. I'd rather just have one log, the client's, to review
when there are errors. Sysadmins try to make their job easier, not
harder by having to review logs for multiple links in the chain.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

VanguardLH,

This thread asks about using a tunneling proxy to add SSL/TLS
encryption to connects from some e-mail client. You also mentioned
slypheed looks like what you'll use. Yet sylpheed's doc pages says
it supports SSL/TLS. So, yes, I got confused in this thread,

My apologies. I thought that the line "However, yesterday I realized that there is a possible another solution" (apologies for having used "another" instead of "other") would have made clear that I was considering something
else than replacing my email client.

Okay, now that the topic has changed to "Looking for tunneling proxy
to add SSL/TLS to Outlook Express", yep, that'll work.

Replace "Outlook Express" with "an email client which does not have SSL" and I'll agree with you. That in my case its OE doesn't matter in the
slightest.

So, I take it that whomever are your unidentified e-mail providers
do *not* require OAUTH2 to authenticate to their servers; else, all
this sTunnel business is wasted time and effort.

As said, assuming it to be the other way around when its not causes the same waste of time

But yes, that is a risk you always run. Though in my case it looks like
that me being able to send and receive email using Sylpheed - without having configured it for oath usage - seems to indicate its not needed.

And to me that makes sense : I'm using an encrypted connection and am able
to correctly supply a username/password combination. I'm not sure what
level of security oauth would add to it.

The longer the chain, the more fragile it gets.

True. And I'm well aware of that, don't worry.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"R.Wieser" <[email protected]d> wrote:

By the way : I have little wish to have such a SSL-tunnel program running
all the time, so something that can easily be started and terminated would
be preferred.

I'm also confused why that is a requirement. It obviates getting
notified when new messages arrive in your e-mail account.

e-mail client: off
and
sTunnel: off
Result: No notification of new messages.

e-mail client: off
and
sTunnel: on
Result: No notifications of new messages.

e-mail client: on
and
sTunnel: off
Result: No notification of new messages.

e-mail client: on
and
sTunnel: on
Result: Notified of new messages.

Only in the last scenario will you get notified of new messages. If you operate in any of the other scenarios (of which having sTunnel turned
off at any time), you remove a prime function of a local e-mail client notifying you when new messages arrive. If you intend to operate with
sTunnel off or the e-mail client off or both, you might as well not
bother using a local e-mail client with or without sTunnel. Loading the
e-mail client and sTunnel (one, or both) on demand means you denigrate
those programs to manual checking.

For manual checking of new messages, use a URL shortcut to your e-mail provider's webmail client. You have a web browser already. For manual checking via webmail, you don't need to trial a multitude of local
e-mail clients nor bother with configuring and testing configs for
sTunnel. There are plenty of users that don't bother with local e-mail
clients (even when one has been pre-installed), and just use webmail. I
prefer to get notified when there are new messages. Some users don't
care, don't want to figure out how to install and configure a local
e-mail client, and only want to manually check for new messages which is easiest using webmail clients.

My local e-mail client consumes 161MB of RAM. Its size is likely larger
than your eventual choice of local e-mail client with sTunnel. For your unidentified local e-mail client (you said OE before, then mentioned
sylpheed, but now want to leave your choice unidentified to encompass
any local e-mail client absent of SSL/TLS connects), how much memory
does it consume, and how much does sTunnel consume?

What is the influencing factor on why you want sTunnel unloaded until
you load whatever SSL/TLS-deficient local e-mail client? Why unload the
local e-mail client, too, or disable it by unloading sTunnel?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

VanguardLH,

By the way : I have little wish to have such a SSL-tunnel program running
all the time, so something that can easily be started and terminated
would
be preferred.

I'm also confused why that is a requirement. It obviates getting
notified when new messages arrive in your e-mail account.

True. But you are thinking as if from the POV of someone who has no clue
how to automate stuff.

Imagine a small script (batchfile ?) which launches the SSL tunnel, launches the email client, waits until the email client terminates, closes the SSL tunnel.

IOW, the tunnel and the email program would always be opened and closed in tandem.

Only in the last scenario will you get notified of new messages.

Not in my case.

Besides that I close my email program as soon as I'm done with it, I've also disabled any setting pertaining to the automatic up/downloading of messages (email or otherwise).

For manual checking of new messages, use a URL shortcut to your
e-mail provider's webmail client.

lol ? Why ? I can open my email client and press its "fetch new mail"
button and than directly have access to it. Why would I want to use a
wholly different environment just to check if I have new email ? Thats a hassle I do not want or need.

For your unidentified local e-mail client (you said OE before, then
mentioned sylpheed, but now want to leave your choice unidentified
to encompass any local e-mail client absent of SSL/TLS connects),
how much memory does it consume, and how much does sTunnel consume?

I have no idea how much and you're missing the point : its not about
resource usage.

What is the influencing factor on why you want sTunnel unloaded
until you load whatever SSL/TLS-deficient local e-mail client?

Do a guess. You might not agree with my reason, but try.

Why unload the local e-mail client, too

Because neither is of any use without the other ?

, or disable it by unloading sTunnel?

Disabeling my email programs access to the pop/smtp servers by just closing
it works quite well. :-)

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

VanguardLH,

Update.

my googeling returned some info that seems to indicate that, for smtp,
port 587 is the one which does it the old way (using starttls etc.),
while port 465 just (presumably) expects a standard "port 110"
connection, just wrapped in an SSL layer.

I've taken a simple standard-to-SSL tunnel program, and it works as I
expected. SMTP over SSL port 465 is just port 25 wrapped in SSL. In the
same way POP3 over SSL port 995 is just port 110 wrapped in SSL.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)