Hello simon,
sorry for not stumbling over this earlier but my test setup has just
one server configured and I just ran into this trying a run on a
(thankfully) standby machine in the production environment.
Perdition is 1.18-2 (Debian Sid/Lenny backports).
If the LDAP URL has more than one LDAP server in it, queries fail with
this:
---
dbserver_get2: ldap_initialize: Bad parameter to an ldap routine
---
Which had me rather stumped for a while until in one iteration I reduced
things to one server. And no, version 2 or 3 make no difference. ^^
Working config line:
---
m 3:ldap://localhost/ou=mail,dc=gol,dc=com?mailLocaladdress,mailServer?one?(uid=%s)
---
Not working:
---
m 3:ldap://localhost ldap.dentaku.gol.com/ou=mail,dc=gol,dc=com?mailLocaladdress,mailServer?one?…
---
And while I know you are not really involved with the LDAP bits, do you
(or anybody else here) know how a hostname resolving to multiple IPs is
treated? I.e, pick the first IP the resolver returns and if that is dead,
this "host" is dead. Or try all IPs returned until one succeeds and if
not, next server (if configured).
Regards,
Chibi
--
Christian Balzer Network/Systems Engineer
chibi(a)gol.com Global OnLine Japan/Fusion Communications
http://www.gol.com/
Hello,
it seems the issues is related to tls/ssl session caching...
A workaround is to start perdition via inetd (though less performing).
This way each process serves only one request and then dies (emptying
tls cache). This patch worked for me.
Waiting for a clean solutions.
Bests
Giorgio
--
"Le cose belle della vita Ing. Giorgio Paolucci
o sono illegali, o sono Universita' di Padova
immorali, o fanno ingrassare" Centro di Calcolo di Ateneo
+39-049-8273711
--
Hello,
it seems the issues is related to tls/ssl session caching...
A workaround is to start perdition via inetd (though less performing).
This way each process serves only one request and then dies (emptying
tls cache). This patch worked for me.
Waiting for a clean solutions.
Bests
Giorgio
--
"Le cose belle della vita Ing. Giorgio Paolucci
o sono illegali, o sono Universita' di Padova
immorali, o fanno ingrassare" Centro di Calcolo di Ateneo
+39-049-8273711
--
Hi,
We've installed the latest version of perdition, from the mercurial
repository, on Debian Squeeze. From the source we created deb packages
and only installed the main perdition package.
With the imap and managesieve protocols activated, perdition starts up
correctly, the imap is working without problem, but with managesieve,
the following happens:
webmail1:etc/perdition# telnet localhost 2000
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
Connection closed by foreign host.
On syslog we get:
Jul 8 16:42:09 webmail1 perdition.managesieve[2302]: Connect:
127.0.0.1:40425->127.0.0.1:2000
Jul 8 16:42:09 webmail1 perdition.managesieve[2302]: Exiting on signal 11
We have the debug mode activated, but don't seem to get any more info.
Could you please help?
Thanks!
Regards,
Filipe
--
Filipe André Romualdo de Carvalho
Unidade de Administração de Sistemas (UAS)
Centro de Informática Prof. Correia de Araújo (CICA)
Faculdade de Engenharia da Universidade do Porto (FEUP)
Tlf: (+351) 22 508 15 06 - SIP/VoIP: filipec(a)fe.up.pt / Ext: 3092
Hello,
It seems there is a problem between thunderbird 3.1 and perdition even
the last one.
Here's some part of the log of a a freshly installed Squeeze with the
last version of perdition (same problem with 1.18 or with our prod
server using Lenny and 1.17).
Jul 9 14:15:51 sorbier perdition.pop3s[1988]: Starting perdition
version=1.19-rc1 protocol=POP3S
Jul 9 14:16:39 sorbier perdition.pop3s[1993]: Connect:
XXX.XX.XX.XX:49381->XXX.XX.XX.XX:995
Jul 9 14:17:06 sorbier perdition.pop3s[1993]: Auth:
XXX.XX.XX.XX:49381->XXX.XX.XX.XX:995 client-secure=ssl
authorisation_id=NONE authentication_id="hotelier"
server="xxx.supagro.inra.fr:995" protocol=POP3S server-secure=ssl
status="ok"
Jul 9 14:17:06 sorbier perdition.pop3s[1993]: Closing session:
XXX.XX.XX.XX:49381->XXX.XX.XX.XX:995 authorisation_id=NONE
authentication_id="hotelier" received=12 sent=14
Jul 9 14:17:26 sorbier perdition.pop3s[2006]: Connect:
XXX.XX.XX.XX:49387->XXX.XX.XX.XX:995
Jul 9 14:17:26 sorbier perdition.pop3s[2006]: Fatal error establishing
SSL connection to client
After the first connection nothing works, on perdition side the message
is always the same "Fatal error establishing SSL connection to client".
Thunderbird 3.1 is implementing a solution to security issue
CVE-2009-3555 as explained in this document
https://wiki.mozilla.org/Security:Renegotiation
I tried different parameters but nothing worked.
I wonder if there are some perdition parameters that may correct the
problem ?
Regards,
Thierry Hotelier
Since I'm on the subject of logging...
I notice that even if I am coming in on port 993, the port field that is
logged is the port of the outgoing connection:
Apr 4 11:19:24 auk perdition[19421]: Auth: 0.0.0.0->0.0.0.0 ---- server="0.0.0.0" port="143" status="ok"
In this case, my incoming imap connection was an imaps (993) connection
to perdition, it then looked up my user and found the server to connect
to, and then made the connection to that server over port 143. I
expected it to connect to the remote server over 143, but I was
expecting to get a log entry from perdition that the port it received
the connection on is port 993.
Is there a way to get a log entry that indicates the incoming port
number, as well as the outgoing one?
Thanks!
micah
--
"It is no measure of health to be well adjusted to a profoundly sick society." - J Krishnamurti
Recently, I switched from thunderbird 3.05 to 3.1, on linux.
After the switch, I was no more able to download
my e-mail using our pop3s server more than once;
So, I had to re-start thunderbird each time.
I filed this bug report,
https://bugzilla.mozilla.org/show_bug.cgi?id=575915
The problem was acknowledged, and if I understand correctly
(I'm not sure of this, It's better read the bug logs if you are
interested), it happens because the secure connection
encounters an error after the first authentication and mail download.
I answered some questions, and at the end asked for help
to our sysadm. It turned out that I was not accessing
directly the pop3s server. Rather, I was accessing perdition
1.17.1 (debian lenny). And thunderbird 3.1 works flawlessy accessing
our real pop3s server.
So, it can be a thunderbird a bug, but it occurs only with perdition.
I'm writing you because I've left unanswered the following questions:
>Can you check with Gmail's POP3 server using perdition 1.17.1 and Tb 3.1?
> Can you test with newer perdition 1.18 shipped on 27th November 2009
shortly?
I can't use our real server for these experiments. So, I've built
perdition 1.17.1 and perdition 1.18 on my pc (linux) (where I have
administrative rights). Both were built
The plan was to fire perdition.pop3s (not as a daemon).
Something like (for "Can you check with Gmail's POP3 server using
perdition 1.17.1 and Tb 3.1"):
./perdition.pop3s -s pop.googlemail.com -d --no_daemon
--ssl_ca_accept_self_signed -C
But I've surely done something wrong, perhaps in the generation of the
self-signed certificates: perdition 1.18 quits immediately, and
perdition 1.17.1 quits as soon as I try to download my e-mail from
thunderbird. I've not modified the installed configuration files, nor
added any database.
So, could you please confirm me that what I'm trying to do has some
sense? And if this is the case, could you write for me an idiot-proof
step-by-step instruction list, including the generation of the
certificate, so that I can help the thunderbird guy?
(even better would be to help him directly, but I can take care of it if
you don't have time).
I understand that this is asking a lot, but at this point I'm struck
with something way too different from what I know, and, having already
spent too much time with this issue, I don't currently have enough time
to understand what I should do.
Thanks a lot,
Marco
Hi,
I'm happy to announce the release of 1.19-rc1.
This includes numerous bug fixes and support for the manage sieve protocol.
As always I would like to thank those who contributed patches, bug reports,
testing and their time towards the development of perdition. In particular
I would like to thank the Université Lille 1 - Sciences et Technologies, France
for making the manage sieve work possible.
A full change log is provided by the Mercurial repository
http://hg.vergenet.net/perdition/perdition/
Perdition 1.19-rc1 and the vanessa libraries that it depends on
are available from:
http://www.vergenet.net/linux/perdition/download/1.19-rc1/
Debian unstable packages have been uploaded to Debian.Org
and should be available in the Debian archive within 24 hours.
http://packages.debian.org/source/unstable/perdition
Packages for various RPM based distributions are being built by the SUSE
build service and should be available shortly from
http://download.opensuse.org/repositories/home:/horms:/perdition/