according to /var/log/qmail/smtp/current mail is coming in, and being accepted:

@400000005101a6cf2c091fec tcpserver: pid 11677 from 24.1.2.10
@400000005101a6cf2c0923d4 tcpserver: ok 11677 tcemail2:69.1.2.25:25 
:24.1.2.10::1441
@400000005101a6d0037d41d4 CHKUSER accepted sender: from 
<[email protected]::> remote <txdomain.net:unknown:24.1.2.10> rcpt <> : 
sender accepted
@400000005101a6d0101418b4 CHKUSER accepted rcpt: from 
<[email protected]::> remote <txdomain.net:unknown:24.1.2.10> rcpt 
<[email protected]> : found existing recipient
@400000005101a6d010142084 policy_check: remote [email protected] -> local 
[email protected] (UNAUTHENTICATED SENDER)
@400000005101a6d01014246c policy_check: policy allows transmission
@400000005101a6d021a85b1c tcpserver: end 11677 status 0
@400000005101a6d021a85f04 tcpserver: status: 0/50
(IPs and email addresses changed to protect the innocent)

However, "/home/vpopmail/rxdomain.net/receiver/Maildir/new" remains empty.  
"/etc/init.d/qmail queue"  shows that the message is in the queue.
qmail doqueue does not release it.
queue_repair.py reports only permission problems (heres just one as an example):
queue/mess/22/20857181 ownership 7794:89, should be qmailq:qmail
stopping qmail, running queue_repair.py -r  fixes permissions, but restarting 
qmail and processing the queue does not deliver messages.
/var/qmail/control/spfbehavior is set to 1

Users CAN send email out without any problems...
What changed?  The server.  we moved from an old (yet up to date QMT 
installation on CentOS 4 i386) to a new CentOS 5 x86_64 installation.  This was 
a clean install, and used qtp-newmodel for the bulk of the install.  qtp-backup 
was used on the old server, then qtp-restore was used on the new server to put 
everything back.  qmail and friends where stopped during the backup and restore 
processes.  Only other thing worth noting is this machine's hostname was 
changed from mail3 to mail2.  We updated all the MX records for the hosted 
domains to point to mail2.

I've read through the mailinglist archives and looked over the other instances 
where this happened, and those solutions seem to have been fixed back in 2007 
and 2009.

Is there any other logs I should be looking at to determine what/where the 
problem is?
(Please excuse if I forgot to include some vital piece of information needed 
for troubleshooting, I always seem to forget something)
- - -   Jon

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to