9 Feb
2009
9 Feb
'09
2:17 p.m.
Hello list,
My perdition director seems to be working fine with unencrypted POP and
IMAP connections, but logs the following when I try to connect from
Thunderbird using TLS:
Connect: 128.146.221.167->206.71.169.193
SELF: "* OK IMAP4 Ready yankee 0001de1f\r\n"
CLIENT: "1 capability\r\n"
SELF: "* CAPABILITY IMAP4 IMAP4REV1\r\n"
SELF: "1 OK CAPABILITY\r\n"
CLIENT: "2 STARTTLS\r\n"
SELF: "2 OK Begin TLS negotiation now\r\n"
username_mangle: username_strip
main: username_mangle STATE_GET_SERVER
Fatal error manipulating username for client "128.146.221.167": Exiting
child
What should I do to get TLS working?
Thanks!
--
Robert C. Sheets
Picosecond Software
10 Feb
10 Feb
12:14 a.m.
On Mon, Feb 09, 2009 at 09:17:59AM -0500, Robert C. Sheets wrote:
Hello list,
My perdition director seems to be working fine with unencrypted POP and
IMAP connections, but logs the following when I try to connect from
Thunderbird using TLS:
Connect: 128.146.221.167->206.71.169.193
SELF: "* OK IMAP4 Ready yankee 0001de1f\r\n"
CLIENT: "1 capability\r\n"
SELF: "* CAPABILITY IMAP4 IMAP4REV1\r\n"
SELF: "1 OK CAPABILITY\r\n"
CLIENT: "2 STARTTLS\r\n"
SELF: "2 OK Begin TLS negotiation now\r\n"
username_mangle: username_strip
main: username_mangle STATE_GET_SERVER
Fatal error manipulating username for client "128.146.221.167": Exiting
child
What should I do to get TLS working?
Hi Robert,
would it be possible to let me know which version of perdition
you are using, where you got it from and send a copy of your
perdition configuration file so that I can try and reproduce
this problem.
Thanks
--
Simon Horman
VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en
1:10 a.m.
Simon Horman wrote:
would it be possible to let me know which version of
perdition
you are using, where you got it from and send a copy of your
perdition configuration file so that I can try and reproduce
this problem.
I'm using perdition as distributed by Ubuntu (Hardy). The version number
of the package is 1.17.1-1build2.
Here is the output of "egrep -v '^(#|\w*$)'
/etc/perdition/perdition.conf":
map_library /usr/lib/libperditiondb_postgresql.so.0
map_library_opt
"ds0:5432:psadmin:perdition:perdition:[REDACTED]:servername:user:port"
ssl_ca_chain_file /etc/ssl/certs/mail-cacert.pem
ssl_cert_file /etc/ssl/certs/mail-cert.pem
ssl_key_file /etc/ssl/private/mail.key
Also, in case it helps, here's the log message produced by the IMAP4
server on startup, though it looks kind of like it's been truncated...
Feb 9 17:03:18 yankee perdition[2334]: version=1.17.1, add_domain="",
authenticate_in=off, bind_address="", capability="IMAP4 IMAP4REV1",
client_server_specification=off,
config_file="/etc/perdition/perdition.conf", connection_limit=0,
connection_logging=on, connect_relog=300, debug=on,
domain_delimiter="@", explicit_domain="", group="nogroup",
inetd_mode=off, listen_port="143", log_facility="mail",
login_disabled=off, lower_case="",
map_library="/usr/lib/libperditiondb_postgresql.so.0",
map_library_opt="ds0:5432:psadmin:perdition:perdition:[REDACTED]:servername:user:port",
no_bind_banner=off, no_daemon=off, no_lookup=off, nodename="yankee",
ok_line="You are so in", outgoing_port="143",
outgoing_server="",
pid_file="/var/run/perdition.imap4/perdition.imap4.pid",
protocol="IMAP4", server_resp_line=off, strip_domain="",
timeout=1800,
username="nobody", username_from_database=off, query_key="",
quiet=off,
ssl_mode="", ssl_ca_file="",
ssl_ca_path="/etc/perdition/perdition.ca/",
ssl_ca_accept_s
Feb 9 17:03:18 yankee perdition[2334]: vanessa_socket_daemon_setid:
uid=65534 euid=65534 gid=65534 egid=65534
Please let me know if I can provide anything else. Thank you!
--
Robert C. Sheets
Picosecond Software
25 Mar
25 Mar
3:05 a.m.
On 2/9/2009 8:10 PM, Robert C. Sheets wrote:
Simon Horman wrote:
Any new thoughts on this? I'm at a loss as to what to try next or where
else to go for help. Thanks!
--
Robert C. Sheets
Picosecond Software
would it be possible to let me know which version
of perdition
you are using, where you got it from and send a copy of your
perdition configuration file so that I can try and reproduce
this problem.
I'm using perdition as distributed by Ubuntu (Hardy). The version number
of the package is 1.17.1-1build2.
[snip]
13 Aug
13 Aug
4:06 a.m.
On 3/24/2009 11:05 PM, Robert C. Sheets wrote:
On 2/9/2009 8:10 PM, Robert C. Sheets wrote:
Still hoping for some help on this issue. Broken TLS support makes me
sad. Am I the only one experiencing this problem?
--
Robert C. Sheets
Picosecond Software
Simon Horman wrote:
Any new thoughts on this? I'm at a loss as to what to try next or where
else to go for help. Thanks! would it be possible to let me know which version
of perdition
you are using, where you got it from and send a copy of your
perdition configuration file so that I can try and reproduce
this problem.
I'm using perdition as distributed by Ubuntu (Hardy). The version number
of the package is 1.17.1-1build2.
[snip]
5:53 a.m.
On Thu, Aug 13, 2009 at 12:06:22AM -0400, Robert C. Sheets wrote:
On 3/24/2009 11:05 PM, Robert C. Sheets wrote:
Possibly :-(
Apologies if I have asked this before, but on which architecture
are you seeing this problem?
On 2/9/2009 8:10 PM, Robert C. Sheets wrote:
Still hoping for some help on this issue. Broken TLS support makes me
sad. Am I the only one experiencing this problem? Simon Horman wrote:
Any new thoughts on this? I'm at a loss as to what to try next or where
else to go for help. Thanks! would it be possible to let me know which version
of perdition
you are using, where you got it from and send a copy of your
perdition configuration file so that I can try and reproduce
this problem.
I'm using perdition as distributed by Ubuntu (Hardy). The version number
of the package is 1.17.1-1build2.
[snip]
8:38 a.m.
On 8/13/2009 1:53 AM, Simon Horman wrote:
Apologies if I have asked this before, but on which
architecture
are you seeing this problem?
This is on x86, in a paravirtualized Xen VM if it matters. The physical
hardware architecture is x86_64. I can try to reproduce the problem in a
64-bit VM if that would be useful, or even directly on physical hardware.
--
Robert C. Sheets
Picosecond Software
10:42 a.m.
On Thu, Aug 13, 2009 at 04:38:07AM -0400, Robert C. Sheets wrote:
On 8/13/2009 1:53 AM, Simon Horman wrote:
I think that should be enough information to work with for now.
I'll try and set up a similar environment to test the code.
Apologies if I have asked this before, but on
which architecture
are you seeing this problem?
This is on x86, in a paravirtualized Xen VM if it matters. The physical
hardware architecture is x86_64. I can try to reproduce the problem in a
64-bit VM if that would be useful, or even directly on physical hardware.
11:54 a.m.
On Thu, Aug 13, 2009 at 08:42:00PM +1000, Simon Horman wrote:
On Thu, Aug 13, 2009 at 04:38:07AM -0400, Robert C.
Sheets wrote:
Hi Robert,
I think that I have a solution :-)
The problem is twofold.
1) In order to accept STARTTLS you need to set ssl_mode=tls_listen
in the perdition configuration file.
2) There is a bug in perdition that causes it to crash
if it receives STARTTLS but ssl_mode=tls_listen has not been set.
http://bugs.debian.org/500554
On 8/13/2009 1:53 AM, Simon Horman wrote:
I think that should be enough information to work with for now.
I'll try and set up a similar environment to test the code. Apologies if I have asked this before, but on
which architecture
are you seeing this problem?
This is on x86, in a paravirtualized Xen VM if it matters. The physical
hardware architecture is x86_64. I can try to reproduce the problem in a
64-bit VM if that would be useful, or even directly on physical hardware.
10 Dec
10 Dec
11:05 p.m.
On 8/13/2009 7:54 AM, Simon Horman wrote:
On Thu, Aug 13, 2009 at 08:42:00PM +1000, Simon Horman
wrote:
Thank you, Simon. I was finally able to try this, and it works great
now. I really appreciate your help. :-)
--
Robert C. Sheets
Picosecond Software
On Thu, Aug 13, 2009 at 04:38:07AM -0400, Robert
C. Sheets wrote:
Hi Robert,
I think that I have a solution :-) On 8/13/2009 1:53 AM, Simon Horman wrote:
I think that should be enough information to work with for now.
I'll try and set up a similar environment to test the code. Apologies if I have asked this before, but on
which architecture
are you seeing this problem?
This is on x86, in a paravirtualized Xen VM if it matters. The physical
hardware architecture is x86_64. I can try to reproduce the problem in a
64-bit VM if that would be useful, or even directly on physical hardware.
11:30 p.m.
On Thu, Dec 10, 2009 at 06:05:54PM -0500, Robert C. Sheets wrote:
On 8/13/2009 7:54 AM, Simon Horman wrote:
Glad to hear that the problem is solved.
On Thu, Aug 13, 2009 at 08:42:00PM +1000, Simon
Horman wrote:
Thank you, Simon. I was finally able to try this, and it works great
now. I really appreciate your help. :-) On Thu, Aug 13, 2009 at 04:38:07AM -0400, Robert
C. Sheets wrote:
Hi Robert,
I think that I have a solution :-) On 8/13/2009 1:53 AM, Simon Horman wrote:
> Apologies if I have asked this before, but on which architecture
> are you seeing this problem?
This is on x86, in a paravirtualized Xen VM if it matters. The physical
hardware architecture is x86_64. I can try to reproduce the problem in a
64-bit VM if that would be useful, or even directly on physical hardware.
I think that should be enough information to work with for now.
I'll try and set up a similar environment to test the code.
5270
days inactive
5574
days old
10 comments
2 participants
participants (2)
-
Robert C. Sheets -
Simon Horman