Announcement

**BillS** · 25-Feb-2014, 01:51 PM

Of course it could be: The US 1&1 Dedicated Server Support Team knew nothing ot the 1&1 guys implementations in Germany?... In our case I would 100% guarantee it was nothing to do with Sellerdeck scripts or programs - absolutely 100%. I can also confirm we had no Windows updates applied in the month when we epereinced the issue - and anycase IIS 6.5 is years old...

I suspect they have hardware monitoring the individual SMTP ports and closing them down if not 'complying with the rules'...

Bill.

**PA.com** · 25-Feb-2014, 02:42 PM

Yes I agree there's nothing wrong with the Sellerdeck mail scripts, after all they worked for 9 years without a murmur, but I can only guess there may be something intrinsic in the way the software works that the Internetters mail server can't cope with since an unknown update was made.

One other, perhaps key thing about the downloads issue! While I wish I'd made more extensive notes about how my previous directory structure was set up on the Windows server, I have managed to recall that two CGI files had placed themselves in the root directory, i.e. below both the CGI bin and the website files. The files in question were ts000001.cgi and cp000001.cgi. I never placed them in the root folder myself, so Actinic 7 must have placed them there for me.

Now I notice that some testing has taken place at my site this morning (by Sellerdeck support) and these two files are amongst the only ones to have been modified, as though they are key to the downloading issue I have raised. This could perhaps explain why it worked when I tested it on the previous Windows server, as these files were already in the root despite the new version putting them in the CGI-bin. I don't know.

I was wondering if I should take them out of the CGI bin and put them in the root directory again? Does anyone know what these files do and where they should be put for what I'm trying to do. Hoping I may be on to something here...

Thanks again for everyone's time

Paul

**BillS** · 25-Feb-2014, 02:52 PM

The TS*.pl file is a 'Test Script'(to test email works!) - i don't think this should be in the Root but should be in the cgi-bin folder... However, if you allow EXEcutable access in the root folder it will run...

The CGI file I have not come across before... but again, I suspect it should be in the cgi-bin, by nature of its extension...

