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
If you are going to run a self-signed cert, there is a config
file option to have it not verify the certificate. It is probably
trying to verify the certificate chain.
A debug connection would probably verify that.
We use internally-generated certs from our own CA but
they are NOT self-signed. I provide the location of our
site's CA.cert file and that takes care of that.
Hi,
I have gotten POP3-->POP3 pass-through proxy working. However, my ultimate
goal is to get POP3-->POP3-SSL working. I would assume that I need a
certificate to get it to work, but have seen very little in the way of
documentation.
Basically right now I get: Dec 19 10:07:26 CentOS45 perdition[3852]:
perdition[3852]: Fatal error negotiating setup. Exiting child.
Can anyone point me in the right direction?
Thanks Vincent & Nathan for your quick replies.
The bit I was missing was that even when you specify ssl_listen, you
need to specify the real server port as 143. I tcpdumped headers from
the perdition box to the back-end server, and when I saw it going to
port 993, I assumed it was still trying SSL to the back-end server when
I had specified ssl_listen.
On Vincent's comment that ssl on the backend shouldn't really matter, I
agree- this isn't the 90s, and I've got very beefy hardware. On the
other hand, the servers are both on a protected subnet which no user can
plug into, so there's not even a possibility of arp-spoofing MITM
attacks.. so why waste resources which are totally unnecessary? Also,
you can then avoid the extra work of configuring & maintaining multiple
SSL certificates.
Cheers
Ross
-----Original Message-----
From: Vincent Fox [mailto:vbfox@ucdavis.edu]
Sent: Wednesday, December 12, 2007 1:28 PM
To: Ross Becker
Cc: perdition-users(a)vergenet.net
Subject: Re: [PERDITION-USERS] Perdition config question
Ross Becker wrote:
> Looking at the ssl_mode options, there doesn't appear to be a
> none_outgoing, which is what I believe I want.
>
Read the man page again.
If you specify ssl_listen only, then outoing is unencrypted by default.
We fine-grain each protcol, with 4 config files:
perdition.imap4.conf
perdition.imaps.conf
perdition.pop3.conf
perdition.pop3s.conf
Our setup is actually the reverse, we enforce all backend
connections to the server to SSL. The penalty of encryption
to backends is IMO overstated and a waste of time to pursue.
Setting up a private network to keep all your passwords from
being sniffed sniffed blah blah is a common solution, but it's
spending dollars worth of man-hours to save a few pennies.
SSL imposes at most a 20% overhead on CPU these days.
This is not the 90's unless you are trying to run 10K users on
a Pentium III you will not run out of CPU.
Vincent,
Fair enough points. In my case, I control every server, as well as
the firewall and the rest of the network, so it's not apples-to-apples.
Your point about all layers of security handy is a very good one,
though. I was looking at it from the standpoint that if I have a hacked
server, I have serious trouble anyhow, which was probably not the right
way to look at it.
Cheers
Ross
-----Original Message-----
From: Vincent Fox [mailto:vbfox@ucdavis.edu]
Sent: Wednesday, December 12, 2007 1:51 PM
To: Ross Becker
Cc: perdition-users(a)vergenet.net
Subject: Re: [PERDITION-USERS] Perdition config question
I work in the UC Davis Data Center we have about
70K users plus or minus a few hundred.
When more than a couple of systems end up getting attached
to your "private" network, at some point you will have
to do a LENGTHY investigation when some system
you didn't even know about, gets hacked and then the
security folks wonder whether 70K users could have
had their passwords sniffed. Let's not get into proper
security practice discussion, if you work in a Data Center
you know you have enough systems something will go
wrong or maybe you'll just get hit with a 0-day sploit.
Things do go wrong and I prefer to not trust anything
will take advantage of any layers of security handy.
IMO plaintext is not worth the trouble. I like the added security
of being able to say "I didn't trust the network" because
sometimes you really can't unless it's a one-man show
with a handful of systems.
If you are not using this in a big shop and do not
have these problems then by all means. I can tell you
from running Perdition in this mode, the CPU on our
4 Perdition frontends are barely ticking over at load peak
of MAYBE 0.2 during the Fall quarter rush. Our frontends
are nothing exciting really just some COTS 1U Opterons.
We use internally generated certs for Perdition to backend
mail-store and that is no big deal to set up.
It is very nice having Perdition in the front, we can migrate
users around in the backend to all kinds of mail-stores Exchange
or Cyrus or whatever, it's transparent. We just update the record
in LDAP as to what backend they are stored on.
I just wish Perdition had GSSAPI support.
Hi there- I recently found perdition and it looks like a beautiful
solution to my migration- moving users from one exchange server to
another. Unfortunately, I think the config may be missing one option
which would make perdition a full-time solution. What I'd like to do is
use unencrypted connections to the back-end server and encrypted
connections coming in.
Looking at the ssl_mode options, there doesn't appear to be a
none_outgoing, which is what I believe I want.
Could someone enlighten me and let me know if I can do this with some
different option, or if I can't do it? If it's not currently in there I
might just be motivated enough to hack it in....
--Ross