Having Form submission Problems? There is an alternative

Tutorials
1

There are a number of users who appear to be having difficulties in getting their forms to work correctly. These problems are not usually Sparkle related, but are part of a wider move by hosting companies and email service providers to prevent delivery of emails they think may be spam. The way to overcome these issues is to set up your forms in Sparkle as usual, and if things don’t work out, contact your hosting company to see if they can tweak the security setting of your site to accommodate your form submissions. The problem is that many hosting companies are not particularly helpful when these issues arise, so it’s left to you to try and find a solution. You could also try using the SMTP option to send your form data through a correctly configured email account. If that fails, you could go for the ‘last-resort’ option of hosting your own script. Sparkle will accommodate this last option, but due to the vast variety of third-party scripts available, it’s difficult to offer specific details on how best to use the advanced Form Submission option.

For those who may be experiencing these problems. I’ve put together a step-by-step tutorial on using the Sparkle Advanced Form Submission option with a reliable and well tried and tested script that is free to use. You can see the tutorial at THIS LINK. If you decide to try this option and get into difficulties, please feel free to reply in this thread.

2

Although this seems a viable workaround I wonder if it isn’t introducing more things that can go wrong with your email account? This is also giving easier access to hackers if the account was to be breached.

How does it work with the latest forced domain + server authentication/authorisation layer to appease Google, Yahoo and a few others?

I know the hosting gig is a cut-throat business but it is not a good idea to go for the cheapest!
Don’t buy the free this the free that! There is no FREE and other behind-the-scenes services will be dropped to give you free!

3

Using a third-party script instead of Sparkle’s own may not complicate matters significantly, but Sparkle’s solution is generally preferred by site developers due to its pure convenience. Hence, I suggest considering a third-party script only if Sparkle’s option fails and your host is unable to resolve forwarding issues.

In many cases, data is received and processed by the script (whether Sparkle’s or third-party), but server forwarding fails for various reasons. Nowadays, web hosts are cautious about server spam, often requiring SPF, DMARC, and DKIM TXT records to authorize email sending and verify the server. Many hosts using cPanel allow domain owners to set up these records themselves, along with addressing Google’s requirements.

I’ve encountered this issue with several websites where hosting support couldn’t diagnose the email forwarding problem accurately. Often, they suggest contacting the script developer for assistance, which isn’t very helpful.

In such cases, I’ve resorted to using third-party scripts, which surprisingly proved effective. While it’s a last-resort solution, it’s worth trying. Over the years, I’ve found the recommended script to work reliably across various hosts. Initially, many hosts offered it as a one-click install via cPanel, but with web development apps managing form handling directly, such options seem to have diminished.

Fortunately, the recommended script developers have kept it updated to suit most hosting servers, ensuring it’s secure and effective, with built-in spam filtering. Unlike hosts, the script can notify senders if a mail fails due to anti-spam requirements, directing them to a dedicated web page for troubleshooting the reasons why their submission failed.

Although web development software simplifies form handling, expecting them to excel in ever-changing and complex mail delivery systems might be unreasonable. Dedicated companies focusing on form handling and mail delivery are often better equipped to integrate features into their applications and scripts that help meet the requirements of hosting servers.

On the subject of hacking, very few scripts are guaranteed to be completely hack-proof - even the one deployed in Sparkle. However, in most cases a determined hacker would first have to exploit any security vulnerabilities of the server in order to gain access to the script. Even then, if a script is well written to include robust security measures, such as input validation, output encoding and common exploits such as SQL injection and cross site scripting, it becomes increasingly difficult to exploit the script.

4

What is the Tectite script doing more/better than Sparkle’s? Whatever that is, there’s no reason we couldn’t add it in Sparkle.

5

For the most part, the Sparkle script is just fine on about 85% of the domains we’ve used it on. Furthermore, there has never been any serious spam issues. Those issues that have surfaced have been a result of individual site owners leaving themselves exposed in some way, rather than the script itself.

I think the problems in those instances where the Sparkle option hasn’t worked well has had more to do with security settings established by the hosting provider - overly cautious server configurations and the like. It’s only in those instances where we’ve resorted to using the Tectite option - mainly because it was an option offered at one time by those same web hosting companies. That was a few years back when Tectite was still on version 8 (it’s now up to 10). The strange thing is that many of the web hosts stopped providing any form of scripted mail handling when they started getting worried about spam and spam gateways. We went through a period when even the Tectite script stopped working. It wasn’t until the release of version 9 that the problems seemed to go away and we were able to upgrade the scripts that were already installed. The strange thing is those same hosting companies that currently seem unable to fix the delivery problems, have the same problem when using the SMTP options provided by most scripts.

I don’t actually know what Tectite may have done when they upgraded their script to make it start working more consistently, but they certainly did something that made it more acceptable to the mail sending rules introduced in recent times. We’ve had similar issues with bulk email applications. These were once working just fine, but again they started failing as the rules became more vigorous. As a consequence, the developers of this type of software upgraded their offerings to make them more security compliant. I’ve yet to discover from any of these developers exactly what they did to make their products start working correctly again.

Maybe I should open up the script and find out what it’s doing - it’s a very well documented script, so maybe there are some clues in there somewhere. It was suggested by one of our techies that the script could be pulling some information from the server environment that makes it more acceptable to the overly cautious web hosts - who knows?