[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?
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?
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
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.
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.
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 : hugo.monteiro@fct.unl.pt 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 apoio@fct.unl.pt
ci.fct.unl.pt:~# _
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.
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(00000003) depth=1 /O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org 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/emailAddress=support@cacert.org
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 : hugo.monteiro@fct.unl.pt 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 apoio@fct.unl.pt
ci.fct.unl.pt:~# _
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
-----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-----
-----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-----
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.
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
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.
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
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
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
- the name of your MX
- 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
-----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-----
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
On Wed, 2007-11-14 at 12:29 -0600, Kyle Wheeler wrote:
Is TLS always performed BEFORE auth with generally available POP/IMAP clients? .. Technically, there's nothing in the IMAP spec that forbids doing it
On Wednesday, November 14 at 11:51 AM, quoth Ed W: the other way around,
Actually there is :) STARTTLS is a valid command only in non-authenticated state.
On Wednesday, November 14 at 09:15 PM, quoth Timo Sirainen:
On Wed, 2007-11-14 at 12:29 -0600, Kyle Wheeler wrote:
Is TLS always performed BEFORE auth with generally available POP/IMAP clients? .. Technically, there's nothing in the IMAP spec that forbids doing it
On Wednesday, November 14 at 11:51 AM, quoth Ed W: 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
participants (10)
-
Ed W
-
Eli Sand
-
Hugo Monteiro
-
Jonathan Bond-Caron
-
Kyle Wheeler
-
Marcus Rueckert
-
Nikolay Shopik
-
Steffen Kaiser
-
Stuart Auchterlonie
-
Timo Sirainen