Been using GPG4WIN (v3.1.16 loaded) for a couple years but have not had to get into [some] nuts and bolts till now.
GPG4WIN encryption via Outlook (GpgOL plugin) has worked fine in and out with a webhost mail service being used. Pretty much standard mail settings in and out (POP3, SMTP, SSL/TLS, normal authentication for incoming and outgoing).
Changed my outgoing server over to use PostMark mail service who I have for other needs, allowing me to track those messages. However, none of the encrypted messages are getting to them, Have enabled some of the LOG files to see if I can pick anything out but nothing yet. Still have some testing to do.
Sent a note to PostMark and they asked what TLS version the GpgOL plugin is using. Have not found anything that states “GpgOL uses TLS x.x”. Have read some threads that imply it GPG4 is using TLS v1.2 and will soon be 1.3, but no real official statement with respect to TLS versioning.
What I thought is GPG4WIN is encrypting the message before it even is transmitted so a secure connection is not even required. Is that correct?
Will continue testing various settings and reviewing log files but thought I would throw this out there for any GPG4WIN gurus!
if you are using Outlook SMTP via TLS to the PostMark service, then this is the same transport method as before. GpgOL encrypts the message, and gives it to Outlook for transportation.
It does not do transportation itself.
The crypto engine of Gpg4win is called GnuPG. It can use TLS connections for receiving or sending public key information. (But again, no mails.) This explains why GnuPG can do
TLS.
If GpgOL encrypts an email for a recipient (using GnuPG in the background), it is end-to-end encrypted to the recipients and yourself. This means that its privacy is protected during transport.
Today the transport itself is also secured by using TLS, first by SMTP over TLS (called SMTPS) and secondly by POP3 via TLS (POP3S) or IMAP via TLS (IMAPS). But each server doing part of the transport could read
a plain-text email. The end-to-end decryption thus is another layer of protection even trying to defend
against listening to your emails on the transport server side.
For technical debugging, you could try and see if you find an TLS debugging proxy that listenens to the communication between your client (Outlook) and the outgoing mailserver (postmark). Note that you would temporarily allow Outlook to use a wrong TLS certificate of the proxy.