.pl & .php not working properly after patching

[ladyoclass1]

The CGI forum suggested I post to this forum so here is my problem...

I know very little about what is necessary to run .php &.pl files but I know it was working until this last weekend when I installed a bunch of Microsoft security patches. After the patches were installation, none of the websites I host will send the mail from their web mail scripts. There are no errors and in fact, I get the thank you page that follows. The only thing is that I never receive the web form email. It seems as though it is never mailed.

I also found that a lot of permissions were suddenly missing on a number of servers that has patches applied so I am assuming this is a permissions issue.

There is nothing in the event viewer and in the IIS logs; the only thing is each line ends with a 200, 404 or 304 at the end of the line with the page request on it.

What kind of permissions do I need to have this function or what can be missing that would keep the scripts. Is there anything I can do to find out why it isn’t sending the form information?

Each site that needs to use this web mail function has a virtual directory of cgi-bin in their home directory and that points to the cgi-bin under

http://wwwroot.

Any help would be greatly appreciated

 

[tfg13]

What patches were applied? Was there any type of php fix applied as well?

 

[ladyoclass1]

This particular server runs Windows 2003 and I'm not sure if it ever had a patch applied. I started this position to too long ago and am trying to secure the systems so all critical Microsoft patches were applied. Nothing specifically related to php.

Also, as I am digging further into this, all mail sent from the cgi-bin end up in the directory specified in the script and are just not being sent out.

There are other php files on the server and they are working.

Thank you for your response.

 

[tfg13]

Sounds almost as if you have a problem with SMTP. Does this apply?

http://msdn2.microsoft.com/en-us/library/8b83ac7t(VS.80).aspx

If needed, uninstall SMTP, then reinstall.....

 

[ladyoclass1]

No...SMTP isn't installed on this server.

What happens is from an internet web form, someone fills it out and when they hit submit, the form lands in a temp directory (specified by the web form) and then accesses /cgi-bin/formmail.pl and that sends the information from the form to the email address specified in the form. The files with the form information is just sitting in the temp directory and not being “sent”.

Any ideas why these files aren’t being sent? This all worked last week so I know the scripts are ok.

 

[tfg13]

How is the mail sent out? Through which protocol? Servers/PC's just don't "send" out mail, they need a way to do so. If anything, there should be an indication within the .pl that tells you how it is sent out. Have there been any network changes recently (routers/firewalls reconfigured)?

 

[ladyoclass1]

The $mailprog in the script is blat.exe I'm wondering how that could be messed up from updates but I think that is where I will concentrate my troubleshooting today.

 

[tfg13]

From:

http://www.blat.net/?docs/readme.txt

Blat is a Public Domain (generous aren't we?) Win32 console utility that sends the contents of a file in an e-mail message using the SMTP protocol. Blat is useful for creating scripts where mail has to be sent automatically (CGI, backups, etc.) To use Blat you must have access to a SMTP server via TCP-IP.

I would start looking at what has happened to the SMTP server. Where was it initially (if on the web server itself, what happened to the service). A reinstall of Blat.exe may very well be required, but you will still need to know what SMTP server you are connecting to.

 

[ladyoclass1]

Thank you very much. I will investigate that now.

 

[tfg13]

This page:

http://www.blat.net/syntax/syntax.html

has some interesting bits in it. If the .pl script uses blat, it may contain the SMTP server it is going to. That way, you'll at least know what the server's IP is.....and then work to resolve the problem that way (ping the server, get with the network managers to find out what they did to get it to stop working, etc, etc.).