FormMail script and changing MX records
July 1, 2015 3:37 PM Subscribe
I'm pretty much a newb at low level email server stuff. But I have a client who has a an old online order form made using the formmail script. Today they suddenly had to change their email provider, so their MX records changed. Now the online order form no longer works. Here's what I've tried so far to fix this...
I don't see anything in the formmail script about MX values. I've changed the name of the mail server referenced in the script, but that doesn't fix anything. Any suggestions? Is it even possible to host the formmail script on server when the mx record points to a different one? It seems to be looking for the sendmail program on a specific sever.
I don't see anything in the formmail script about MX values. I've changed the name of the mail server referenced in the script, but that doesn't fix anything. Any suggestions? Is it even possible to host the formmail script on server when the mx record points to a different one? It seems to be looking for the sendmail program on a specific sever.
Response by poster: Does the email address in the recipient input (this a hidden input in the html document that posts to this form that specifies the email address that the order should be sent to) still actually receive email in general?
This has changed and I've confirmed that the new email is working properly i.e. you can send and receive email from it.
What happens when you submit the form? Does a server error pop up or does it just act like everything worked but you never receive the order?
It proceeds like everything is ok.
posted by Brandon Blatcher at 3:57 PM on July 1, 2015
This has changed and I've confirmed that the new email is working properly i.e. you can send and receive email from it.
What happens when you submit the form? Does a server error pop up or does it just act like everything worked but you never receive the order?
It proceeds like everything is ok.
posted by Brandon Blatcher at 3:57 PM on July 1, 2015
If the email address has changed, it is quite possible that the new email provider refuses to receive messages from a server not associated with that host name. For example your new domain might now have an SPF record which then doesn't match your server.
Can you try changing your recipient email address to other addresses on other domains to see if any of them go through?
Do you have access to the out going mail logs on the server from which the formmail script is being served? Can you run sendmail from the command line on the server to see if that can still send messages to your new address?
posted by NormieP at 4:08 PM on July 1, 2015
Can you try changing your recipient email address to other addresses on other domains to see if any of them go through?
Do you have access to the out going mail logs on the server from which the formmail script is being served? Can you run sendmail from the command line on the server to see if that can still send messages to your new address?
posted by NormieP at 4:08 PM on July 1, 2015
Response by poster: Can you try changing your recipient email address to other addresses on other domains to see if any of them go through?
Did that, none seem to be going through.
Do you have access to the out going mail logs on the server from which the formmail script is being served?
I have root access to the server, no idea where to look though.
Can you run sendmail from the command line on the server to see if that can still send messages to your new address?
No idea how to do this one, sorry!
posted by Brandon Blatcher at 4:25 PM on July 1, 2015
Did that, none seem to be going through.
Do you have access to the out going mail logs on the server from which the formmail script is being served?
I have root access to the server, no idea where to look though.
Can you run sendmail from the command line on the server to see if that can still send messages to your new address?
No idea how to do this one, sorry!
posted by Brandon Blatcher at 4:25 PM on July 1, 2015
Response by poster: For example your new domain might now have an SPF record which then doesn't match your server.
To be clear, this isn't a new domain, just a new MX record.
posted by Brandon Blatcher at 4:50 PM on July 1, 2015
To be clear, this isn't a new domain, just a new MX record.
posted by Brandon Blatcher at 4:50 PM on July 1, 2015
Whoa. Man, this script is taking me waaaay back.
Okay, so formmail pipes text into whatever local mail program you have configured. That means it uses the local MTA (postfix, qmail, sendmail, etc). That MTA is what looks up the MX record in order to route the email. The MTA may be dropping the mail for some reason. How to determine that depends one which you use. jquinby's question is a first start to answering that, but you'll probably need more info.
Assuming the MTA is attempting to send the email on, what's the FROM: address? The destination SMTP server might be refusing delivery (or quarantining, or marking as spam, etc) for a number of reasons, one of which may be the FROM: address not matching the originating host. For example, if smtp.example.com is trying to send email from formmail@oldhost.invalid, but oldhost.invalid's MX record points to google.com, your new email provider may say "nope". That requires a proper MX record and/or DKIM setup to fix.
posted by TheNewWazoo at 5:30 PM on July 1, 2015
Okay, so formmail pipes text into whatever local mail program you have configured. That means it uses the local MTA (postfix, qmail, sendmail, etc). That MTA is what looks up the MX record in order to route the email. The MTA may be dropping the mail for some reason. How to determine that depends one which you use. jquinby's question is a first start to answering that, but you'll probably need more info.
Assuming the MTA is attempting to send the email on, what's the FROM: address? The destination SMTP server might be refusing delivery (or quarantining, or marking as spam, etc) for a number of reasons, one of which may be the FROM: address not matching the originating host. For example, if smtp.example.com is trying to send email from formmail@oldhost.invalid, but oldhost.invalid's MX record points to google.com, your new email provider may say "nope". That requires a proper MX record and/or DKIM setup to fix.
posted by TheNewWazoo at 5:30 PM on July 1, 2015
To be clear, this isn't a new domain, just a new MX record.
I'm a bit confused on this one since you said the recipient address also changed. If it was just the mx record then the email address shouldn't have changed, no?
I have root access to the server, no idea where to look though.
You can run the command mailq to see if there are any pending outgoing messages. It would also show the reason why a message was deferred. If the message was flat rejected, it might not show anything.
The logs are typically somewhere in /var/log check systlog, messages, and mail in that directory.
(All this is assuming some sort of unix/unix-like OS, which seemed reasonable since you mentioned root.)
posted by NormieP at 5:35 PM on July 1, 2015
I'm a bit confused on this one since you said the recipient address also changed. If it was just the mx record then the email address shouldn't have changed, no?
I have root access to the server, no idea where to look though.
You can run the command mailq to see if there are any pending outgoing messages. It would also show the reason why a message was deferred. If the message was flat rejected, it might not show anything.
The logs are typically somewhere in /var/log check systlog, messages, and mail in that directory.
(All this is assuming some sort of unix/unix-like OS, which seemed reasonable since you mentioned root.)
posted by NormieP at 5:35 PM on July 1, 2015
Correct. You want to run that script and look for interesting messages in wherever your MTA (postfix or sendmail) is logging. It may be possible to amp up the logging to save (and display) the actual SMTP transactions going on. If the remote MTA is dropping the message for one reason or another, it should reasonably be returning a code or message as to why.
Another way to capture what's going in (and I'll confess that I straight hustled this from postfix's troubleshooting FAQ) is via a packet capture. Start this up in a terminal window (as root):
# tcpdump -w /tmp/dump -s 0 tcp and port 25
...run a message through your script, the CTRL-C that capture and examine /tmp/dump for clues to see if mail is getting dropkicked along the way.
posted by jquinby at 6:07 PM on July 1, 2015
Another way to capture what's going in (and I'll confess that I straight hustled this from postfix's troubleshooting FAQ) is via a packet capture. Start this up in a terminal window (as root):
# tcpdump -w /tmp/dump -s 0 tcp and port 25
...run a message through your script, the CTRL-C that capture and examine /tmp/dump for clues to see if mail is getting dropkicked along the way.
posted by jquinby at 6:07 PM on July 1, 2015
Response by poster: What sort of system is the formmail script hosted on?
According to phpinfo, it's "Windows NT 211626-1 6.0 build 6002"
Assuming the MTA is attempting to send the email on, what's the FROM: address?
It was an something like "FORMORDER@domainnome.com", but that email doesn't exist at the new server (which is only hosting email), so I changed it to a email that does exist on the new server, but that didn't fix anything.
Is there a way to dig into sendmail or to see/change the email sever? I'm assuming I should use the new email server configs given by the new host.
I'm a bit confused on this one since you said the recipient address also changed. If it was just the mx record then the email address shouldn't have changed, no?
Since they were changing the email host, the client decided the form should send mail to a new address (since an employee was let go who had access to everything, so they want things changed).
The server is dedicated Windows server, which I can access from my Mac using Microsoft Remote Desktop.
posted by Brandon Blatcher at 6:08 PM on July 1, 2015
According to phpinfo, it's "Windows NT 211626-1 6.0 build 6002"
Assuming the MTA is attempting to send the email on, what's the FROM: address?
It was an something like "FORMORDER@domainnome.com", but that email doesn't exist at the new server (which is only hosting email), so I changed it to a email that does exist on the new server, but that didn't fix anything.
Is there a way to dig into sendmail or to see/change the email sever? I'm assuming I should use the new email server configs given by the new host.
I'm a bit confused on this one since you said the recipient address also changed. If it was just the mx record then the email address shouldn't have changed, no?
Since they were changing the email host, the client decided the form should send mail to a new address (since an employee was let go who had access to everything, so they want things changed).
The server is dedicated Windows server, which I can access from my Mac using Microsoft Remote Desktop.
posted by Brandon Blatcher at 6:08 PM on July 1, 2015
Response by poster: Ok, this might be real basic but there's this line "$mailprog = '/usr/lib/sendmail -i -t';"
I guess sendmail is in that folder, hopefully with config files? But I don't see that folder when connecting via Filezilla or Remote Desktop.
posted by Brandon Blatcher at 7:06 PM on July 1, 2015
I guess sendmail is in that folder, hopefully with config files? But I don't see that folder when connecting via Filezilla or Remote Desktop.
posted by Brandon Blatcher at 7:06 PM on July 1, 2015
Is it possible your sending server is on a blacklist that didn't matter because beforehand it never actually left your server? Could you have broken something when you changed the name of the mail server? If it was a local server and now it's not, you might be missing authentication information somewhere. To be clear, it was working BEFORE the MX change, and then only the MX changed and now it's not working?
posted by one4themoment at 7:27 PM on July 1, 2015
posted by one4themoment at 7:27 PM on July 1, 2015
"Windows NT 211626-1 6.0 build 6002"
oof... isn't that windows vista sp2?
Ok, this might be real basic but there's this line "$mailprog = '/usr/lib/sendmail -i -t';"
That was actually going to be the next thing I asked about, that's the program that the script is invoking to actually send the mail. There wouldn't be config files in /usr/lib. What I was going to suggest was trying to run what ever that command was from the CMD window and see what happens.
Is this machine running cygwin or something? That's a unix style path, not a windows path. It's also the default setting in the frommail distribution.
(On preview)
Yeah, this really does sound like something that wouldn't have been broken by a simple MX record change. I hadn't thought of the possibility that it was actually emailing something hosted locally on the box. Then again I wouldn't have thought this was running on windows, so I'm not doing too well with assumptions today.
Also the blacklisting sounds plausible. This is an ancient OS running a potentially dangerous web script and if it hasn't been carefully configured could easily be used for spamming.
posted by NormieP at 7:32 PM on July 1, 2015
oof... isn't that windows vista sp2?
Ok, this might be real basic but there's this line "$mailprog = '/usr/lib/sendmail -i -t';"
That was actually going to be the next thing I asked about, that's the program that the script is invoking to actually send the mail. There wouldn't be config files in /usr/lib. What I was going to suggest was trying to run what ever that command was from the CMD window and see what happens.
Is this machine running cygwin or something? That's a unix style path, not a windows path. It's also the default setting in the frommail distribution.
(On preview)
Yeah, this really does sound like something that wouldn't have been broken by a simple MX record change. I hadn't thought of the possibility that it was actually emailing something hosted locally on the box. Then again I wouldn't have thought this was running on windows, so I'm not doing too well with assumptions today.
Also the blacklisting sounds plausible. This is an ancient OS running a potentially dangerous web script and if it hasn't been carefully configured could easily be used for spamming.
posted by NormieP at 7:32 PM on July 1, 2015
You can check for blacklisting - plug the external-facing IP address of your server into this page and if it's listed anyplace, there's a good chance that's why mail is croaking. This *should* be reflected in the mail logs of your MTA, but again, you might need to turn the verbosity up on the logs to get that level of detail.
There are several other RBL lookup sites out there - you may need to check more than one.
posted by jquinby at 7:42 PM on July 1, 2015
There are several other RBL lookup sites out there - you may need to check more than one.
posted by jquinby at 7:42 PM on July 1, 2015
Response by poster: Hey, the client managed to get in touch with the developer who configured this system and they're supposed to be sending specific instructions on how to fix this.
Thanks to everyone who took the time to respond, I appreciate it.
posted by Brandon Blatcher at 10:26 AM on July 2, 2015
Thanks to everyone who took the time to respond, I appreciate it.
posted by Brandon Blatcher at 10:26 AM on July 2, 2015
Nice. Would be curious to know what the actual culprit was.
posted by jquinby at 10:36 AM on July 2, 2015
posted by jquinby at 10:36 AM on July 2, 2015
« Older Moving into a house; how to not creep myself out... | Moving and want to buy a car...but don't want to... Newer »
This thread is closed to new comments.
What happens when you submit the form? Does a server error pop up or does it just act like everything worked but you never receive the order?
posted by NormieP at 3:52 PM on July 1, 2015