Sendmail not pulling MX record for vtext.com
 

Where I work (ISP), we're using a monitoring server (statseeker) on FreeBSD 6.2-20070130.

The Statseeker software sends out a message to our phones on Verizon Wireless. In order to do that, it emails phonenumber@vtext.com.

Here's the sticker. If we use our main mail server as a relay, everything works beautifully. If, however, we send directly from the statseeker software, we can't send to vtext.com.

The error seems to be in DNS. The a record for vtext.com is:

The MX record is:

Here's the relevant info from the maillog file:


I've wiped out the phone numbers with "##########", and our domain with "domain.tld" for security reasons :)


I would post the sendmail config, but the other net admin changed it over to relay off of our primary mail server till we get some more research done.

We would like this server to send directly, as the mail servers are being monitored by this device. If the mail server goes down now, we won't get a notification, and that would be very frustrating :)

Let me know if more info is needed.

Thanks,

Tim

Is your statseeker setup as an actual server with MX record like your main mail server? That would probably be the issue, they might be denying due to something along those lines.

No, it doesn't have an MX record. Actually, it doesn't even have a real IP (it's on a private network attached to our proxy).

This was my first theory as well, but it doesn't hold water. If I telnet to port 25 on smtpsp.vtext.com or the IP from the statseeker, it accepts manual mail commands and delivers the message. If I telnet to vtext.com (or its IP) from statseeker or one of our mail servers, there is no response. If I send the mail (mail ##########@vtext.com) from the mail server (or another CentOS testbed that is not a mail server), the mail is accepted.

From what I can tell, this is an issue with Sendmail (or BSD) not doing a proper DNS query on vtext.com. Interestingly, it DOES send mail correctly to my account on our mail server.

Your mail server is setup differently than theirs most likely. Most ISP's and mail servers will reject mail from a unknown source. If this machine or server is sending the mails directly, it's behind on a private network, you're probably best to just relay these thru your mail server so it appears to vtext.com as a real legitimate email, not a spammer with a hacked bot with unknown sending sources.. ;)

They don't appear to be blocking it. If I telnet to the actual SMTP server (smtpsp.vtext.com), it works. It appears that statseeker. isn't sending to the MX record target, but just to "vtext.com", which is not a mail server.

Well, of course not. If they were blocking port 25, then it wouldn't be a mail server. What's most likely happening is exactly how it was described. You relay thru your own actual mail server, it accepts, it's a valid mail server with MX records, static IP, etc.

Now when you try to send the email directly from a server not recognizable to the outside world, so it can reach outside but others can't directly hit it, most likely depending on your network setup, vtext.com will see the email coming from an IP Address that isn't your MX or Mail server, has not MX record and will deny or just drop it, not delivering the message since of course, it would look like it's coming from some random IP on the internet and I don't blame them for dropping such messages.

Does that make sense? Easiest way to do this is just to have your messages filter thru your mail server or relay thru it, it works, shouldn't be a problem to me, especially if you need monitors in place to page you.. ;)

Again, the issue seems to be with sendmail on the local machine. I can send from statseeker manually, the automated process is sending to the wrong server according to DNS.

If I send to the proper server manually, it works. Following is the capture from a console session of me sending my phone an email message. The message was received.

Sendmail will use the system DNS just as if you were connecting using telnet from the machine. If you ping or telnet to smtpsp.vtext.com and see the IP it uses, there's no reason why sendmail on the same machine will use a different IP. It's not a DNS issue, it's another issue.

Personally, I think it's probably the headers that are getting attached and vtext.com mail servers are rejecting it.

Probably the process flow you are taking:

Email Message -> Sendmail -> MX Lookup -> vtext.com Mail Server -> vtext.com Mail server Checks Headers and rejects/drops

Your manual connection is working cause it works a little differently. You're specifying the info directly to probably one of many mail servers they may have. I think you're direct email straight from the statseeker using sendmail is not properly supplying header info and vtext.com rejects such things. From my experience, it is not a DNS issue, it's a configuration issue. That's why I said if you have a real Mail server setup, you should really be relaying your email thru it. I don't see that being a problem unless there's a reason it has to come directly to your phone from the server.

In your manual telnet, you display that your specifying your domain with:

helo statseeker.domain.tld

What happens if you just do a helo? I mean, I connected and used a domain that was not associated with my current IP and it allowed me to send an email to my verizon phone from a domain I have but wasn't currently on. I also did another manual connection with just helo and got the email.

Do a dig from your server and see what MX record it comes back with. If it's correct, then it's most likely how it's getting passed along and is a configuration issue, not a DNS issue.

The reason I'm so anxious to get this going is Statseeker is watching our servers, including our mail server. If the mail server goes down tonight, we won't get notifications.

In my experience, we always have a watcher watching the watcher. Cause what if the watcher goes down, you don't get any pages either and think everything is all find and dandy. Always a good idea to have two monitoring systems, one main one watching everything and another one watching the main one.

There are also other 3rd party tools to check on services. Something like redalert.com, you can use it to watch your mail server, if it doesn't respond, you'll get notified by them so you can respond quickly in hopes that nothing else is paging.. ;)