The original IPv6 patches I submitted earlier didn't build on Linux
systems. Attached are updated IPv6 patches which have been tested
successfully in inetd mode on CentOS 5. However, in daemon mode under
CentOS, sometimes the spawned process will segfault. I'm still trying to
determine whether this is due to a problem with the patch itself or the
way I've built the RPM. Both daemon mode and inetd mode under FreeBSD
seems to work reliably though so I suspect this problem is something
peculiar to Linux which I've overlooked. In any case, I'm putting these
updated patches out in the hope of getting additional data back from
anyone running perdition in daemon mode on Linux systems.
I've found a small problem in the way perdition interacts with
thunderbird to do with capabilities.
We look up our users in ldap to get their mail server, some of which
have different capabilities.
When Thunderbird connects to the perdition proxy, it sends a capability
command after connecting
and again after a starttls command but it doesn't send it after a login
The RFC says it is possible for a server to send CAPABILITY results in
the tagged OK response to a
successful LOGIN command. Is it possible to have perdition either proxy
the OK response
of the server instead of sending it's own as the server is sending the
capabilities in the OK response,
or have perdition send a CAPABILITY command to the server and create an
OK header from
I'm hoping someone can help me out here or point me in the
right direction. We've
been testing perdition for a while now to do ldap based lookups of a
users mail server and
proxy their pop/imap connections through a single service alias. Just
as we were about
to announce it and roll it our to all our users I started getting
reports of Thunderbird both
Mac and Windows versions not showing the folders for certain users.
I can't find anything for these users that's any different to the ones
that work and these users
will sometimes start working, once by deleting the .mailboxlist file and
I've had one user
who said their thunderbird stopped allowing them to subscribe to new
folders, they just don't
Connecting directly to the mail server allows the users to see all of
their mailboxes and subscribe
to them but so does using a different client via perdition.
Snooping on the connection and turning on Thunderbird's debugging I see
the following where
thunderbird seems to be sending pipes and percents instead of forward
slashes and asterisks.
36108288[17bf8150]: 276c400:imap.st-andrews.ac.uk:A:SendData: 46 list ""
36108288[17bf8150]: ReadNextLine [stream=17bf8a58 nb=22 needmore=0]
276c400:imap.st-andrews.ac.uk:A:CreateNewLineFromSocket: 46 OK LIST
36108288[17bf8150]: 276c400:imap.st-andrews.ac.uk:A:SendData: 47 list ""
The only difference I can see in responses is that going to the server
directly, the initial OK header
also contains the capabilities but I have other imap servers which don't
show capabilities in the initial
header that I've never seen thunderbird exhibit this behaviour with.
In thunderbird Account Settings -> Server Settings -> Advanced
The Imap server directory is ~/mail and "server supports folders that
contain sub-folders and messages" is unchecked
in general. Personally, I've never touched those settings and have
never had this problem with
may mail account, but I've setup one of the failing accounts in my mail
client and seen the problem
both with these variables set / unset.
I'm running cyrus imap behind perdition. Yesterday I changed the
imap_capability option of perdition to reflect what cyrus advertises.
I connected to my cyrus server over ssl and issued capability, and
copied its output into my perdition config.
The capability line had AUTH=PLAIN. Now, users using PINE couldn't login.
Perdition: IMAP DEBUG 23:41:48.977832: * CAPABILITY IMAP4 IMAP4rev1
LITERAL+ ID AUTH=PLAIN SASL-IR ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS
NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY
SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE
CATENATE IDLE URLAUTH
Client: IMAP DEBUG 23:41:49.054219: 00000000 OK CAPABILITY
Client: IMAP DEBUG 23:41:49.069100: 00000001 AUTHENTICATE PLAIN
Perdition: IMAP DEBUG 23:41:49.108864: 00000001 NO AUTHENTICATE
mechanism not supported, mate
I removed AUTH=PLAIN from the capability list that perdition advertises,
and PINE users can log in again.
I'm sure that this is a issue of me not understanding a RFC. Could
someone give me a hint what RFC?
Thanks in advance,
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Rudy Gevaert Rudy.Gevaert(a)UGent.be tel:+32 9 264 4734
Directie ICT, afd. Infrastructuur ICT Department, Infrastructure office
Groep Systemen Systems group
Universiteit Gent Ghent University
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Is it possible to connect perdition to an IMAP4 server via SSL,
while the client only uses an IMAP4 connection without encription?
I do have the ssl-pem-file available, it is a self signed key and it
is used at the moment for a stunnel-connection. I'd like to remove
At the moment the setup is like:
client (no encription) -> perdition (no encription) -> stunnel (ssl)
I'd like to have
client (no encription) -> perdition (ssl) -> imap-server (ssl-only)
Which ssl-options do I have to set to make it work?
I'm using Thunderbird to contact a perdition server with SSL/995.
It works fine until I import a certificate to sign messages.
Then I get the message "Error establishing an encrypted connection to
server.my.domain. Error Code -12195." when I try to *get* messages.
After several attempts to solve the problem, I became suspicious about
Perdition/SSL. Other servers work fine.
Is this the problem
Where should I look further ?
i resend this message. maybe anyone can help me.
i have the following Problem. I use Courier-Imap 4.0.6 and Perdition
1.17 and Openssl 0.9.8e-r3
I want to connect with TLS1. i get the following Error in my
perdition: SELF: "flim08 STARTTLSrn"
perdition: REAL: "flim08 OK Begin SSL/TLS negotiation
imapd: couriertls: connect: error:1408F10B:SSL
routines:SSL3_GET_RECORD:wrong version number
In my perdition.conf i set ssl_mode to tls_all. i set my courier to
a another port 144 and pertition works on 143.
i dont know do i have error in reasoning or do i have a problem with
when its correct so i can use Courier IMAP with port 143(for xample
144) with STARTTLS and SSL on Port 993. The problem is i have two
configurations files. One /etc/courier-imap/imapd (Port 143) and
/etc/courier-imap/imapd-ssl (Port 993). If i understand it correct so
i normally have no (TLS/SSL) on port 143 only on port 993. But courier
uses STARTTLS on port 143. I dont know maybe i have to use only
plaintext login. Maybe there should not STARTTLS on port 143.
for port 993 i used ssl_mode ssl_all and setup my ssl_ca_file and my
ssl_cert_file. its a self signed certificate from my own certificate
authority. i dont know but i should comment out
i also dont get it run with 993. do i have forgotten something?
maybe i should only use 993 with certificates but i dont see the
problem at the moment. (i set my courier for listening to port 994)
i hope anyone can give me some tips.
I understand that the default timeout is 1800s (30minutes). That seems
like a lot of time to just sit there while nothing is going on. What
values are people using in a real world environment, more like for just
pop3. I understand antivirus programs now adays act as proxy for mail and
can sometimes hang clients.
Same problem with 1.17.1 on Centos5 and Fedora 7
I think i have found the problem
this is a (little) stack overflow in option.c.
I think that this handle by recent versions of gcc with stack-protector
Here is the patch :
--- perdition/options.c.ori 2007-11-02 05:42:00.000000000 +0100
+++ perdition/options.c 2007-11-02 05:42:16.000000000 +0100
@@ -894,7 +894,7 @@
- char ssl_mode;
+ char ssl_mode;
char *ssl_mode_p = NULL;
#endif /* WITH_SSL_SUPPORT */
This is not optimal, but other parts of the code also use static buffers
Mail : laurent(a)licour.com
PGP KeyID 0xDA160AA2
FingerPrint 0920 EC01 F265 C9EA 537E 7AEE 986F 58C6 DA16 0AA2