Emails disappearing for just one domain

[emmanuel]

It's a very weird situation that has me tearing my hair out.

Users on domain InternalA.com on my server complains for some reason they stopped receiving emails from senders from external domain ExternalA.com

Senders at ExternalA.com does not get any failed messages. As far as they are concerned, the mail was successfully delivered.

ExternalA.com is on the whitelist and even if I turn off SpamAssasin for the domain, it doesn't help.

I've searched through all of exim's logs(mainlog rejectlog processlog) and these emails never even show up in the logs.

The strange thing is, it doesn't happen for every single domain on my server or for every sender. Just mostly one and on the occasion another.

If I use an account [email protected] to send the email to somebody@InternalA and [email protected], InternalB gets the email, but not InternalA.

If I use an account [email protected] or [email protected] to send the email, both gets the email.

If I use [email protected] and [email protected], both gets the email.

For another sender, [email protected], InternalA gets the email but InternalB does not.

There's no log, even monitoring the log files while the mails are sent, showed no traces of the mystery emails ever coming into exim's processing.

Server IP is not on any blacklist based on an online check.

Can anybody suggest what might be wrong or where else should I be looking for clues?


Other info
=======
InternalA does use quite a bit of space, about 2+ GB for emails alone, although unlikely does Exim have problems handling this amount, including an account about 700MB in size?

Server load is pretty low, less than 0.3 at any times when these problems were observed.

Running on CentOS 5.

APF/BFD is installed via ELS but don't think that's the problem, or both would not have gotten any emails from any of the senders.

 

[nobaloney]

internala.com doesn't exist. You can't receive email if you don't exist. You may or may not be able to send emails if you don't exist. Some recipient servers care; others don't.

More information can be found here.

Jeff

 

[emmanuel]

internala.com doesn't exist. You can't receive email if you don't exist. You may or may not be able to send emails if you don't exist. Some recipient servers care; others don't.

More information can be found here.

Jeff

Thanks for that link although I still don't feel comfortable about splashing my client's domain name, especially email addresses and their customers out in public

Naturally, although all the "domains" in my post are invalid, they are actual properly working domains.

 

[nobaloney]

If they were properly working, then you wouldn't have the problem, would you?

My brain doesn't work well in hypotheticals. Perhaps someone else will respond.

Jeff

 

[emmanuel]

If they were properly working, then you wouldn't have the problem, would you?

My brain doesn't work well in hypotheticals. Perhaps someone else will respond.

Jeff

It all worked fine for months prior to this. Then suddenly this started happening without any changes to the domain or DNS information. So I don't see what difference knowing the actual domains and using placebo domains would make since I'm not having problems with the DNS as the sites are all contactable with the correct IP addresses.

Of course I may be wholly mistaken and would appreciate if you or anybody could explain the significance. Thanks

 

[bclark94]

First of all something has changed (maybe an update; does not have to be on your server). I agree customer email address should not be posted on public forums with out their consent. With real domains it would give us the ability to check the mx records and IPs against sites like spamhaus and dnsstuff. One of us could also mimic a SMTP session.

I would guess 85% of email delivery errors are DNS related. Have you confirmed that 'externalA' can send others on your box emails?

 

[emmanuel]

First of all something has changed (maybe an update; does not have to be on your server). I agree customer email address should not be posted on public forums with out their consent. With real domains it would give us the ability to check the mx records and IPs against sites like spamhaus and dnsstuff. One of us could also mimic a SMTP session.

At that point, I've checked the MX, DNS and email blacklists which all returned OK results. That's why I didn't think it would be necessary to work on the DNS/MX angle. But thanks for the clarification anyway

I would guess 85% of email delivery errors are DNS related. Have you confirmed that 'externalA' can send others on your box emails?

Thanks for this crucial question, I got externalA to try sending to other domains on my box and those didn't come through either. Basically, their mails to anything on my IP just didn't go through. So I started suspecting it's not my setup but their smtp server not liking my IP or something.

Further checking of their email headers on successfully received emails sent to other ISP/email servers led to the discovery that they are using an inhouse exchange server which relays their email through a third party SMTP server. So I asked externalA to check if this smtp server is actually sending the mails that are relayed.

Just this morning, externalA confirmed that this third party SMTP server upstream provider was causing the problem because it was misrouting the traffic after a weekend maintenance. They have no idea why it happened as yet but things appeared to be fixed.

 

[nobaloney]

Make sure you've got reverse DNS set up for the server's main IP#.

Make sure your BIND service on your server is running.

Make sure you're not firewalling off DNS access.

These are all questions that could have been answered within hours of your first post if you'd given us your information. You could have saved at least three days.

Jeff

 

[emmanuel]

I'm sorry if I've offended you by not revealing the domain names of my clients.

However, as noob as I am, I've ensured that reverse DNS works, that BIND is running and I've not firewalled DNS access. Since these would have caused many other things to fail long before this incident and these are also amongst the first things I've checked using sites like dnsstuff.com

So even if I've given the domain names, it wouldn't had helped resolved this any faster. The fault simply wasn't on my side, it's their upstream provider that screwed up their routing which previously was working and is now working again without any changes on my end.