email field should be used in emailReplyTo, not emailFrom, to avoid rejected emails based on SPF/ DMARC violation

[yoleg]

The default behavior of the FormIt email hook of setting the "from" address as the "email" form field causes failure of contact form emails when they are sent to email providers that reject or greylist SPF/ DMARC failures, such as gmail.

Severity:

• This problem only happens for certain form submissions (e.g. from aol.com users) and when using certain providers (e.g. gmail), so it can take a long time to realize it is happening. By that time, you have lost several form submissions.
• What's worse, no error is logged to the MODX error log or shown during the form submission (at least for certain mail server configurations), and you usually must have root access to view mail logs to even see this problem
• If your mail server is properly configured to send the reject mail back to the form submitter, they get to see your (possibly private) email address.
• If you're lucky, some user might be able to contact you some other way to tell you about the reject message. Otherwise, you might never know about the failures.

Note: I have been monitoring my exim logs over the last few weeks for several clients, and I have verified several lost contact form submissions already!

Backgound: SPF is a public domain policy (published via DNS TXT records) that lists the servers that are allowed to send mail with a "from" address from that domain. Spam often uses fake "from" addresses and usually fails SPF validation, so many email providers reject or greylist mail that fails SPF. DMARC is an additional policy that recommends what to do with SPF or DKIM failures of email "from" that domain.

Example 1: A user fills out a FormIt contact form with the email address "someone@aol.com". The contact form sends the email to the emailTo addresss, which is the admin's gmail address. aol.com has recently implemented a DMARC policy of "reject" for SPF failures. Because the email says "from" aol.com but this web server is not listed in aol's SPF record of allowed servers, SPF validation fails, and GMail honors aol's policy to reject SPF failures by rejecting the email. The email to the admin fails, possibly with a failure notification sent to "someone@aol.com" IF the mail server is configured to do so.

Example 2: A user fills out a FormIt contact form with the email address "someone@gmail.com". The contact form sends the email to the emailTo addresss, which is hosted with Zoho Mail. The admins have configured Zoho Mail to reject SPF violations to reduce spam, since Zoho Mail does not support DMARC. The email fails SPF validation, because gmail.com's SPF policy does not allow THIS web server to send mail "from" gmail.com. The local server's retry timeout expires, and the email to the admin fails, possibly with a failure notification sent to "someone@gmail.com" IF the mail server is configured to do so.

Proposed Solution: The default behavior should be changed to be as follows:

• &emailFrom - If not set, use the emailsender system setting
• &emailFromName - If not set, the site_name system setting (or perhaps leave empty)
• &emailReplyTo - If not set, first look for an email form field. If none is found, leave empty.

This way, the email will still be easy to "reply to". The emailsender is likely already set to an address that is allowed to send from this server. Even if it is not, the SPF/ DMARC failures would be CONSISTENT, and thus easier to detect during initial testing.

[jpdevries]

Possibly related, this seems strange to me:

Optional. If set, will specify the From: address for the email. If not set, will first look for an email form field. If none is found, will default to the emailsender system setting.

So I created a FormIt form and labeled the email the user inputs as email, as many would. The expected behavior was emails would be sent from the emailsender setting but instead emails get sent "from" the email the user registered with causing SPAM issues.

I would think it would be better to:

Optional. If set, will specify the From: address for the email. If not set, will default to the emailsender system setting.

[jpdevries]

• &emailReplyTo - If not set, first look for an email form field. If none is found, leave empty.

Maybe this should be emailsender as well? It doesn't really make sense to me that a form accepting a user to input their email would have them reply to themselves...

I agree this is a severe issue, and the solution(s) may need to be considered a breaking change (major version bump).

[joeke]

@yoleg @jpdevries I've made the folllowing changes to the email hook: emailReplyTo will now fallback to a form field with name 'email' (same behaviour as emailFrom) As discussed with JP in https://github.com/Sterc/FormIt/pull/102; for the sake of backwards compatibility I've elected to not change the behaviour of the fallbacks in the emailFrom parameter. I did update the RTFM pages to urge people to always set the emailFrom to a valid emailaddress to prevent email rejections. Furthermore the emailFromName already has a fallback to site_name system setting, so no changes required there. The changes will be available in upcoming FormIt release 2.2.11.

[joeke]

Version 2.2.11 is out: https://modx.com/extras/package/formit

[jpdevries]

@joeke so does that mean that currently emailFromName falls back to the site_name but emailFrom falls back to <input name="email"> as it did before? Would that mean that for registration forms where emailFrom is not set and the user signs up with <input name="email"> they'd get an email from themselves but with a emailFromName of the site name?

Agreed on needing to keep it for backwards compatibility, but for that reason I'd +1 coming back to this for a 3.0 release.

[joeke]

@jpdevries Yes you are right on the fallback. I also agree that for a 3.0 (or perhaps 2.x) release this behaviour should be changed to the proposed solution.

[jpdevries]

@joeke well, to be all semver about it I think it could be considered a breaking change and justify a major bump. It could be considered modifying an existing feature, because that is basically what it is doing and just be a minor bump but the thing is depending on how people have things configured it could cause unexpected results.