Hi Atul,

The second point is the solution which I use for my domain. I had primary MX
point to my QMT and secondary to Google Server. On Google I had created 1
catchall account. Now when my QMT is down all mails are redirected to Google
server. On QMT I setup fetchmail to fetch all the mails from Google server.
This solves my mail loss problem during QMT is down.

Amit

On Tue, Aug 10, 2010 at 9:18 AM, Atul Paralikar <[email protected]> wrote:

> Hi Eric,
>
> Your solution sounds good and practical. But is there a way where emails
> received by QMT are delivered during unavailability of QMT too. For eg.
>
> - Some time back our servers were hit with huge spam attack and the SMTP
> was
> pending with huge queue and that delayed the delivery of the genuine emails
> by 4-6 hrs locally. Since the emails don't reach their intended recipient
> local box, it will not be forwarded to Gmail.
>
> - The other possibility could be, QMT server might be down or unreachable
> due to various reasons like network and server failures. In this case too,
> the mails to Gmail will not be delivered.
>
> The second point I feel can be handled only by using MX records, but want
> to
> know if anyone has attempted it in any better way.
>
> - Atul Paralikar
>
> -----Original Message-----
> From: Eric Shubert [mailto:[email protected]]
> Sent: Tuesday, August 03, 2010 11:14 PM
> To: [email protected]
> Subject: [qmailtoaster] Re: Dual Delivery
>
> Kent Busbee wrote:
> > I am trying to set up dual delivery with gmail and qmail.  MX is
> > pointing to google and all messages are being copied to qmail, thus
> > emails in both places nicely.  However, messages sent from within qmail
> > (squirrelmail) to locals are not going out to the gmail MX.  How can I
> > copy those messages out (and without creating a loop)?  I tried setting
> > the google mx in smtproutes, but it does not work.
> >
> > [r...@mail control]# vim smtproutes
> > [r...@mail control]# qmailctl cdb
> > Reloaded /etc/tcprules.d/tcp.smtp
> > Reloaded /var/qmail/control/badmimetypes.cdb
> > Reloaded /var/qmail/control/badloadertypes.cdb
> > Reloaded /var/qmail/control/simversions.cdb
> > Reloaded /var/qmail/control/simcontrol.cdb
> > [r...@mail control]# qmailctl stop
> > Stopping qmail-toaster: svscan qmail logging.
> > [r...@mail control]# qmailctl start
> > Starting qmail-toaster: svscan.
> > [r...@mail control]# cat /var/qmail/control/smtproutes
> > northlakechristian.org:SPMX.L.GOOGLE.COM <http://PMX.L.GOOGLE.COM>
> > [r...@mail control]#
> >
>
> qmail-send sees that local messages are local, so it doesn't get to the
> point of checking MX (why would it?), it simply passes the messages on
> to qmail-local.
>
> I think you should point your MX to the primary mail server for the
> domain (QMT). Then configure the QMT accounts to send a copy to gmail.
> Then everything would go both places.
>
> In addition, having your MX point to gmail defeats the effectiveness of
> spamdyke.
>
> --
> -Eric 'shubes'
>
>
>
> ----------------------------------------------------------------------------
> -----
> Qmailtoaster is sponsored by Vickers Consulting Group
> (www.vickersconsulting.com)
>    Vickers Consulting Group offers Qmailtoaster support and installations.
>      If you need professional help with your setup, contact them today!
>
> ----------------------------------------------------------------------------
> -----
>     Please visit qmailtoaster.com for the latest news, updates, and
> packages.
>
>      To unsubscribe, e-mail:
> [email protected]
>     For additional commands, e-mail:
> [email protected]
>
>
>
>
>
>
> ---------------------------------------------------------------------------------
> Qmailtoaster is sponsored by Vickers Consulting Group (
> www.vickersconsulting.com)
>    Vickers Consulting Group offers Qmailtoaster support and installations.
>      If you need professional help with your setup, contact them today!
>
> ---------------------------------------------------------------------------------
>     Please visit qmailtoaster.com for the latest news, updates, and
> packages.
>
>      To unsubscribe, e-mail:
> [email protected]
>     For additional commands, e-mail:
> [email protected]
>
>
>

Reply via email to