CC’s and Forwarding Issues

I’ve released version 16 of FormSpammerTrap (FST) earlier this month. So I had to spend some time installing it on my 30 web sites. (I’m a firm believer in ‘eating your own dog food’ – using tools that I’ve written on my other web sites.) All the contact forms on my site use FST. I’m upgrading all sites to use the latest version.

While upgrading and testing, I found that the contact forms on some sites not working. And have spent the last two weeks trying to figure it out. There’s been changes to site MX records and other domain settings. Lots of testing the domain mail configuration on various testing sites. And lots of test pages and test contact pages.

As background to what I found – all of my sites have an ‘admin’ email address on that domain set up on the hosting place. And all of them have a forwarder for that admin email to forward the email to my personal account. That makes it easier to read contact emails from the 30 sites.

So when you fill out the contact form on an FST-enabled site, the email is sent to the domain’s ‘admin’ account. And that email then gets forwarded to my personal account. That’s great – when it works.

But it stopped working. Well, sometimes it worked, and sometimes test emails worked, and sometimes they didn’t. That’s been my last two weeks of efforts – among all my other projects. It was difficult to find a commonality in all sites that would indicate a solution.

So, after careful configurations and testings, I finally figured it out.

It turns out that some email clients (I use gmail) will not always forward a message properly. The gmail guys will get the message, but it will never appear in the inbox. Or the spam, or the promotions folder, or anywhere. It just gets thrown in the ‘bit bucket’.

And that was caused by my contact forms setting up a “CC” value of my personal gmail address. The email was being sent twice to the gmail account. And gmail was throwing it away – without any trace.

So the cause was:

  • If you set up a CC value in your FST form,
  • and the mail is sent to a user on your domain (which FST requires, or there is a whole other set of problems),
  • and you have a forwarding rule on your domain email to forward to an external (not your domain) email address
  • and your personal account is on gmail,
  • then the email will not be delivered. There will be no trace of it on your gmail account.

The fix is:

  • don’t have a forwarding rule, but include the CC value in your FST contact form to get it to your non-domain email account, or
  • have a forwarding rule to your personal gmail account, but don’t specify a CC email address in your FST form

Don’t do both. Or you will spend a couple of weeks trying to figure it out.

If you have followed those two rules, the forwarded emails will get received in your non-domain mail account. In my case, they also sometimes got into the spam folder on my gmail account, so I had to set up filter rules to not do that. And I still get the ‘looks like spam’ alert when reading the email, so I have to mark it as ‘not spam’, but at least I see the email in my personal gmail account. And I sometimes have to look in the ‘promotions’ folder (and the spam folder) to see if there is still an issue.

But removing the CC value from the FST contact form seems to have fixed most problems. (Although there were some changes I had to make to the MX and TXT records on several of the 30 domains on that hosting account – which is a bit geeky, so contact your hosting support to help with that.)

And that’s why the current version of FST is now version 16.10. It has notes configuration docs to alert you to potential problems if you specify the CC value in your contact form. You’ll get version 16.10 if request it via the FST contact form.

Check out the change log on the FST site for all of the new features in the past three versions. Lots of new stuff to help you get FST to work on your site.

 

Changing Language on the FST Form

FST Version 14 introduced the feature of allowing alternate language messages on the form. This is done with an array called $FST_LANG_TEXT. Just like other FST settings, you can re-define this setting according to your needs. For instance, you could create an alternate form in Spanish for your Spanish-reading visitors.

The $FST_LANG_TEXT setting is a two-dimensional array. Here’s one element of the array – you can see all of them on this page. (The contents of that page- the various text strings used in your form – are taken directly from the FST functions file where the default English language values are defined.

Here’s one element of that array: Continue reading →