I have been using Perdition 1.19rc5 for a while, have had sporadic
about POP that I think could be Perdition.
I noticed 2.1 is out since February, is anyone using it, and can comment
I don't see any RPM for it for RHEL6/OEL6, they all seem to be the
1.19rc5 I have now.
I previously built using the source RPM. Anyone happen to have one?
new installation of perdition. I use the same file and content on my
popmap as I do on a working production server.
I see in my maillogs the following error:
Fatal Error reading authentication information from client
127.0.0.1:43557->127.0.0.1:143: Exiting child
It seems that perdition can't read my popmap file to get the redirection
to the imap server.
Can someone explain what the message is really telling me, please?
I'm trying to install perdition on a new Centos 6.5 server. I'm using
the rpms from opensuse repo mentioned on the downloads page.
Upon startup, I getting the following message:
Starting perdition services (IMAP4): dlopen of
I'm not sure where this library comes from and there aren't any
libperdition rpms that seem to provide this library.
Can anyone set me straight, please? Thanks
Hello List(s), ...
When using saslauthd for authentication with a remote imap server, in this
case perdition IMAP4, there seems to be a compatibility issue.
After LOGIN, perdition is sending the CAPABILITY tag before the OK.
saslauthd expects an OK, but receives the CAPABILITY first and then closes
saslauthd :do_auth : auth failure: [user=x(a)test.d250.hu]
[mech=rimap] [reason=[ALERT] Unexpected response from remote authentication
I was able to alter the last lines of auth_rimap.c, and hack this out, but
this should be implemented properly.
I assume, perdition behaves standard compliant within the IMAP4 protocol,
however it could send the combined "a OK [CAPABILITY ... ]" as dovecot
does. Is there a technical reason for the two separate messages? I was not
able to manipulate this behavior with configuration arguments.
saslauthd on the other hand could read the CAPABILITY tag, skip it, and
process the next tag to read an OK, and then close the connection, with the
Unexpected response error eventually.
I'm not sure which is the more standard compliant approach, but if my
assumption is correct, auth_rimap.c should be modified for increased
Thank you, ...
+36 209 753 758