It is not the mail scripts that are failing it is the SMTP Server settings. You will find, if you have root access to your server, all the mails are sitting on your server (on windows it's normally somewhere under C:\inetpub folder)

If SD are investigating for you: Don't move 'recently modified files' - you could disrupt their work and make things tougher for them... ;-) Wait til they're done before you 'cleanup'...

KR

Bill.

**BillS** · 25-Feb-2014, 03:01 PM

Here: Copy this code into a file called testmail.php upload to your acatalog folder and run it from www.yourwebsite.co.uk/acatalog/testmail.php (obviously you need to be able to execute php code on your server! ;-)

Code:

<?php
	/**********************************************************************
  REVISION HISTORY
  ----------------
  02/19/2005 - John Renna - Initial Creation of script to test mail

               This Script is freely distributable from Maxsponder.com
*/
if (!isset($_POST['email']))
{
echo <<< HTML
<html><body>
  	<h2>Form To test mail</h2>
      <form id="mailform"  acceptcharset="UTF-8" action="{$_SERVER['PHP_SELF']}" method="post">
	<p>Please enter the email to,from, subject, message and click the Send button
      <table >
        <tr><td>Email to send to: <input type="text"  name="email"  size="50" maxlength="50"></td></tr>
        <tr><td>Email From: <input type="text" name="fromemail" size="50" maxlength="50"></td?</tr>
        <tr><td>Subject: <input type="text" name="subject" size="80" maxlength="80"></td?</tr>
        <tr><td>Message: <textarea name="msg">Email message here</textarea></td></tr>
<tr><td><input id="submit_trans_keys" name="submit" type="submit" class="submit" value="Send Email"></td></tr>
</table>
        </tr></body></html>
HTML;
}
else
{
        $email = $_POST['email'];
        $fromemail = $_POST['fromemail'];
        $subject = $_POST['subject'];
        $msg = $_POST['msg'];
	$headers = "From: ".$fromemail;
	mail($email, $subject, $msg,$headers);  // send out the e-mail message to 
	echo <<< HTML
  	<h2>Test Results</h2>
      	<form id="mailform">
      	<table >
        <tr><td>Mail sent to $email</td?</tr></table>
        </tr>
HTML;
} //end else

?>

This will prove/disprove the SD scripts / prove/disprove the SMTP Server settings...

kr,

Bill.

**PA.com** · 25-Feb-2014, 03:54 PM

Thanks very much Bill, that's a useful bit of code and it does actually send me a message to the address specified. I shall try and interpret what this send success means in relation to my previous smtp failures.
I don't have root access to the server as I am on shared hosting, but I am able to ftp into part of it and add .htaccess etc.

Maybe those pl scripts in the root folder are a red herring after all, it's more regarding the download link issue than the emails that I brought that up for, and the fact they were modified this morning at the testing session. I certainly won't move anything around of my own accord, I will wait for authorisation from support sometime.

Thanks
Paul

**BillS** · 25-Feb-2014, 04:11 PM

Hey, so that's good news... Doesn't give you the anwer, but a step in the right direction.. The SMTP Server settings are working OK for you...

So, it *could* be the SD scripts (but I'd be surprised!) / sounds more like your Network Settings now... (but then I'm not as expert as the SD guys (in some areas! ;-) )

kr
Bill.

**Mike Hughes** · 25-Feb-2014, 04:42 PM

The SMTP Server settings are working OK for you...

Not necessarily.

AFAIK, on a unix server the php mail function will use whatever mta has been installed and configured on the server. It doesn't necessarily meant that smtp is working for you and even if it is it doesn't tell you what the smtp settings you need to use are.

Mike

**BillS** · 25-Feb-2014, 04:48 PM

I don't do *unix* but *default settings* are *default settings* - if they work for one script they should work for all... (in whatever OS / surely?)... IMHO!

kr

Bill.

**Mike Hughes** · 25-Feb-2014, 05:26 PM

Then maybe you could explain it to me because I would find it helpful. With 1and1 I can send emails via sendmail and php mail but not smtp.

What should my smtp settings be?

Mike

**BillS** · 26-Feb-2014, 10:13 AM

Hi Mike,

I just did a quick Google on PHP Mail on Unix Servers... This topic shows you how to modify/select which Mail Server is used for PHP:

http://email.about.com/od/emailprogr...nding_Mail.htm

You could set it to use your SMTP server, test the script, then revert back to the original setting...

Bill

**malbro** · 26-Feb-2014, 11:33 AM

Originally posted by PA.com View Post

I was wondering if I should take them out of the CGI bin and put them in the root directory again? Does anyone know what these files do and where they should be put for what I'm trying to do. Hoping I may be on to something here...

Thanks again for everyone's time

Paul

.CGI files are executables so would normaly be found in the cgi-bin folder, cgi are one of the earliest types of executable files found on servers.

The root folder is generally the top level folder of a web site with all other folders below it in a hierarchy and for a Sellerdeck site it usually only contains two files .htaccess and index.html (on a linux server). However you can put executable files in any folder which has executable permissions so they can then be run from the web browser.

I notice in your earlier postings that there appears to be an acatalog folder inside the cgi-bin folder, this is also an unusual feature, and I am not sure why it is there.

**PA.com** · 26-Feb-2014, 02:43 PM

Thanks Malcolm,

Yes I was surprised to find those two cgi files in the root folder of my previous Windows server, but I'm guessing they are red herrings to the download problem

I'm not sure about that extra acatalog folder either, it was empty so I've deleted it. Still doesn't make a difference to the download failure though.

With reference to earlier posts I wondered if a line in the digdown.pl file
$sURL .= "/$sPresentationFile";
was responsible for adding that extra bit of the filename that could have been the problem.
I deleted that and uploaded again. When I put through an order, the link did actually look like ones that previous worked, but unfortunately it still took me to the 'page can't be displayed' page.

I think I might have to try and go back to Windows hosting, where the site previously worked. My download scripts look pretty much the same as the ones I was using in Actinic 7, and while it would be a different, newer, Windows server I fervently hope that there wouldn't be too much difference from the old one. But what do I know.

**BillS** · 26-Feb-2014, 03:21 PM

Hi Mike,

I just re-read your Original Post where you show a screen dump of your SMTP settings....

Just try this:

Replace LOCALHOST with www.piano-accompaniments.com

You can always put it back if it doesn't work...

KR

Bill

**BillS** · 26-Feb-2014, 03:46 PM

PS: You will probably need to 'restart' the SMTP/Web Service or reboot the machine for changes to be recognised...

**PA.com** · 26-Feb-2014, 03:58 PM

I've tried substituting localhost with all sorts of things, including authorisation from my own email address, and nothing worked. A chap from Internetters spent about half an hour on the phone with me suggesting different settings, IP addresses and so on, and he seemed astonished that nothing worked. If I haven't mentioned already I'm on shared hosting, so rebooting the mail server is not an option sadly.

As I say, for the moment the sendmail workaround is working, but if I have to move back to a Windows server to solve the download links problem, then I fully expect that to stop working as apparently Windows hosting doesn't support sendmail. Rock or a hard place stuff.

Announcement

Downloads not working, emails not being sent, desperate for help.

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment