Perdition-users February 2008

perdition-users@vergenet.net

1 participants
3 discussions

Zombie pop3s (and imaps?) processes in connect state

by Christian Balzer

Hello, we've been using perdition as a pop3/pop3s/imap/imaps proxy for about four years now, first with Debian Sarge package and now under Etch. And throughout this time I've seen pop3s (and from the looks of it the same happens with imaps) processes stuck in connect, like this: --- 16836 ? S 5:31 0 120 32179 2204 0.0 perdition.pop3s 28070 ? S 0:00 0 120 32311 1564 0.0 \_ perdition.pop3s: connect 7782 ? S 0:00 0 120 32311 1564 0.0 \_ perdition.pop3s: connect 24468 ? S 0:00 0 120 32311 1568 0.0 \_ perdition.pop3s: connect 14180 ? S 0:00 0 120 32311 1568 0.0 \_ perdition.pop3s: connect 13503 ? S 0:00 0 120 32311 1564 0.0 \_ perdition.pop3s: connect --- They never die off, keep the connection open, there is no traffic and the other end might be long gone. Last trace in the logs is always like this: --- Feb 5 22:05:16 pp11 perdition[7782]: Connect: hi.mi.ts.u->203.216.5.113 --- It must be something related to the SSL'ness of these service, since I'm not seeing this happening ever for imap/pop3. Alas a lot of people do use TLS with those, so it's not a generic SSL issue. Maybe the master process could kick a child handling connections in the head after "timeout" seconds in connect state? If more information is needed I can try to provide it, but note that with a rate of roughly 35 pops per second I'm a bit weary to turn on debugging. ^_- This may or may not be related to another SSL related issue, which will be for the sake of making searches in the archive more likely to find good keywords in a separate mail. Regards, Christian -- Christian Balzer Network/Systems Engineer NOC chibi(a)gol.com Global OnLine Japan/Fusion Network Services http://www.gol.com/

11 years, 9 months

updated IPv6 patches for perdition and vanessa socket lib

by Antonio Querubin

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. Antonio Querubin whois: AQ7-ARIN

15 years, 10 months

TLS/SSL client credentials support?

by Christian Balzer

Hello, this one should be a fun one for Simon, as it's a "local" issue. ;) When debugging a problem with downloads of large emails with Hidemaru mail (from the same guy that wrote the Hidemaru editor), I've learned about something that I wasn't aware of. According to the author of Hidemaru mail having "Client Credentials" enabled in their client breaks the connection immediately, same thing for the infamous Becky!. Both are using probably the same public M$ SSL code examples one ventures. Here is an example with Credentials on: --- I サーバーを検索中 - popmail.gol.com I 接続中 - 203.216.5.113 I 接続完了 R +OK POP3 Ready pp12 0001f653 S STLS R +OK Begin TLS negotiation, mate I SSL初期化中 E ホストからのデータ受信に失敗しました。エラーコード=10054 (Error in receiving data from host) --- Googling for that error code gives us for example: http://glwebmail.gordano.com/kb.htm?q=275 So it's perdition hanging up after being so rudely presented with unwanted credentials. ^_- The respective entry in the logs here is: --- Feb 5 10:59:05 pp12 perdition[25716]: Fatal error establishing TLS connection --- No biggie, as this feature can be turned off on the clients of course. I'm just wondering if it's missing code on the perdition side or if this could be fixed with some SSL config magic. Though the settings that I would expect to have an influence on this are all stating that they are only dealing with outgoing connections to the real-servers. Regards, Christian -- Christian Balzer Network/Systems Engineer NOC chibi(a)gol.com Global OnLine Japan/Fusion Network Services http://www.gol.com/

16 years, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Perdition-users February 2008