On 15.1.2014, at 0.54, Andreas Schulze wrote:
> Am 14.01.2014 20:38 schrieb Adrian Zaugg:
>> This is not the test morrison has suggested. Doing his test with telnet
>> and thus not complete the SSL handshake, the connection stays open much
>> longer than 3 Minutes. I closed the connection now man
Am 14.01.2014 20:38 schrieb Adrian Zaugg:
> This is not the test morrison has suggested. Doing his test with telnet
> and thus not complete the SSL handshake, the connection stays open much
> longer than 3 Minutes. I closed the connection now manually after a
> little more than 2 hours. This is on
Hi Pascal
Am 14.01.14 20:26 schrieb Pascal Volk:
> On 01/14/2014 04:42 PM morrison wrote:
> Please define 'forever'
>
> I just did `time openssl s_client -connect mail.example.com:143
> -starttls imap` (and nothing else):
This is not the test morrison has suggested. Doing his test with telnet
an
Am 14.01.2014 20:26, schrieb Pascal Volk:
> Please define 'forever'
>
> I just did `time openssl s_client -connect mail.example.com:143
> -starttls imap` (and nothing else):
>
> CONNECTED(0003)
> depth=0 CN = mail.…
> …
> . OK Pre-login capabilities listed, post-login capabilities have more
On 01/14/2014 04:42 PM morrison wrote:
> Hi,
>
> I am a system admin and I am evaluating using dovecot as our email server. In
> my test, I found that if I telneted to 993 port and did not do anything or I
> telneted to 143 port, sent starttls command and then did not do anything, the
> connect
Hi,
I am a system admin and I am evaluating using dovecot as our email server. In
my test, I found that if I telneted to 993 port and did not do anything or I
telneted to 143 port, sent starttls command and then did not do anything, the
connection stayed forever without timeout. This will make
ofcourse - thx ;)
Am 23.07.10 22:07, schrieb Charles Marcus:
Leander S. wrote:
Am 23.07.10 21:35, schrieb Charles Marcus:
ovecot uses %Lu (the 'L' means 'lowercase')...
^^ Where must I add this option to make it work cause that sounds like
something nice to have ...
In your user query...?
Leander S. wrote:
> Am 23.07.10 21:35, schrieb Charles Marcus:
>> ovecot uses %Lu (the 'L' means 'lowercase')...
> ^^ Where must I add this option to make it work cause that sounds like
> something nice to have ...
In your user query...?
On 07/23/2010 09:46 PM Leander S. wrote:
> ^^ Where must I add this option to make it work cause that sounds like
> something nice to have ...
See http://wiki.dovecot.org/Variables
Regards,
Pascal
--
The trapper recommends today:
http://kopfkrebs.de/mitarbeiter/mitarbeiter_der_woche.ht
Am 23.07.10 21:35, schrieb Charles Marcus:
ovecot uses %Lu (the 'L' means 'lowercase')...
^^ Where must I add this option to make it work cause that sounds like
something nice to have ...
Leander S. wrote:
> Am 23.07.10 02:59, schrieb Andrew Bruce:
>> eel free to post this to the running conversation on the list (strip my
>> email address from this email though please)
> The issue was a case sensitive typo. When Setting up your Thunderbird
> don't type in eMail Addresses & Username
Am 23.07.10 02:59, schrieb Andrew Bruce:
eel free to post this to the running conversation on the list (strip my
email address from this email though please)
The issue was a case sensitive typo. When Setting up your Thunderbird
don't type in eMail Addresses & Usernames including uppercase lette
"Leander S." writes:
> server [~]# cat /etc/ssl/mail/mail.key
> -BEGIN RSA PRIVATE KEY-
> [...]
Hmm, you have apparently posted your private key to a public maillist.
You might want to generate a new key and cert.
P.S. I just had another look at my Logs again - and I'm finding now the
following when Thunderbird 3.1 tries to establish TLS unsuccessful:
server dovecot: imap-login: Disconnected (no auth attempts):
rip=84.157.147.152, lip=192.168.1.100, TLS handshaking: SSL_accept()
failed: error:14094412:
No problem:
server [~]# dovecot -n
# 1.2.4: /usr/local/etc/dovecot.conf
# OS: FreeBSD 8.0-RELEASE amd64 ufs
protocols: imap imaps pop3 pop3s managesieve
listen(default): *
listen(imap): *
listen(pop3): *
listen(managesieve): *:2000
ssl_cert_file: /etc/ssl/mail/mail.cert
ssl_key_file: /etc/ssl/m
On 2010-07-12 1:34 PM, Leander S. wrote:
> But no, I don't know how it came there - I must have accidently done a
> typo while editing the mail. It looks like that on the server:
Always post output of dovecot -n, not copy/pastes from the config file
(unless it is something that isn't output by dov
Oh, ofcourse - a pipe - silly me ;)
But no, I don't know how it came there - I must have accidently done a
typo while editing the mail. It looks like that on the server:
##
## SSL settings
##
ssl = yes
ssl_cert_file = /etc/ssl/mail/mail.cert
ssl_key_file = /etc/ssl/mail/mail.key
#ssl_key_passw
hey,
check your dovecot.conf :
"ssl_key_file = /etc/ssl/mail/mail.key"
is that a pipe, a vertical sign after "mail.key" ?
> Thanks for your reply.
> What do you mean by "pipe"
>
> See, I can even connect via the console from the outside:
>
>
> |Notebook [~]$ openssl s_client -CApath ~/.cert/XYZ
Thanks for your reply.
What do you mean by "pipe"
See, I can even connect via the console from the outside:
|Notebook [~]$ openssl s_client -CApath ~/.cert/XYZ.com/ -connect
XYZ.com:993
CONNECTED(0003)
depth=0 /C=DE/ST=BW/L=City/O=HomeServer
GmbH/OU=WebHosting/CN=XYZ.com/emailaddress=ad
get the feeling that this is
ether a Thunderbird incompatibly or a little switch which is missed in
the dovecot.conf to get compatible - but I'm not getting it.
I set up Dovecot SSL/TLS & Postfix SSL/TLS for several times succesfully
now ... and now oll of a sudden it stops working with T
Leander S. put forth on 7/11/2010 8:24 AM:
> There is something else missed - I just don't get it ;/
The solution to your problem, or at least information pointing you in the
right direction, is in those Google search results, if you'd bother to
actually read some of them. I guess you'd rather w
Am 11.07.10 14:35, schrieb Stan Hoeppner:
Leander S. put forth on 7/11/2010 7:26 AM:
Hi,
since I upgraded to the new Thunderbird version 3.1 I can't establish a
TLS/SSL connection anymore. But before the update Thunerbird was able to
establish an encrypted session ...
Maillog shows me the f
Leander S. put forth on 7/11/2010 7:26 AM:
> Hi,
>
> since I upgraded to the new Thunderbird version 3.1 I can't establish a
> TLS/SSL connection anymore. But before the update Thunerbird was able to
> establish an encrypted session ...
>
> Maillog shows me the following now:
>
> server dovecot
P.S. Postfix TLS/SSL works still fine ... I don't understand why dovecot
doesn't want to work with the new thunderbird version ...
Hi,
since I upgraded to the new Thunderbird version 3.1 I can't establish a
TLS/SSL connection anymore. But before the update Thunerbird was able to
establish
Hi,
since I upgraded to the new Thunderbird version 3.1 I can't establish a
TLS/SSL connection anymore. But before the update Thunerbird was able to
establish an encrypted session ...
Maillog shows me the following now:
server dovecot: imap-login: Disconnected (no auth attempts):
rip=84.15
OK thanks a lot Timo :-)
BTW I wonder when 2.0 will be released for a production site ?
Thank you
On 06/04/2010 04:15 PM, Timo Sirainen wrote:
> On pe, 2010-06-04 at 14:20 +0200, Frank Bonnet wrote:
>
>> Is it possible to generate a SSL cert for each IP address
>> on the same dovecot instance i
On pe, 2010-06-04 at 14:20 +0200, Frank Bonnet wrote:
> Is it possible to generate a SSL cert for each IP address
> on the same dovecot instance in the configuration file ?
With v2.0 you can tell Dovecot to use different certs for different IPs.
With v1.x you'd have to run multiple Dovecot insta
Hello
I have a server which has two gigabits interfaces
with different IP addresses and DNS names
I would like to let IMAP(S) users access both.
Is it possible to generate a SSL cert for each IP address
on the same dovecot instance in the configuration file ?
Thanks a lot
Steffen Kaiser wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 11 Jul 2009, Ed W wrote:
per host (current situation is rather difficult... I'm using a cert
with multiple names on it, but this is hard to buy)
What expieriences do you have on client-side with those certs?
I tried
On Sun, 2009-07-12 at 19:41 +0100, Ed W wrote:
> Actually that ended up being mainly about the COMPRESS protocol
> extension - that is interesting, but I personally doubt it offers much
> extra over a simple outer layer protocol compression algorithm, eg
> native SSL compression. (However, woul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 11 Jul 2009, Ed W wrote:
per host (current situation is rather difficult... I'm using a cert with
multiple names on it, but this is hard to buy)
What expieriences do you have on client-side with those certs?
I tried a two-name cert three
Timo Sirainen wrote:
As an aside, I see several other software projects now enabling the
compression option when establishing an SSL connection - any chance
you could look at enabling the relevant lines of code in Dovecot? We
had this conversation some months/years back and it appeared simpl
On Jul 12, 2009, at 2:21 PM, Ed W wrote:
I meant that you could have one server (one IP) and when a customer
connects they can connect to mail.theirdomain.com (CNAME or A to
mail.ourserver.com) and not see warnings about the SSL cert not
matching the address they are connecting to (ie the g
Timo Sirainen wrote:
On Jul 11, 2009, at 1:10 PM, Ed W wrote:
Actually, I'm coming in rather late, but I thought that was the whole
point of TLS that you could decide what certificate to present AFTER
you knew which client was connecting? This allows virtual hosting
with a different SSL cert
On Jul 11, 2009, at 1:10 PM, Ed W wrote:
Actually, I'm coming in rather late, but I thought that was the
whole point of TLS that you could decide what certificate to present
AFTER you knew which client was connecting? This allows virtual
hosting with a different SSL cert per host (current
Steffen Kaiser wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 9 Jul 2009, Timo Sirainen wrote:
That's a wrong way to think about it. imaps is a legacy port that
should have died years ago. You can force encrypted sessions on imap
port just by setting
Well, I do not see it like
On 7/10/2009, Steffen Kaiser (skdove...@smail.inf.fh-brs.de) wrote:
> Well, I do not see it like that, moreover because the STARTLS is not
> essentially better than IMAP-over-SSL. At least one should be able to
> submit the domain/host the client wants to connect to, in order to
> enable virtual IM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 9 Jul 2009, Timo Sirainen wrote:
That's a wrong way to think about it. imaps is a legacy port that should have
died years ago. You can force encrypted sessions on imap port just by setting
Well, I do not see it like that, moreover because
On Thu, 2009-07-09 at 17:35 +0200, Federico Nicolelli wrote:
> > That's a wrong way to think about it. imaps is a legacy port that should
> > have died years ago. You can force encrypted sessions on imap port just
> > by setting disable_plaintext_auth=yes (or even more strongly with
> > ssl=requ
On Thu, 2009-07-09 at 12:07 -0400, Charles Marcus wrote:
> On 7/9/2009, Federico Nicolelli (federico.nicole...@iscsi.it) wrote:
> >> So, does disable_plaintext_auth=yes automatically change the imap listen
> >> port to 993, or would I then nees to also set 'ssl_listen: 993' (if so,
> >> wouldn't th
On 7/9/2009, Federico Nicolelli (federico.nicole...@iscsi.it) wrote:
>> So, does disable_plaintext_auth=yes automatically change the imap listen
>> port to 993, or would I then nees to also set 'ssl_listen: 993' (if so,
>> wouldn't that seeting be more appropriately named tls_listen? ;) ?
> No it
Charles Marcus ha scritto:
On 7/9/2009, Timo Sirainen (t...@iki.fi) wrote:
Forcing encrypted port (imaps) for everyone really doesn't add
anything in the way of overhead on modern systems, and I just don't
like the idea of unencrypted sessions, even on on 'trusted'
networks.
That's a wrong wa
On 7/9/2009, Timo Sirainen (t...@iki.fi) wrote:
>> Forcing encrypted port (imaps) for everyone really doesn't add
>> anything in the way of overhead on modern systems, and I just don't
>> like the idea of unencrypted sessions, even on on 'trusted'
>> networks.
> That's a wrong way to think about i
Timo Sirainen ha scritto:
On Jul 9, 2009, at 11:15 AM, Charles Marcus wrote:
On 7/9/2009, Federico Nicolelli (federico.nicole...@iscsi.it) wrote:
Ok, so if you set
"protocols = imap imaps"
Personally, I never enable unencrypted imap port...
Forcing encrypted port (imaps) for everyone really
Thanks for everyones help. Looks like I have a active and successful
TLS connection between clients and the IMAP server. Now to move on to
getting TLS and Postfix working...
I really appreciate everyones help!
On Jul 9, 2009, at 11:15 AM, Charles Marcus wrote:
On 7/9/2009, Federico Nicolelli (federico.nicole...@iscsi.it) wrote:
Ok, so if you set
"protocols = imap imaps"
Personally, I never enable unencrypted imap port...
Forcing encrypted port (imaps) for everyone really doesn't add
anything
in
On 7/9/2009, Federico Nicolelli (federico.nicole...@iscsi.it) wrote:
> > Forcing encrypted port (imaps) for everyone really doesn't add anything
> > in the way of overhead on modern systems, and I just don't like the idea
> > of unencrypted sessions, even on on 'trusted' networks.
> >
> Me too, but
On 7/9/2009 11:18 AM, Carlos Williams wrote:
>> Personally, I never enable unencrypted imap port...
>>
>> Forcing encrypted port (imaps) for everyone really doesn't add anything
>> in the way of overhead on modern systems, and I just don't like the idea
>> of unencrypted sessions, even on on 'trust
On 7/9/2009, Federico Nicolelli (federico.nicole...@iscsi.it) wrote:
Ok, so if you set
"protocols = imap imaps"
Personally, I never enable unencrypted imap port...
Forcing encrypted port (imaps) for everyone really doesn't add anything
in the way of overhead on modern systems, and I just don't
On Thu, Jul 9, 2009 at 11:15 AM, Charles
Marcus wrote:
> Personally, I never enable unencrypted imap port...
>
> Forcing encrypted port (imaps) for everyone really doesn't add anything
> in the way of overhead on modern systems, and I just don't like the idea
> of unencrypted sessions, even on on '
> My question now after it appears to be working, did I configure this
> properly for TLS? Users can still log into the IMAP server and get
> their mail via plain text or with the SSL certificate. Did I set the
> correct port for ssl_listen or is that for SSL only and not TLS?
I never tried it, bu
On Thu, Jul 9, 2009 at 10:51 AM, Carlos Williams wrote:
> When I edit me dovecot.conf file, I uncommented the
> following with the values you see below:
>
>> ssl_cert_file = /etc/ssl/mail.crt
>> ssl_key_file = /etc/ssl/mail.key
>> ssl_listen: 993
>> ssl_key_password: ***
>> ssl_disa
Carlos Williams ha scritto:
On Thu, Jul 9, 2009 at 10:58 AM, Federico
Nicolelli wrote:
If you want to have all protocols enabled add the following line in your
dovecot.conf
protocols = pop3 pop3s imap imaps
this will enable "normal" pop3 and imap connections too.
No we don't allow any kind o
On Thu, Jul 9, 2009 at 10:58 AM, Federico
Nicolelli wrote:
>
> If you want to have all protocols enabled add the following line in your
> dovecot.conf
>
> protocols = pop3 pop3s imap imaps
>
> this will enable "normal" pop3 and imap connections too.
No we don't allow any kind of pop3 access. It's
My question now after it appears to be working, did I configure this
properly for TLS? Users can still log into the IMAP server and get
their mail via plain text or with the SSL certificate. Did I set the
correct port for ssl_listen or is that for SSL only and not TLS?
Comments / Suggestions?
On Tue, Jun 30, 2009 at 11:02 AM, Steffen
Kaiser wrote:
> We do not use Verisign, so I don't know. However, OpenSSL uses PEM-format as
> does Apache. So I'd guess "Apache" is OK.
>
> Maybe, you find infos regarding PEM format on Verisign pages.
I am downloading my SSL certificate from Verisign.com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 30 Jun 2009, Carlos Williams wrote:
So I have OpenSSL installed. I am creating the SSL certificate to use
for my mail server via
TLS. When I am on Verisign's website, they ask for "Server Platform"
and normally I would
select "Apache" but I
On Tue, Jun 30, 2009 at 10:30 AM, Steffen
Kaiser wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Tue, 30 Jun 2009, Carlos Williams wrote:
>
>> No I do not. I don't even have a /etc/ssl/ direcory on my mail server
>
> hmm, do you have openssl installed at all :) ?
> I had guessed tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 30 Jun 2009, Carlos Williams wrote:
No I do not. I don't even have a /etc/ssl/ direcory on my mail server
hmm, do you have openssl installed at all :) ?
I had guessed that any openssl package comes with at least a bunch of CA
certs.
Bye
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 29 Jun 2009, Carlos Williams wrote:
When TLS occurs and my SSL certificate is used, I am assuming that I
need to add the SSL certificate somewhere in my /etc/dovecot.conf,
correct?
Yes
Secondly, as it stands right now. When someone tries
Thanks everyone who contributed to this message. I am going to use TLS
on my Postfix / Dovecot server and just hope for the best. Now if I
use TLS, is this configured in my Postfix config files or Dovecot
config files?
When TLS occurs and my SSL certificate is used, I am assuming that I
need to add
Michael Orlitzky schrieb:
Timo Sirainen wrote:
On Fri, 2009-06-26 at 23:39 +0400, Proskurin Kirill wrote:
SSL just binds to special port(like 993 in IMAP by default).
No, SSL is a protocol, just like TLS. It doesn't bind to any ports.
http://wiki.dovecot.org/SSL
To illustrate, both SSL a
Timo Sirainen a écrit :
On Sat, 2009-06-27 at 20:06 +0200, Jean-Noel Chardron wrote:
This is the protocol: the server announces its capability but can not
force the use of TLS which is an initiative of the client.
Server can't force clients to do STARTTLS, but it can prevent clients
fr
On Sat, 2009-06-27 at 20:06 +0200, Jean-Noel Chardron wrote:
> This is the protocol: the server announces its capability but can not
> force the use of TLS which is an initiative of the client.
Server can't force clients to do STARTTLS, but it can prevent clients
from being able to log in without
Carlos Williams a écrit :
On Fri, Jun 26, 2009 at 5:46 PM, Michael Orlitzky wrote:
A typical "TLS" session will work as follows:
1 The client connects to the IMAP service on port 143, unencrypted.
2 The server announces that it speaks TLS.
3 The client says "Ok, let's talk encrypted."
4
Carlos Williams wrote:
On Fri, Jun 26, 2009 at 5:46 PM, Michael Orlitzky wrote:
A typical "TLS" session will work as follows:
1 The client connects to the IMAP service on port 143, unencrypted.
2 The server announces that it speaks TLS.
3 The client says "Ok, let's talk encrypted."
4 Magic
On Fri, Jun 26, 2009 at 5:46 PM, Michael Orlitzky wrote:
> A typical "TLS" session will work as follows:
>
> 1 The client connects to the IMAP service on port 143, unencrypted.
> 2 The server announces that it speaks TLS.
> 3 The client says "Ok, let's talk encrypted."
> 4 Magic occurs, and the
Timo Sirainen wrote:
On Fri, 2009-06-26 at 23:39 +0400, Proskurin Kirill wrote:
SSL just binds to special port(like 993 in IMAP by default).
No, SSL is a protocol, just like TLS. It doesn't bind to any ports.
http://wiki.dovecot.org/SSL
To illustrate, both SSL and TLS as implemented in Dove
On Fri, 2009-06-26 at 23:39 +0400, Proskurin Kirill wrote:
> SSL just binds to special port(like 993 in IMAP by default).
No, SSL is a protocol, just like TLS. It doesn't bind to any ports.
http://wiki.dovecot.org/SSL
signature.asc
Description: This is a digitally signed message part
Carlos Williams пишет:
Is it talking about a actual SSL certificate or TLS?
You should read this:
http://en.wikipedia.org/wiki/Transport_Layer_Security
Your certificate is ok and will work with SSL&TLS.
SSL just binds to special port(like 993 in IMAP by default).
--
Best regards,
Proskurin Ki
On 6/26/2009 2:53 PM, Carlos Williams wrote:
> http://wiki.dovecot.org/SSL/DovecotConfiguration
>
> Is it talking about a actual SSL certificate or TLS?
>
> Thanks for any clarification!
There's no such thing as a 'TLC Certificate'... TLS uses standard SSL
certs, so just use your current one no
I am running Postfix and Dovecot on my mail server. I am required now
to have SSL/TLS on my mail server. I did check and found out that I
have a SSL certificate with Verisign issued to my mail servers FQDN.
Now my question is when reading the Dovecot Wiki, I noticed it said
that it is not common to
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
-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
completel
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 us
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
> >ca
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 s
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
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
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,
Actu
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
-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 app
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
-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,
- --
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
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 PRO
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 ha
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
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
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 b
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 doe
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
certifica
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-si
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?
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 m
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
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 wi
97 matches
Mail list logo
