Cannot Send Emails to Same Domain

Hey guys, I can't seem to send emails to users if my email originates from the same domain.

e.g. [email protected] => [email protected]

This applies to every user/domain on my server. Both forwards and POP3s are affected.

Here's what happens: when attempting to send, the email just sits in my outbox indefinitely (using Outlook 2003). Same situation in Squirrelmail... the email simply never reaches its recipient. Any ideas? I'm thinking it's a DNS issue...

FreeBSD 5.5, Exim 4.66, SpamAssassin 3.1.7, ClamAV 0.88.7

First step is to check the /var/log/exim/mainlog. Best is to tail it while attempting to send the mail.

Jeff

Ah, my bad! I forgot to include the log bit:

We had something similar happen with some of our users that were using certain local isp's. Changing the SMTP port from 25 to 587 seemed to fix (or at least bypass) the problem. I think it had to do with the IP address of the sender being in a range of IP addresses that were blocked by Spamhaus.

This may be a different problem than you are experiencing since you say it is happening with all of your users but it might be worth a shot.

roarkh said:

We had something similar happen with some of our users that were using certain local isp's. Changing the SMTP port from 25 to 587 seemed to fix (or at least bypass) the problem. I think it had to do with the IP address of the sender being in a range of IP addresses that were blocked by Spamhaus.

This may be a different problem than you are experiencing since you say it is happening with all of your users but it might be worth a shot.

Click to expand...

Interestingly, this solution seems to be working for me. Thank you!

Here's what happens to me.

I figured I'd skip the Outlook/Apple Mail BS and the variables that go alomng with a mail client an ISP etc and just use webmail.

SquirrelMail has always worked well for me until recently. Now....

When using Squirrelmail (1.4.9) trying to send email everything works just fine. Unless someone tries to send to someone else on the server. In which case it takes a long time (30-300 seconds) before it either goes or gives this error


When this happens the exim mainlog says this:


Again when mail is sent to a domain off of the server it goes right through no delay or anything. This is only from one email account on the server to another on the server.

I tried adding smtp_enforce_sync = false to exim.conf as John suggested. He pointed me to this http://help.directadmin.com/item.php?id=83

Nothing has worked so far and it doesn't always fail but it ALWAYS takes way too long to send. If I send off server it's instantaneous. If I send on the server the above happens. I haven't switched to dovecot or any upgrades to squirrelmail or exim (until this weekend in an effort to fix this).

It's very frustrating at this point to have a perfectly good working (although ugly) webmail interface go from working fine to not working at all for people to communicate with each other within a domain or to anyone else on the server. I have 285 users and 310 domains on this server... ouch...

mmx said:

Interestingly, this solution seems to be working for me. Thank you!

Click to expand...

That fix will not help your webmail at all for obvious reasons. So I'd say that you still have a problem like I do.

I was just looking around in my squirrelmail config file and am testing the following changes...

My config file is located at: /var/www/html/squirrelmail/config/config.php

Change the line with $smtpPort = 25; to $smtpPort = 587;

Change the line with $smtp_auth_mech = 'none' to $smtp_auth_mech = 'login';

I have not exhaustively tested but so far it seems that it may be helping on my server, at least with smtp delays causing Squirrelmail to timeout.

Your mileage may vary but it is very easy to change back if it does not help so you may want to give it a go.

Genius!

It works fast and flawlessly now. I guess I would have gone there next but man it's hard to dig into a config file that's been working great then all of a sudden it doesn't work.....

What changed??? Why do we have to do this now?

Thanks so much Roark I was barking up the wrong tree with exim but there must have been some change... right?

motobrandt,

When was the last time you updated anything in your exim.conf file?

Have you checked to make sure your own IP# isn't in any blocklists?

Jeff

roarkh said:

Change the line with $smtpPort = 25; to $smtpPort = 587;

Change the line with $smtp_auth_mech = 'none' to $smtp_auth_mech = 'login';

Click to expand...

The RBL delay does seem like it would explain it. The question now is, show the above be set as default, or should it simply be added to the knowledgebase for a case-by-case fix?

587 should be enabled for all new exim.conf, but we cannot gurantee it's there for older ones.

Comments welcome.

John

If anyone's still using those old exim.conf files, they shouldn't be .

Forcing 587 connections would force them to update; wouldn't it .

I'd like to see it as the default. But I'm not the only person here. More comments?

Jeff

I think that if "forcing" people to make this change will save some of them the trouble we've been experiencing then it's a good idea. It seems to me that getting used to using port 587 for all authenticated SMTP transactions is just good practice now.

I also think that setting the default smtp port in webmail to 587 is the appropriate thing to do at this stage. I don't see how it can be a bad thing. And it clearly is a good thing.

While switching to port 587 seemed to fix some of the slowdown problems I was having I still wanted to determine why sending mail on port 25 was taking so long. It seemed to me that it had to do with the spam lookups so I decided to try, one at a time, to comment out the different block list checks in exim.conf. It didn't take me very long to find the culprit in this ACL entry...


I commented this entry out and all of the sudden I was able to send mail out on port 25 just as quickly as ever.

An nslookup of relays.ordb.org for me returns a nonexistent domain error so I think that is what was causing the slow downs for me.

I'm wondering if anyone else is experiencing the same thing?

Well I made my last post before doing a search, after searching for ordb.org I found this thread...

http://www.directadmin.com/forum/showthread.php?t=16384

In it I see this quote by Jeff...

In the meantime, it's good to know that leaving ORDB in won't break anything, though it could slow down incoming email about two seconds waiting for a timeout. Note that doing so will not place an appreciable load on your mail server; I've been watching my main server for over 24 hours now.

Click to expand...

At least for me it looks like it is more of a problem than first thought.

I've also had the same frustrating local delivery problems over the last 2 weeks.

In Squirrelmail: 554 Synchronization error
And with mail clients, very long SMTP delays.

I don't know why it pertains to only mail sent to addresses on the server but hey I really didn't take time to review it once I found the solution.

All you need is to comment out the relays.ordb.org line in the code shown above. I went through all the port 587 stuff and once I got it working right I put everything back except for the relays.ordb.org line. Everything is now great.

Thanks for all the discussions that led me through the maze!

DirectAdmin Support said:

587 should be enabled for all new exim.conf, but we cannot guarantee it's there for older ones.

Click to expand...

How does one know if they have an old exim.conf? If it turns out I have an old version, how to I obtain a newer one?

Every now and then I will see talk about the DirectAdmin people putting up new versions of a file, but no where is it explained how to actually get these files.

You can tell what version of the file you are using by looking at the comments at the top of the /etc/exim.conf file.

For example mine is...


This thread includes download links for new versions...

http://www.directadmin.com/forum/showthread.php?t=3145&highlight=spamblocker

Hey,

You can find the files DA uses here as well:

http://files.directadmin.com/services

David