Koozali.org: home of the SME Server

Sending mail via different network takes a long time.

finchwizard

Sending mail via different network takes a long time.
« on: September 21, 2004, 02:33:43 AM »
The subject pretty much says it all.

I have to networks, 192.168.0.x and 192.168.10.x

The server is on a 192.168.0.x address.

All the computers on the 192.168.10.x address take about 1 minute to connect and send mail. It sends in the end, but takes a while.

The network is added into the Local networks part of the server manager.

It's SME 6.0 as well, the Networks are separated by a Router which is properly configured as well.
Someone told me before that it was the mail server trying to perform a reverse lookup or something on the machine, and because the machine isn't on the same network as the server it has some issues.

I'm not entirely sure whether that's correct or not, but that's what some other guy said anyway.

If anyone knows how I could speed up sending mail between the other network, it would be REALLY appreciated.

Regards
Finchwizard

finchwizard

Sending mail via different network takes a long time.
« Reply #1 on: September 21, 2004, 03:03:08 AM »
It's all fixed........oh thank god.

That problem I've been trying to fix for 9months :P

Thanks to guy who posted the fix, I think it was Slang or someone.
Dude, your a champion!

Thanks again.

Offline psoren

  • *
  • 371
  • +0/-0
Sending mail via different network takes a long time.
« Reply #2 on: September 21, 2004, 03:46:00 AM »
Quote from: "finchwizard"
It's all fixed........oh thank god.

That problem I've been trying to fix for 9months :P

Thanks to guy who posted the fix, I think it was Slang or someone.
Dude, your a champion!

Thanks again.


Please post the fix here. That way other people can benefit as well.

Per

finchwizard

Sending mail via different network takes a long time.
« Reply #3 on: September 21, 2004, 03:54:26 AM »
smtpfront-qmail isn't that fussy about forward vs. reverse DNS mappings. What it wants, is a DNS reply, even a 'not found' or 'server fail' will do. We don't actually need complete reverse mappings. This is good news.

 A simple (read: HACK) fix may be as follows:

 If your PC's are on a non local network interface, and in this example it's: 192.168.2.0/24, try the following:

 1) Modify the template that creates the tinydns configuration

 cd /etc/e-smith/templates/var/service/tinydns/root/data/

 Add the following to /etc/e-smith/templates/var/service/tinydns/root/data/30nameServers just below the similar code and in appropriate position w.r.t. curly braces etc.

 #Steves test...
 $reverse = esmith::util::computeLocalNetworkReversed ("192.168.2.0", "255.255.255.0");
 $reverse =~ s/\.$//;
 $OUT .= ".$reverse\:\:127.0.0.1\n";

 2) Expand the config out to make the real config files
 /sbin/e-smith/expand-template /var/service/tinydns/root/data

 3) Compile the configuration into the DB format

 cd /var/service/tinydns/root/data.cdb
 /usr/local/bin/tinydns-data

 Check the date/time stamps of both data and data.cdb. They should match or at least be very close.

 4) Restart DNS services to force them to use the new values.

 service dnscache stop
 service tinydns stop
 service tinydns start
 service dnscache start