2 redundant mail servers
Petre Bandac
virtual users/domains
the whole point of the situation below is redundancy in case if mx1/mx2
has a hardware failure (which happened 2 weeks ago)
I want to replicate the postfix users, so an user added to mx1 will
also be found on mx2 - this can be easily made by replicating the mysql
table; however, I want to also have the _current_ maildir on both
servers, so in case one fails (physically), the user won't notice, as
he will find the inbox intact
rsync is out of the question, I have already tried
thanks,
petre
--
Login: petre Name: Petre Bandac
Directory: /home/petre Shell: /usr/local/bin/zsh
On since Tue Jul 26 10:40 (EEST) on ttyv5, idle 5:13 (messages off)
New mail received Fri Feb 25 18:30 2005 (EET)
Unread since Wed Feb 23 16:47 2005 (EET)
No Plan.
Ondrej Sury
> I have 2 postfix servers running in parallel, each one with different
> virtual users/domains
>
> the whole point of the situation below is redundancy in case if mx1/mx2
> has a hardware failure (which happened 2 weeks ago)
>
> I want to replicate the postfix users, so an user added to mx1 will
> also be found on mx2 - this can be easily made by replicating the mysql
> table; however, I want to also have the _current_ maildir on both
> servers, so in case one fails (physically), the user won't notice, as
> he will find the inbox intact
>
> rsync is out of the question, I have already tried
Well, it depends how much money you are willing to spend :-). But you
need to spend some.
Most obvious solution is using NFS+Maildirs, but then NFS is SPOF, but
this can be handled. I know that some companies do clustered NFS
solutions.
Another solution could be using Cyrus as backend and use 2.3 development
branch, where "replicated" murder can server user mailboxes from
"shared" storage.
Ondrej.
--
Ondrej Sury <ond...@sury.org>
zeroguy
Petre Bandac <pe...@kgb.ro> wrote:
> I want to replicate the postfix users, so an user added to mx1 will
> also be found on mx2 - this can be easily made by replicating the
mysql
> table; however, I want to also have the _current_ maildir on both
> servers, so in case one fails (physically), the user won't notice, as
> he will find the inbox intact
What about storing the maildirs on a network block device, such as drbd
(http://www.drbd.org/)? Works great for data redundancy between two
nodes. Just make sure you know what you're doing before you try
implementing it in production, otherwise you may lose all of your data.
-zeroguy
Magnus Bäck
Brian Coca <bc...@cheetahmail.com> wrote:
> First of all thanks for the prompt response.
>
> > If you mean DIGEST-MD5 authentication, then no. It needs the
> > plaintext password (or plaintext equivalent).
> > The methods that can use a hashed password are plain text methods,
> > like LOGIN and PLAIN.
>
> This is the conclusion I arrived at, but I just could believe it.
>
> It seems trivial to me to just compare the hash you receive from the
> client to the one in the database (whichever we select).
And if the same hash can be used over and over again, exactly
how is that any more secure than cleartext passwords?
The point of the MD5 mechanisms is that they depend on a
challenge-response scheme. The server sends some data, the
client encrypts the data with the password and sends it back.
The server uses the stored password to encrypt the data
previously sent and compares it to what it just received
from the client.
> Instead I'm forced to either keep the password as cleartext or
> transmit it as cleartext so the service can create its own MD5
> hash to do the comparison.
Indeed. Pick your poison.
[...]
--
Magnus Bäck
mag...@dsek.lth.se
Brian Coca
> It's a matematical impossibility to make DIGEST-MD5 be able to use
>hashed passwords in the server storage.
I never meant for the original MD5 to be transmitted, challange-response was
implied in my thoughts (missing from my posts though).
I didn't know that it was impossible to use a seed on the already MD5 hashed
password in the database to match it to the client's response.
> Pick your poison
Indeed I must.
You learn something new every day.
--
Brian Coca
Andreas Hasenack
> I have postfix+ldap setup and can authenticate using ssl/tls and PLAIN without
> a problem. I store the passwords as MD5 hashes in LDAP and I dont want to
> replicate them in sasldb, specially if they are stored as plain text.
> SASL does not seem to support using MD5 (cram or digest) as an SMTP auth
> method except through the use of sasldb.
Actually, the issue is how the password is stored, and not where
(sasldb, ldap, mysql, etc).
> Is there any way I can use smtp auth MD5 authentication while storing the
> passwords only in LDAP as MD5 hashes?
Brian Coca
I have postfix+ldap setup and can authenticate using ssl/tls and PLAIN without
a problem. I store the passwords as MD5 hashes in LDAP and I dont want to
replicate them in sasldb, specially if they are stored as plain text.
SASL does not seem to support using MD5 (cram or digest) as an SMTP auth
method except through the use of sasldb.
Is there any way I can use smtp auth MD5 authentication while storing the
passwords only in LDAP as MD5 hashes?
Thanks in advance
Brian C
Andreas Hasenack
> > If you mean DIGEST-MD5 authentication, then no. It needs the plaintext
> > password (or plaintext equivalent).
> > The methods that can use a hashed password are plain text methods, like
> > LOGIN and PLAIN.
>
> It seems trivial to me to just compare the hash you receive from the client to
But then the "secret" (even if just hashed) would be in clear text over the network.
DIGEST-MD5 is not that: it protects your password in the network.
> keep the password as cleartext or transmit it as cleartext so the service can
> create its own MD5 hash to do the comparison.
>
> Yes, I can use ssl/tls to secure the communication or permissions to do the
> same for the DB, but for me this defeats the purpose of using MD5 at all.
>
> Would this be a feature that can be added to postfix or is Cyrus-SASL the
> culprit?
It's a matematical impossibility to make DIGEST-MD5 be able to use
hashed passwords in the server storage. One has to choose: clear text in
the storage or in the wire.
Brian Coca
> If you mean DIGEST-MD5 authentication, then no. It needs the plaintext
> password (or plaintext equivalent).
> The methods that can use a hashed password are plain text methods, like
> LOGIN and PLAIN.
This is the conclusion I arrived at, but I just could believe it.
It seems trivial to me to just compare the hash you receive from the client to
the one in the database (whichever we select). Instead I'm forced to either
keep the password as cleartext or transmit it as cleartext so the service can
create its own MD5 hash to do the comparison.
Yes, I can use ssl/tls to secure the communication or permissions to do the
same for the DB, but for me this defeats the purpose of using MD5 at all.
Would this be a feature that can be added to postfix or is Cyrus-SASL the
culprit?
--
Brian Coca
Tony Earnshaw
[...]
> It seems trivial to me to just compare the hash you receive from the client to
> the one in the database (whichever we select). Instead I'm forced to either
> keep the password as cleartext
Has to be stored in plain text ...
> or transmit it as cleartext so the service can
> create its own MD5 hash to do the comparison.
Neither CRAM-MD5 or DIGEST-MD5 auth protocol secrets are transmitted in
plain text. Moreover, neither transmits any password over the wire.
> Yes, I can use ssl/tls to secure the communication or permissions to do the
> same for the DB, but for me this defeats the purpose of using MD5 at all.
SSL/TLS is not necessary for CRAM/DIGEST-MD5 - the password is not
transmitted over the wire.
> Would this be a feature that can be added to postfix
No.
> or is Cyrus-SASL the
> culprit?
No.
Remember, *millions* of people have gone down this road before you,
don't try to reinvent the wheel, you'll end up with square tyres ;)
--Tonni
--
mail: to...@billy.demon.nl
http://www.billy.demon.nl
Devdas Bhagat
>
> > It's a matematical impossibility to make DIGEST-MD5 be able to use
> >hashed passwords in the server storage.
> I never meant for the original MD5 to be transmitted, challange-response was
> implied in my thoughts (missing from my posts though).
> I didn't know that it was impossible to use a seed on the already MD5 hashed
> password in the database to match it to the client's response.
>
you have a shared secret and encrypt on the wire, or you have an
encrypted password and send the plaintext over the network.
This problem was neatly solved by Diffie-Hellman. Welcome to the brave
new world of TLS, certificates and self signed CAs.
Devdas Bhagat
Brian Coca
> new world of TLS, certificates and self signed CAs.
policy to not store clear text passwords, it is policy not to send cleartext
passwords (LOGIN, PLAIN) even over ssl.
If I had my way everyone would have a 16 char (4 char cases) passphrase
protected certificate I issue and revoke at will.
(item number 132 after I take over the world and rule with an iron fist) ;-)
--
Brian Coca
Andreas Hasenack
> > neatly solved by Diffie-Hellman. Welcome to the brave
> > new world of TLS, certificates and self signed CAs.
> And I wish I could use them. My problem, like most, stems from policy. It is
> policy to not store clear text passwords, it is policy not to send cleartext
> passwords (LOGIN, PLAIN) even over ssl.
You could try gssapi.
Devdas Bhagat
Run your own CA, issue your certificates and use certificates for
authentication. No passwords anywhere.
Alternatively, require that all external users VPN in and add the IP
range of the VPNed hosts to mynetworks.
Devdas Bhagat
Brian Coca
> Run your own CA, issue your certificates and use certificates for
> authentication. No passwords anywhere.
> Alternatively, require that all external users VPN in and add the IP
> range of the VPNed hosts to mynetworks.
Policy is why original request was flawed, it is opposed to reality.
Its hard to balance policy, security, functionality and ease of use.
(my sanity does not make it into this list)
Yes, you already know this, I'm just ranting.
--
Brian Coca