Spam Prevention nightmares

Spam prevention has been a nightmare for all involved since even before I began CharlesWorks in 1998.

• Spammers: they are always trying to find ways around the spam protection.
• Email users: It is a constant battle trying to sort spam from legitimate emails. This issue is compounded by the fact that what one person deems spam is not necessarily spam to another.
• Web companies: Companies like CharlesWorks operate email servers for web clients. We are bombarded by complaints about spam.

Contact forms

One aspect of websites that has always been negatively affected by spam and spam filtering is the operation of contact forms on them. Over time, some basic rules have evolved to help forms to get delivered.

DNS settings

There are a number of settings that can affect email delivery from forms, including, but not limited to:

• DNS (the Domain Name System is the phone book of the Internet that lets users connect to websites using domain names instead of IP addresses)
• SPF (the Sender Policy Framework is an email-authentication technique used to prevent spammers from sending messages on behalf of your domain)
• DKIM (Domain Keys Identified Mail is an email authentication technique that allows the receiver to check that an email was indeed sent and authorized by the owner of that domain)
• DMARC (Domain-based Message Authentication, Reporting and Conformance is a policy that allows a sender’s domain to indicate that their emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes – such as to reject the message or quarantine it)

Such records and all of the others that have been developed to control the flow of email are far beyond the scope of this article. There is abundant information on the Internet about each.

Overview

I’ll try to provide a brief overview to give those who do not operate email and web servers a rudimentary idea of what happens.

In a nutshell, one rule revolves around the use of what IP addresses email addresses are “allowed” to send emails from particular domains.

It used to be a website’s form could just send from any address. This made it convenient to collect a website visitor’s email address in a form and send the form content directly to the web owner appearing to come “From:” the website visitor. What a mess this became over the years – as it was the perfect way to spam website owners.

So, form software evolution provided a solution: the web form had to come “From:” an email address actually authorized to send from the web server’s IP address.

This created an issue where the receiver of the email could not “directly” just hit “Reply To” to respond to a website inquiry.

Again, the contact form software “evolved” to allow the insertion of a “Reply To:” field in the email generated by the form. In this situation the website owner would receive an email that came “From:” an authorized address (usually something like mail@ or website@ belonging to the domain of the website). When the emailed form output is generated, the email of the site visitor is then placed in a “Reply To:” field which allows the recipient of the email generated by the form to simply hit “”Reply To” in their email application to conveniently reply directly to the site visitor.

One issue that has been noticed is when the email is “Forwarded” to yet another email provider. It cannot always be guaranteed that the site visitor’s email address after the forward will retain the “Reply To:” field generated in the original form output.

Possible Workarounds

There are, of course, workarounds that can be applied. One is to change the form software (e.g., using a different plugin in WordPress). Unfortunately, that is not always just a simple task. The use of different forms can affect site aesthetics and general content placement. These can result in additional labor expense to make the needed changes.

One simpler workaround I have used is to simply rearrange the field data in the form output. I have done this so the site visitor’s email address is seen by the recipient. This allows the form recipient to simply copy and past the site visitor’s email address into the desired email application to facilitate contacting them.