Welcome to WebmasterWorld Guest from 184.108.40.206
Forum Moderators: bakedjake
For some reason, when I send an email through my server or if an email is sent to a domain on my server, there is a 10-30 minute lag time.
I have ran MANY tests and the odd thing is when I view the email headers - it shows the email was received within a fraction of a second of when it was sent (many tests show this).
I have a theory as to what is going on.. but not sure exactly how to confirm/locate/check.
About 2 weeks ago my hosting company found out they setup my dedicated server w/out the RAID I specified - so they needed to setup a new server for me. Orginally they wanted to just setup the new server and have me reinstall my software, set things up, etc. But I told them that was not acceptable... so what they ended up doing is creating the new server and then doing an rsync from old to new - so the new server would have all the files from the old server.
Now, to do this they had to add an extra nic card to the new server (with a couple new ip addresses) this way I could keep my ip addresses and they could perform the rsync (after the transfer they removed the extra nic card).
Anyway, my problem started to happen around this time. (I wasn't aware of it until recently when I was on the phone with someone and sent an email to them... but they didn't get it for over 30minutes).
I'm wondering if the server is trying to resolve a domain/ip and is having a heck of a time... which could possibly cause the lag time.... cause according the email headers... the server receives the email a split second after it is sent.
I never had a problem until we were switched to the new server.
Anyone have a clue as to what the problme might be.. or what I could check?
This issue is only happening with email on the server. All the domains on the server respond just fine.
1) IPv6. This is the first one that pops into mind. Sendmail will not work nicely if your system has IPv6, but the systems it's trying to send to don't have AAAA records.
2) DNS. When you do a DNS lookup on a host, does it take forever? "dig MX domain.com".
3) All the config files may have not have been copied over from the old system to the new. If the old one is still around, get them to verify that they got everything.
4) Check the delay times. There are various settings that MTAs will use to calculate how long they should delay an email for, including CPU usage, and static queue delay times.
This is also not something that *you* should be having to check. Ideally you're not the one that's administering the whole machine, but them. I'd call them and tell them what's going on.
qmail has a few surprises, and I've seen exactly this situation...the other details (rsync) support the thesis, so:
Check /var/qmail/queue/lock/trigger . It should look like this:
stella# ls -l /var/qmail/queue/lock/trigger
prw--w--w- 1 qmails qmail 0 Dec 17 21:56 /var/qmail/queue/lock/trigger
The first character "p" in the `ls -l` output means that the file is a named pipe (also called a "FIFO"). If it's a regular file ("-"), doesn't exist, or if the ownership/permissions are wrong, qmail-send won't get an immediate notification when new messages are added to the queue, and it won't process them until it hits its scheduled wake-up time, typically every 30 minutes.
It's easy to fix:
chown qmails:qmail /var/qmail/queue/lock/trigger
chmod 622 /var/qmail/queue/lock/trigger
So, it was caused by them moving me to the new dedicated with RSYNC.
If I need to create a new thread I will, but I have 1 other issue that is somewhat related. At the same time as the move - I can no longer check pop3 email from Outlook. [IMAP works fine] - For some reason it is unable to authenticate - but if I check the account through webmail or set the account up in Outlook with IMAP - it works fine. Any clues on this one as well?
Again, I really appreciate your help! The slow delivery of mail was the top priority for me.