|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: backup system: local delivery and relay at the same time
From: Alain Spineux (aspineux
gmail.com)
Date: Tue Jul 18 2006 - 18:24:22 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Cluster is something a lot more complex than what I want.
I just want to keep a copy of all emails going through the MX backup, and
keep them in mailboxes for one or two week to let user access them during
the time the final server is fixed.
I thing what I need is a smtp-tee filter
Suppose I have two postfix instance, one identical to the final server (to
manage user and alias) on port 10025, and the one on port 25 that will relay
the mails.
The one on port 25 must filter the mail, and expect the mail back on port
10026.
The filter may have the following argument
smtp-tee --listen-on-port 10025 --relay-mail-to localhost:10026
--send-mail-copy-to localhost:10025
The return code smtp-tee will report on port 10025 must be the one it get
from localhost:10026
and if successful try to send the mail to localhost:10025 by replacing the
MAIL FROM: inside the envelope by a MAILER-DAEMON to avoid any problem
notification.
Any comment ?
Or does postfix can do that for me ?
On 7/18/06, Jorey Bump <list
joreybump.com> wrote:
>
> Jorey Bump wrote:
> > Alain Spineux wrote:
> >
> >> I would like to setup my secondary MX as a full email backup server.
> >>
> >> Each email reaching the secondary server must be queued to be sent to
> >> the primary MX BUT also be delivered into a local mailbox. These emails
> >> will be available through a webmail during the time the primary MX is
> >> unavailable (and also after). The relayed emails will reach the
> >> primary MX and be delivered localy as normal.
> >
> > Don't do this. There is a reason (actually many) why mail transport is
> > separated from mail access. Look at solutions to replicate your mail
> > store instead, or you will create a huge unfathomable mess for your
> users.
> >
> >> Something I dont have to forget: The secondary MX will be
> >> configured to never report any problems when delivering emails locally
> >> (mailbox over quota, user not found ...)
> >
> > Ugggh... And how do you expect to reconcile all of this when your
> > primary comes back up? A secondary MX is intended to be a backup for
> > SMTP, not POP/IMAP. Keep the concepts cleanly divided, even if you
> > implement them on the same machine.
>
> BTW, I understand that you're attempting to provide continued access to
> new messages, not mailstore replication, but considering the complexity
> of your proposal, you're actually better off designing a system that
> provides true failover instead of the traditional backup MX
> functionality. Have multiple MX hosts that deliver to a separate
> mailstore (via LMTP, for example). Then if one MX dies, the others will
> continue to deliver messages. This way you can deal with your backup
> needs appropriate to each service, and leverage some of the reusable
> resources you already have in place (the LDAP user database, for example).
>
>
>
>
--
--
Alain Spineux
aspineux gmail com
May the sources be with you
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]