340 deferred messages stuck in the queue

[borngunners]

I was trying to create a split domain, making zimbra the primary mail server and my freebsd my secondary mail server (Though currently the only mail server). However, it did not work out well and all of a sudden the mails that was coming through my zimbra mail server to be relayed to my current server was not being relayed because either the recipient or the sender is not know. Now I am stock with all the 340 emails in my queue. I have tried to flush everything out of my server using the command line

postqueue -f

and also went to the web admin queue to flush it with no luck. Please help. Also, I will like to know what I am doing wrong for that to happen.

[ArcaneMagus]

Flushing the queue just makes the MTA attempt to process the messages again, so until the problem is fixed that wont do anything.

How did you setup zimbra? Did you use a catchall/forward all setup? Or are you using something that attempts to lookup the users in the database of the freebsd server?

[borngunners]

I have setup my zimbra server as the primary MX record and my FreeBSD server as the secondary MX. I created a relay on my zimbra server for my secondary server, but people that still reside on my secondary server were unabel to receive emails from outside. All emails coming from outside are being bounced back to the sender. And when I am being sent an email from users that still reside on the secondary server, the email does not go to my zimbra account instead it goes to my secondary server. My account is the only account that was receiving email from outside senders because it was being migrated to the zimbra box.

This is how the setup is:

-A domain my.account.com was created in the zimbra server (zimbra.my.account.com)

-borngunners@my.account.com was added to the zimbra server using the following command

zmprov ca borngunners@my.account.com mypassword

-At first I had the email flow through the secondary server my.account.com

zmprov ma borngunners@my.account.com zimbraMailTransport smtp:my.account.com:25

the MX record is being setup in the following manner
5 zimbra.my.account.com
10 my.account.com

Then I moved the user borngunners@my.account.com to zimbra completely by using the following command

zmprov ma borngunners@my.account.com zimbraMailTransport lmtp:zimbra.my.account.com:7025

What am I doing wrong in this case? Do I have to do any configuration on the secondary server to know that the primary server is zimbra.my.account.com?

Remember both ip addresses are public ip's. I disabled dns on the admin console. Was that a right thing to do? Do you think using catchall forwardall might solve the problem

Thanks

P/S
Bounce email:
This is the mail system at host cmsout02.mbox.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

<alkay@my.account.com>: host zimbra.my.account.com[192.168.100.20] said: 550
5.1.1 <alkay@my.account.com>: Recipient address rejected: my.account.com
(in reply to RCPT TO command)

[ArcaneMagus]

It sounds like you are on the right track, but you might be trying to have your account exist in two different places at once which wont work too well.
Have you taken a look at Split Domain - Zimbra :: Wiki?

From what you are describing it sounds like you have the following going on:
borngunners@my.account.com exists on both zimbra.my.account.com and my.account.com
When somebody still on the my.account.com server tries to send an email to borngunners@my.account.com it goes to the borngunners@my.account.com on my.account.com not zimbra.my.account.com because the my.account.com server doesn't know that it is supposed to forward the mail over to zimbra.my.account.com.

When mail is coming in it almost sounds like you haven't configured accounts for all your users on zimbra.my.account.com so it thinks those accounts don't exist? Every user still on my.account.com should have a user on zimbra.my.account.com that forwards to the my.account.com server.

[borngunners]

I looked at the Split Domain Wiki and did the configuration from it.
You are absolutely right with both feedback. For the first one, how do I let the my.account.com know that the user now live in zimbra.my.account.com?
The second one, I actually did not move all the users and have just done that. In this case, I don't need any catchall or forwardall, right?

[ArcaneMagus]

First: The only way that you can solve this problem is if the old mail server has the same ability that Zimbra does for setting a mail transport for each individual user. If it allows this then you can set the mail transport for borngunners@my.account.com to zimbra.my.account.com which will solve this problem... if the old mail server doesn't have this capability I don't know of a way to fix this... maybe set a forwarding address of borngunners@zimbra.my.account.com?

Second: No you shouldn't need a catch all / forward all if you did that. Make sure to set the mail transport to the old server for all the accounts that are not fully moved over yet.

[borngunners]

The old mail system is using postfix, which seems to be the same like zimbra. What should I do inthe old mail server in this case?

Do I have to do the following in postfix main.cf:

#relay_domains = zimbra.my.account.com, $mydestination

[ArcaneMagus]

Have a look at Postfix manual - transport(5)

It appears that if you put a line like

borngunners@my.account.com smtp:zimbra.my.account.com

into this transport map on the old server and ran the postmap command on that file (and if the map was enabled in the first place... which it looks like it might be?) then this would accomplish what you are looking for... It looks like this is only for Postfix 2.0 and later so do check your Postfix version.

[ArcaneMagus]

Actually it looks like that might be disabled by default. Check out Postfix Configuration Parameters for how to enable.