September 5, 2008 08:18pm pdt

Member Login

Hall of Fame

Yearly

1kieran_b 89,762
2Sembee 82,300
3Chris-Dent 68,800
4tigermatt 52,243
5war1 44,975
6Richard_... 32,753
7peakpeak 31,985
8mass2612 28,650
9gupnit 28,575
10LegendZM 25,040
11grblades 22,562
12mattee76 21,800
13Network... 21,650
14cshepfam 20,900
15jar3817 20,350
16meverest 19,950
17BBRazz 19,415
18LeeDerby... 17,802
19darkstar3d 17,564
20Paka 16,421
21fgrushev... 16,350
22rakeshmig... 15,500
23uid94130 15,200
24TechSoEasy 15,000
25Sudhircha... 14,950

	[x] Attachment Details

Issues receiving mail

Zones: Simple Mail Transfer Protocol (SMTP), Networking Hardware, Email Servers

Tags: Smartertools, Smartermail, 4.3.2831, cisco, ASA5505

I am having issues with smartermail on one of my mail servers.
I can send out mail but cannot receive mail outside the network
Running smartermail 4.3.2831 on Windows server 2003 thru ASA5505
(I have run no fixup protocol smtp 25 as per http://www.experts-exchange.com/Software/Server_Software/Email_Servers/Exchange/Q_22815776.html)

access-list inbound extended permit tcp any host xxx.xxx.xxx.162 eq smtp
access-list inbound extended permit tcp any host xxx.xxx.xxx.162 eq pop3
static (inside,outside) tcp xxx.xxx.xxx.162 smtp 192.168.1.55 smtp netmask 255.255.255.255
static (inside,outside) tcp xxx.xxx.xxx.162 pop3 192.168.1.55 pop3 netmask 255.255.255.255

Outside the network:
telnet mail.domain.com 25
220************
telnet xxx.xxx.xxx.162 25
220************
telnet mail.domain.com 110
+ok pop3 server ready
telnet xxx.xxx.xxx.162 110
+ok pop3 server ready

Inside the network:
telnet mail.domain.com 25
220 domain.com
telnet xxx.xxx.xxx.162 25
220 domain.com

Nslookup returns:
Name: Mail.domain.com
Address: xxx.xxx.xxx.162
Set type=mx returns correct information as well.

And netstat shows 192.168.1.55 listening on port 25.
Any help would be great
Thanks.

Start your free trial to view this solution

[x]

The Solution Rating System

With so many solutions, how can you tell which solutions are most likely to help you and which ones are not? To provide you with a tool to use, we rate our solutions based on various elements that most accurately determine if a solution is a quality solution. To explain what factors affect the solution rating, here are the elements we take into consideration when formulating our solution rating.

The Grade of the Solution
The Zone Rank of the Expert Providing the Solution
The Number of Author and Expert Comments
The Number of Experts Contributing
The Feedback of the Community

Your Input Matters
Because of the way the system is set up, the most important variable in this equation is you. As a member of Experts Exchange, you are able to cast your vote on the quality of the solutions in regard to how complete, accurate, helpful and easy to understand each solution is. When you provide your feedback, each rating is adjusted accordingly. So, if you see a solution that has a poor rating that you think is a good solution, let us know by rating it. As you do, the rating will be adjusted and will become more accurate for other members of our site.

If you have any suggestions that you would like to make for our rating system, please ask a question in the Suggestions Zone of Community Support.

Thank you!

6.4

Question Stats

Zone: Networking

Question Asked By: ultreya

Solution Provided By: TreyH

Participating Experts: 2

Solution Grade: A

Translate:

Loading Advertisement...

Open Discussion

Comment by TreyH

The only thing I can think of would be the MX and A records were somehow hosed. The MX records have to point to an A record. They can't point to an IP address. Example:

A Records:
domain.com points to xxx.xxx.xxx.161 (web server)
mail.domain.com points to xxx.xxx.xxx.162 (mail server)
mail2.domain.com points to xxx.xxx.xxx.163 (backup mail server)

The MX records should be:
domain.com. IN MX 0 mail.domain.com.
domain.com. IN MX 30 mail2.domain.com.

So all email destined for @domain.com will first try the server at mail.domain.com and if it is down, they will go to mail2.domain.com

Also, some ISP's DNS servers will respect the TTL (time to live) that is set on the zone file by your registrar. I use register.com and they set my TTL to 540000 which equates out to a little over 6 days. If an ISP's DNS server respects the TTL entry, your MX changes will not be visible to an Email server that uses those DNS servers until the TTL expires. At the same time, an Email server that uses DNS that does not respect the TTL may see the MX changes correctly after only a short time.

The "@" symbol is a wild card. If the DNS server cannot find an matching A or CName record it defaults to the IP that the primary domain is pointing to. It's a catch all that is used to point all unrecognized sub-domains to the 'domain.com' IP address.

If your MX record was pointing to 'mail.domain.com' and you didn't have an A record for 'mail.domain.com' the email would be directed to the IP address of the "@" record.

20080723-EE-VQP-34 / EE_QW_2_20070628