Re: [Dovecot] SSL/TLS with Outlook client
Kyle Wheeler wrote: On Wednesday, November 14 at 10:51 PM, quoth Marcus Rueckert: rejecting on wrong informations in HELO/EHLO saves me lots of spam. That's a half-baked idea at best, given that you're violating a MUST NOT in the SMTP specification. Plus, how do you judge "wrong"? Hotmail and MSN both fail to use their FQDNs in their HELO arguments---technically that's wrong. I suppose you reject all hotmail.com email? It's easy to reject on things that clearly aren't configured. HELO localhost ?? nah, that's junk. SpeedTouch.lan <- dodgy USB modem if ever i saw one spammers also quite often helo with 1. the name of your MX 2. the ip of your MX neither of which should come from the outside. So it's not so much about rejecting based on not being able to lookup the helo'd name, it's more about reject based on things that shouldn't be said to your server... Stuart
Re: [Dovecot] SSL/TLS with Outlook client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 14 Nov 2007, Nikolay Shopik wrote: The IMAP spec does not contain an identification of the client application to the server. There is no "HELO" as in SMTP. And HELO in SMTP is entirely unreliable, unverifiable, and on many servers completely skippable. RFC says you SHOULD use FQDN for HELO nothing more. But still you can add SPF record for your HELO so nobody can foged your server HELO, thats it. Well, I brought up HELO as an example just to say that the IMAP protocol has no concept at all that a client can say to the server which kind of client, e.g. "MS Outlook" vs. "Thunderbird", it is. Maybe, the user agent string in HTTP would fit better. Also: unreliable, user-settable, I know. Bye, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBRzv1sC9SORjhbDpvAQKfIwf/TnzcxJfJdncQRMK+rviHISvVSJxT6tYs MLFgYBMGfrHEJLKAxHx27fINS9e7Zm0ne6SZuAmIBzY7SO5fYo9uraU9qX2Iw5Lr ygzZaGfwCzqWXyX8tZ6+cYRGlJNF66FcN4hpqnFbLUalpKWJzN69GOuAi5hV6zMR 3sJlC3WMant6zp5T3Lg1vmH4zXLC3PmJfevYskFNcQvzBN1OSDUEtQ0NOQjAFdt4 YUBOOX95oIXspN4+3iN/ddxZazUCpPFiVhAVadTYR0/ys2n235eI8fTD4/EAXjph xL0+kl5wYSGGzwJ2b0jJLJ4Xr+3iNMJlp2+KcoR4rwRQp4alxEKfsg== =wTS3 -END PGP SIGNATURE-
Re: [Dovecot] SSL/TLS with Outlook client
On Wednesday, November 14 at 10:51 PM, quoth Marcus Rueckert: rejecting on wrong informations in HELO/EHLO saves me lots of spam. That's a half-baked idea at best, given that you're violating a MUST NOT in the SMTP specification. Plus, how do you judge "wrong"? Hotmail and MSN both fail to use their FQDNs in their HELO arguments---technically that's wrong. I suppose you reject all hotmail.com email? Check out: http://homepages.tesco.net/~J.deBoynePollard/FGA/smtp-avoid-helo.html ~Kyle -- Science is what we can tell a computer. Art is everything else. -- Knuth pgpkjtAo5yEZM.pgp Description: PGP signature
Re: [Dovecot] SSL/TLS with Outlook client
On 2007-11-14 13:31:00 -0600, Kyle Wheeler wrote: > On Wednesday, November 14 at 09:35 PM, quoth Nikolay Shopik: > >>And HELO in SMTP is entirely unreliable, unverifiable, and on many > >>servers completely skippable. > >> > >RFC says you SHOULD use FQDN for HELO nothing more. But still you > >can add SPF record for your HELO so nobody can foged your server > >HELO, thats it. > > To quote RFC 821: > > The HELO receiver MAY verify that the HELO parameter really > corresponds to the IP address of the sender. However, the receiver > MUST NOT refuse to accept a message, even if the sender's HELO > command fails verification. > > If you prefer RFC 2821: > > An SMTP server MAY verify that the domain name parameter in the > EHLO command actually corresponds to the IP address of the client. > However, the server MUST NOT refuse to accept a message for this > reason if the verification fails: the information about > verification failure is for logging and tracing only. > > In practice, what that means is that HELO is useless for doing much of > anything. Spammers or other criminals can forge your server's HELO to > their hearts content and you are expressly forbidden from actually > doing anything about it. > > SPF does not override the existing standards. > > And in any case, SPF HELO checks are a pointless exercise, since HELO > is permitted to be anything at all without affecting the envelope of > the message. A spammer can create his own domain, publish his own SPF > settings that explicitly allow email from any source, and use that > domain as his HELO string. rejecting on wrong informations in HELO/EHLO saves me lots of spam. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
Re: [Dovecot] SSL/TLS with Outlook client
On Wednesday, November 14 at 09:15 PM, quoth Timo Sirainen: On Wed, 2007-11-14 at 12:29 -0600, Kyle Wheeler wrote: On Wednesday, November 14 at 11:51 AM, quoth Ed W: > Is TLS always performed BEFORE auth with generally available POP/IMAP > clients? .. Technically, there's nothing in the IMAP spec that forbids doing it the other way around, Actually there is :) STARTTLS is a valid command only in non-authenticated state. Ah! My mistake. That's what I get for not paying close enough attention. :) ~Kyle -- For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken pgpbeQYtKfXG3.pgp Description: PGP signature
Re: [Dovecot] SSL/TLS with Outlook client
On 14.11.2007 22:31, Kyle Wheeler wrote: On Wednesday, November 14 at 09:35 PM, quoth Nikolay Shopik: And HELO in SMTP is entirely unreliable, unverifiable, and on many servers completely skippable. RFC says you SHOULD use FQDN for HELO nothing more. But still you can add SPF record for your HELO so nobody can foged your server HELO, thats it. To quote RFC 821: The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification. If you prefer RFC 2821: An SMTP server MAY verify that the domain name parameter in the EHLO command actually corresponds to the IP address of the client. However, the server MUST NOT refuse to accept a message for this reason if the verification fails: the information about verification failure is for logging and tracing only. In practice, what that means is that HELO is useless for doing much of anything. Spammers or other criminals can forge your server's HELO to their hearts content and you are expressly forbidden from actually doing anything about it. SPF does not override the existing standards. And in any case, SPF HELO checks are a pointless exercise, since HELO is permitted to be anything at all without affecting the envelope of the message. A spammer can create his own domain, publish his own SPF settings that explicitly allow email from any source, and use that domain as his HELO string. ~Kyle That's I'm talking about they only force you to use FQDN but it MAY unresolvable thats it. Sure thing about SPF HELO checks, I'm just notice about what they can't forged your HELO(but AFAIK not much servers check HELO SPF records), everything else is absolutely correct you saying.
Re: [Dovecot] SSL/TLS with Outlook client
On Wednesday, November 14 at 09:35 PM, quoth Nikolay Shopik: And HELO in SMTP is entirely unreliable, unverifiable, and on many servers completely skippable. RFC says you SHOULD use FQDN for HELO nothing more. But still you can add SPF record for your HELO so nobody can foged your server HELO, thats it. To quote RFC 821: The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification. If you prefer RFC 2821: An SMTP server MAY verify that the domain name parameter in the EHLO command actually corresponds to the IP address of the client. However, the server MUST NOT refuse to accept a message for this reason if the verification fails: the information about verification failure is for logging and tracing only. In practice, what that means is that HELO is useless for doing much of anything. Spammers or other criminals can forge your server's HELO to their hearts content and you are expressly forbidden from actually doing anything about it. SPF does not override the existing standards. And in any case, SPF HELO checks are a pointless exercise, since HELO is permitted to be anything at all without affecting the envelope of the message. A spammer can create his own domain, publish his own SPF settings that explicitly allow email from any source, and use that domain as his HELO string. ~Kyle -- I believe that every human has a finite number of heart-beats. I don't intend to waste any of mine running around doing exercises. -- Neil Armstrong pgpxoVg5qadLG.pgp Description: PGP signature
Re: [Dovecot] SSL/TLS with Outlook client
On Wed, 2007-11-14 at 12:29 -0600, Kyle Wheeler wrote: > On Wednesday, November 14 at 11:51 AM, quoth Ed W: > > Is TLS always performed BEFORE auth with generally available POP/IMAP > > clients? .. > Technically, there's nothing in the IMAP spec that forbids doing it > the other way around, Actually there is :) STARTTLS is a valid command only in non-authenticated state. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] SSL/TLS with Outlook client
On 14.11.2007 21:30, Kyle Wheeler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, November 14 at 02:18 PM, quoth Steffen Kaiser: On Wed, 14 Nov 2007, Ed W wrote: Is TLS always performed BEFORE auth with generally available POP/IMAP clients? The IMAP spec does not contain an identification of the client application to the server. There is no "HELO" as in SMTP. And HELO in SMTP is entirely unreliable, unverifiable, and on many servers completely skippable. RFC says you SHOULD use FQDN for HELO nothing more. But still you can add SPF record for your HELO so nobody can foged your server HELO, thats it.
Re: [Dovecot] SSL/TLS with Outlook client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, November 14 at 02:18 PM, quoth Steffen Kaiser: >On Wed, 14 Nov 2007, Ed W wrote: > >> Is TLS always performed BEFORE auth with generally available POP/IMAP >> clients? > >The IMAP spec does not contain an identification of the client application >to the server. There is no "HELO" as in SMTP. And HELO in SMTP is entirely unreliable, unverifiable, and on many servers completely skippable. ~Kyle - -- It ain't the parts of the Bible that I can't understand that bother me, it is the parts that I do understand. -- Mark Twain -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHOz7CBkIOoMqOI14RAnbPAJ9rhYTjqdcd+4Mnmqtzb0Ydu5PmfQCdEdpM YNO3SxOPFKKVx1xknTbGuzc= =eDdV -END PGP SIGNATURE-
Re: [Dovecot] SSL/TLS with Outlook client
On Wednesday, November 14 at 11:51 AM, quoth Ed W: Is TLS always performed BEFORE auth with generally available POP/IMAP clients? Yes, because that's generally the entire point of using encryption. After all, what's more important: encrypting your username/password before transmitting it over an open wire, or encrypting your email messages before transmitting them over an open wire? (Hint: if you need your email encrypted, use PGP.) Technically, there's nothing in the IMAP spec that forbids doing it the other way around, however many IMAP servers (including Dovecot) typically reject unencrypted authentication attempts. Random idea but if there were some way to identify the client BEFORE presenting the certificate then it would be possible to present one of a number of certificates depending on the incoming client Of course, but unfortunately, there's very little. The only thing the server can reliably know is the client's IP address and source TCP port (and it's own IP address). Not much to go on. (don't fancy scraping SMTP server log files and matching back to IP addresses though...) HEH. SMTP-before-IMAP? What a bizarre concept. :) You'd just be transferring the problem: how does the SMTP server know what certificate to use? ~Kyle -- You can gain reconciliation from your enemies, but you can only gain peace from yourself. -- Rubin "The Hurricane" Carter pgpYb8OarAFL7.pgp Description: PGP signature
Re: [Dovecot] SSL/TLS with Outlook client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 14 Nov 2007, Ed W wrote: Is TLS always performed BEFORE auth with generally available POP/IMAP clients? The IMAP spec does not contain an identification of the client application to the server. There is no "HELO" as in SMTP. Bye, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBRzr1vy9SORjhbDpvAQLZeQf+Ka4yKA5Mw8rPBrI3mbwSeF5mTua7VyGE V8PhHxCeyRpwd+e9Ff0CmL404pRJYq1NM3TFxemNH2ILPBA6S1U0+H3ABkS3vCEi PcKjvWEL80SZ6bDgBlWvSi2ji3qgWwcBg2tzn93wNO7D2Yv5A4byR1PZvT2vlYr4 hIUyTXO3LRCM6Kg3aO2B+m+5zA9cYwrfSAA1GzWWdwwZkmZFycRMoul7u4RAPVvJ okcysIKMS2ea1XPXKGFhTjVeRvStos/tTOhM4EyZOTTp3yV2VrbuSD1SAIycPw5o bK0IBs1uWvDux/qvW7TLMSR2C828N+3ZXD5pqJqwhdFhHRIKjiSA9A== =FT2z -END PGP SIGNATURE-
Re: [Dovecot] SSL/TLS with Outlook client
Is TLS always performed BEFORE auth with generally available POP/IMAP clients? Random idea but if there were some way to identify the client BEFORE presenting the certificate then it would be possible to present one of a number of certificates depending on the incoming client (don't fancy scraping SMTP server log files and matching back to IP addresses though...) Ed W
Re: [Dovecot] SSL/TLS with Outlook client
Agree with Hugo most root CA have intermidate certificates which should supplied with your server certificate. Otherwise chain won't work and any client don't trust it. - original message - Subject: Re: [Dovecot] SSL/TLS with Outlook client From: Hugo Monteiro <[EMAIL PROTECTED]> Date: 14/11/2007 00:14 Eli Sand wrote: > Hugo Monteiro wrote: > >> Ah ... wildcard certs .. from what i recall, certs issued like >> *.example.com were not very well accepted by M$ clients. You should >> test against non wildcard certs and see how it behaves. >> > > Already have and no luck :( My domain is elisand.com and I have tried > *.elisand.com, mx1.elisand.com (I believe that's what my MX record is... if > not, whatever it is is what I tried) and mail.elisand.com which is the > smtp/imap server name I use in Outlook. All three yield the same result :( > > Eli. > > > I have taken the liberty to connect to your server, using openssl, i've seen the following: $ openssl s_client -CApath /usr/share/ca-certificates/cacert.org/ -connect mail.elisand.com:993 CONNECTED(0003) depth=1 /O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/[EMAIL PROTECTED] verify return:1 depth=0 /CN=*.elisand.com verify return:1 --- Certificate chain 0 s:/CN=*.elisand.com i:/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/[EMAIL PROTECTED] --- i believe you should change two things. If the name you wish to use on your clients is mail.alisand.com, then the certificate should read CN=mail.elisand.com. Furthermore, it's always a good idea to provide the chaining certificate path on dovecots side. Try using the ssl_ca_file directive on dovecot's configuration. Regards, Hugo Monteiro. -- ci.fct.unl.pt:~# cat .signature Hugo Monteiro Email: [EMAIL PROTECTED] Telefone : +351 212948300 Ext.15307 Centro de Informática Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa Quinta da Torre 2829-516 Caparica Portugal Telefone: +351 212948596 Fax: +351 212948548 www.ci.fct.unl.pt [EMAIL PROTECTED] ci.fct.unl.pt:~# _
Re: [Dovecot] SSL/TLS with Outlook client
Eli Sand wrote: Hugo Monteiro wrote: Ah ... wildcard certs .. from what i recall, certs issued like *.example.com were not very well accepted by M$ clients. You should test against non wildcard certs and see how it behaves. Already have and no luck :( My domain is elisand.com and I have tried *.elisand.com, mx1.elisand.com (I believe that's what my MX record is... if not, whatever it is is what I tried) and mail.elisand.com which is the smtp/imap server name I use in Outlook. All three yield the same result :( Eli. I have taken the liberty to connect to your server, using openssl, i've seen the following: $ openssl s_client -CApath /usr/share/ca-certificates/cacert.org/ -connect mail.elisand.com:993 CONNECTED(0003) depth=1 /O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/[EMAIL PROTECTED] verify return:1 depth=0 /CN=*.elisand.com verify return:1 --- Certificate chain 0 s:/CN=*.elisand.com i:/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/[EMAIL PROTECTED] --- i believe you should change two things. If the name you wish to use on your clients is mail.alisand.com, then the certificate should read CN=mail.elisand.com. Furthermore, it's always a good idea to provide the chaining certificate path on dovecots side. Try using the ssl_ca_file directive on dovecot's configuration. Regards, Hugo Monteiro. -- ci.fct.unl.pt:~# cat .signature Hugo Monteiro Email: [EMAIL PROTECTED] Telefone : +351 212948300 Ext.15307 Centro de Informática Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa Quinta da Torre 2829-516 Caparica Portugal Telefone: +351 212948596 Fax: +351 212948548 www.ci.fct.unl.pt [EMAIL PROTECTED] ci.fct.unl.pt:~# _
Re: [Dovecot] SSL/TLS with Outlook client
Hugo Monteiro wrote: > Ah ... wildcard certs .. from what i recall, certs issued like > *.example.com were not very well accepted by M$ clients. You should > test against non wildcard certs and see how it behaves. Already have and no luck :( My domain is elisand.com and I have tried *.elisand.com, mx1.elisand.com (I believe that's what my MX record is... if not, whatever it is is what I tried) and mail.elisand.com which is the smtp/imap server name I use in Outlook. All three yield the same result :( Eli.
Re: [Dovecot] SSL/TLS with Outlook client
Eli Sand wrote: Nikolay Shopik wrote: Usually it works like this. You are configure your mail client to address like this mail.example.com, when mail client establish connection to server and receive certificate it compare CN with current configuration in it. So if you configure connect to mx.example.com but server receive certificate with CN=mail.example.com it should warn you. It doesn't do any PTR lookups. I have experimented with Outlook 2k7 and valid certificates from CACert and I am unable to say that this is for sure how Outlook is behaving. I have tested with a wildcard cert, and names of both the MX record and the A record configured in the mail client. All three of which produced the same ultimate "The target principal name is incorrect." Error. The certificate is valid and I do have the root CA certs loaded in Windows correctly. Ah ... wildcard certs .. from what i recall, certs issued like *.example.com were not very well accepted by M$ clients. You should test against non wildcard certs and see how it behaves. Regards, Hugo Monteiro. -- ci.fct.unl.pt:~# cat .signature Hugo Monteiro Email: [EMAIL PROTECTED] Telefone : +351 212948300 Ext.15307 Centro de Informática Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa Quinta da Torre 2829-516 Caparica Portugal Telefone: +351 212948596 Fax: +351 212948548 www.ci.fct.unl.pt [EMAIL PROTECTED] ci.fct.unl.pt:~# _
Re: [Dovecot] SSL/TLS with Outlook client
Nikolay Shopik wrote: > Usually it works like this. You are configure your mail client to > address like this mail.example.com, when mail client establish > connection to server and receive certificate it compare CN with current > configuration in it. So if you configure connect to mx.example.com but > server receive certificate with CN=mail.example.com it should warn you. > It doesn't do any PTR lookups. I have experimented with Outlook 2k7 and valid certificates from CACert and I am unable to say that this is for sure how Outlook is behaving. I have tested with a wildcard cert, and names of both the MX record and the A record configured in the mail client. All three of which produced the same ultimate "The target principal name is incorrect." Error. The certificate is valid and I do have the root CA certs loaded in Windows correctly. I'm pretty close to emailing Microsoft themselves to help solve the problem since I am unable to figure out why the error is happening (even debug logging from Outlook produces nothing). Eli.
Re: [Dovecot] SSL/TLS with Outlook client
On 13.11.2007 22:32, Ed W wrote: Nikolay Shopik wrote: On 13.11.2007 4:22, Jonathan Bond-Caron wrote: Anyone have any solution to this? I also getting a "The target principal name is incorrect." in Outlook 2007 Is this a problem with dovecot? That's probably because you CN doesn't match your server in certificate. Do you using self-signed certificated? Is there any way around this if you have an IP and lots of A records pointing at it? As I understand it mail clients are going to winge if you use any name other than the one which is in the certificate? My simple research suggests that they don't do a lookup, then a reverse lookup and compare that? It's a problem with vhosted domains... Any suggestions? Ed W Usually it works like this. You are configure your mail client to address like this mail.example.com, when mail client establish connection to server and receive certificate it compare CN with current configuration in it. So if you configure connect to mx.example.com but server receive certificate with CN=mail.example.com it should warn you. It doesn't do any PTR lookups.
Re: [Dovecot] SSL/TLS with Outlook client
Nikolay Shopik wrote: On 13.11.2007 4:22, Jonathan Bond-Caron wrote: Anyone have any solution to this? I also getting a "The target principal name is incorrect." in Outlook 2007 Is this a problem with dovecot? That's probably because you CN doesn't match your server in certificate. Do you using self-signed certificated? Is there any way around this if you have an IP and lots of A records pointing at it? As I understand it mail clients are going to winge if you use any name other than the one which is in the certificate? My simple research suggests that they don't do a lookup, then a reverse lookup and compare that? It's a problem with vhosted domains... Any suggestions? Ed W
Re: [Dovecot] SSL/TLS with Outlook client
On 13.11.2007 4:22, Jonathan Bond-Caron wrote: Anyone have any solution to this? I also getting a "The target principal name is incorrect." in Outlook 2007 Is this a problem with dovecot? That's probably because you CN doesn't match your server in certificate. Do you using self-signed certificated?
[Dovecot] SSL/TLS with Outlook client
Anyone have any solution to this? I also getting a "The target principal name is incorrect." in Outlook 2007 Is this a problem with dovecot?
Re: [Dovecot] SSL/TLS with Outlook client
Rick wrote: > You could try the old import trick - do https://mail.elisand.com:993 and > accept the cert in IE. Outlook should then just accept it. Thanks Rick - that's a neat trick I didn't even know/think about. However, after trying it (IE7 doesn't seem to let you save invalid certs btw, in my experience anyways) - it just confirmed that the certificates I'm trying are both valid. After I waited for the IMAP session to time out (so I'd see output in the browser), the "security audit" for IE showed that the certificate (tried both mail.elisand.com and *.elisand.com) are OK. Eli.
Re: [Dovecot] SSL/TLS with Outlook client
You could try the old import trick - do https://mail.elisan.com:993 and accept the cert in IE. Outlook should then just accept it. Rick On Thu, 2007-10-25 at 10:08 -0400, Eli wrote: > I am trying to get TLS to work with Outlook 2007 and I've hit a small > problem. Whenever I start it up, I get this error: > > "The server you are connected to is using a security certificate that cannot > be verified. > The target principal name is incorrect." (yes/no choice of trusting) > > I first tried with a wildcard cert (*.elisand.com), and then tried with > mail.elisand.com - both certs are from cacert.org and the root CA certs are > installed and functioning properly on my system (so the certs should be > trusted). > > I've searched all over Google and such trying to find out why Outlook would > give me this error from an IMAP/TLS connection (closest I could find was > Exchange related info), and I know this is by no means an Outlook mailing > list... though I'm just wondering if anyone else on here has ever > encountered this problem before and could point me in the right direction to > getting the SSL cert working with Outlook. > > Thanks in advance! >
[Dovecot] SSL/TLS with Outlook client
I am trying to get TLS to work with Outlook 2007 and I've hit a small problem. Whenever I start it up, I get this error: "The server you are connected to is using a security certificate that cannot be verified. The target principal name is incorrect." (yes/no choice of trusting) I first tried with a wildcard cert (*.elisand.com), and then tried with mail.elisand.com - both certs are from cacert.org and the root CA certs are installed and functioning properly on my system (so the certs should be trusted). I've searched all over Google and such trying to find out why Outlook would give me this error from an IMAP/TLS connection (closest I could find was Exchange related info), and I know this is by no means an Outlook mailing list... though I'm just wondering if anyone else on here has ever encountered this problem before and could point me in the right direction to getting the SSL cert working with Outlook. Thanks in advance!
