Josh's questions

I setup a MX mail server, everything works despite port 25 being blocked, I'm stumped as to why I am able to receive email with this setup, and what the consequences might be if I leave it this way. Here are the details:

• Connections to SMTP over port 25 and 587 both reliably connect over my local network.
• Connections to SMTP over port 25 are blocked from external IPs (the ISP is blocking the port).
• Connections to Submission SMTP over port 587 from external IPs are reliable.
• Emails sent from gmail, yahoo, and a few other addresses all are being delivered. I haven't found an email provider that fails to deliver mail to my MX.

So, with port 25 blocked, I am assuming other MTA servers fallback to port 587, otherwise I can't imagine how the mail is received. I know port 25 shouldn't be blocked, but so far it works. Are there mail servers that this will not work with? Where can I find more about how this is working?

-- edit

More technical detail, to validate that I'm not missing something silly. Obviously in the transcript below I've replaced my actual domain with example.com.

# DNS MX record points to the A record.
$ dig example.com MX +short
1 example.com
$ dig example.com A +short
<Public IP address>

# From a public server (not my ISP hosting the mail server)
# We see port 25 is blocked, but port 587 is open
$ telnet example.com 25
Trying <public ip>...
telnet: Unable to connect to remote host: Connection refused
# Let's try openssl
$ openssl s_client -starttls smtp -crlf -connect example.com:25
connect: Connection refused
connect:errno=111


# Again from a public server, we see port 587 is open
$ telnet example.com 587
Trying <public ip>...
Connected to example.com.
Escape character is '^]'.
220 example.com ESMTP Postfix
ehlo example.com
250-example.com
250-PIPELINING
250-SIZE 10485760
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-BINARYMIME
250 CHUNKING
quit
221 2.0.0 Bye
Connection closed by foreign host.

Here is a portion from the mail log when receiving a message from gmail:

postfix/postscreen[93152]: CONNECT from [209.85.128.49]:48953 to [192.168.0.10]:25
postfix/postscreen[93152]: PASS NEW [209.85.128.49]:48953
postfix/smtpd[93160]: connect from mail-qe0-f49.google.com[209.85.128.49]
postfix/smtpd[93160]: 7A8C31C1AA99: client=mail-qe0-f49.google.com[209.85.128.49]

The log shows that a connection was made to the local IP on port 25 (I'm not doing any port mapping, so it is port 25 on the public IP too). Seeing this leads me to hypothesize that the ISP block on port 25 only occurs when a connection is made from an IP address that is not known to be a mail server. Any other theories?

Running OSX Lion Server (10.7.4), and about once a week or so the Apple File Sharing service stops letting clients connect to its shares. On the client we will see a dialog box stating "There was a problem connecting to the server ". Browsing the server we simply no longer see the shares. The clients are also running the latest OSX (10.7.4)

In /var/log/system.log we see entries like the following:

Jun 26 08:38:22 w3 AppleFileServer[20511]: received message with invalid client_id 157

Jun 26 08:42:11 w3 AppleFileServer[20511]: received message with invalid client_id 165

Jun 26 08:42:21 w3 AppleFileServer[20511]: received message with invalid client_id 174

Where 20511 appears to be the pid, and client_id appears to be incremented with each failed attempt.

Nothing jumps out at me from /Library/Logs/AppleFileService/AppleFileService[Access|Error].log

Restarting the service fixes the problem:

serveradmin stop afp && serveradmin start afp

So I added a script to do this daily using the periodic service. But, we still encounter this problem about once a a week.

Running Apple's Lion Server (10.7.3). I am trying to get VPN clients (clients on another subnet) to see the server's Apple File share. I know that Bonjour doesn't route over a VPN or subnet, so I am adding static DNS entries.

AFP shares work, as I can connect directly to the share using afp://servername.example.com. But, Finder and CLI tools are unable to discover the share.

From my research it sounds like I can use DNS to add SRV entries to make the services discoverable. I have added PTR and SRV entries:

_afpovertcp._tcp.example.co. 10800 IN PTR servername._afpovertcp._tcp.example.com. servername._afpovertcp._tcp.example.com. 10800 IN SRV 0 0 548 servername.example.com.

There is an A record for servername.example.com.

This helps Finder discover the AFP share, but connecting using this link fails.

Using dig I can confirm the PTR and SRV entries.

dig SRV servername._afpovertcp._tcp.example.com

This finds the record, and:

host -t PTR _afpovertcp._tcp.example.com

points back to the server name.

Using dns-sd I see the first signs of problems.

dns-sd -F # successfully finds the example.com group
dns-sd -B _afpovertcp._tcp # correctly shows servername as an afp share
dns-sd -L servername _afpovertcp._tcp example.com # fails to locate anything

The dns-sd commands and dig/host behave the same locally on the server as they do through the VPN. So, am I going down the wrong path trying to add SRV records to DNS? It's showing progress, but I'm just having a hard time getting the servername to point to a physical IP address.