There's an issue in the Webform Reply-To queue which includes a patch to support Webform 7.x-4.x. However, more recent reports there indicate that as of the alpha9 version of Webform, a bit of logic that had been present to permit inline additions to the form rendering was removed, breaking the patch. Might we get that restored, or if not, could you suggest a more appropriate approach? I'd like to release an update of WRT that supports both 3.x and 4.x, if possible.

Comments

knalstaaf’s picture

Issue summary: View changes

Wouldn't it be better to integrate the reply-to functionality into the core of the webform module instrad of a separate module?

More: maybe this shouldn't even be an option that can be chosen, but applied to any webform automatically, since it's a good practice to provide a reply-to address to avoid spamfilters from holding messages back. Services like Gmail tend to refuse e-mails with no reply-to for instance.
Unless the user explicitely wants the reply-to address to be different from value that's been put in an e-mail field (which can trigger spamfilters though).

alexp999’s picture

I think it would be great to have reply-to built in, but it needs to be customisable.

For example we use webform to provide a quote request form on our website, the emails then get sent to our sales team, who just want to hit reply and have it go to the email address given on the request form.

This lets us keep an "info@" address as the from address so it doesn't fail SPF validation.

jerry’s picture

Wouldn't it be better to integrate the reply-to functionality into the core of the webform module instrad of a separate module?

There has already been some discussion of this here in the Webform Reply-To issue queue, incidentally. We're in favor of it from that side, so long as the existing configurability can be maintained.

quicksketch’s picture

The issue for including Webform Reply-To (-like) functionality into Webform is #2236237: Use Reply-To instead of From e-mail headers (Google/Yahoo/etc anti-spoofing policy marks e-mails as spam). It'd be great if you guys could weigh in over there.

More: maybe this shouldn't even be an option that can be chosen, but applied to any webform automatically, since it's a good practice to provide a reply-to address to avoid spamfilters from holding messages back

That's exactly what I was proposing as well. :) Let's discuss in the main issue.

Regarding "restoring compatibility with Webform Reply-To", I didn't realize that we'd changed Webform in a way that prevented it from functioning with Webform 4.x. I'd also be happy to accommodate for it as an add-on module for users that want to explicitly define separate FROM and REPLY-TO headers on a per-form basis. For most users though, I don't think they understand the difference between these two options, which is why I'd like to avoid adding more fields to the individual e-mail configuration forms.

So in summary:
- For solving the From/Reply-To header problem in an site-wide way, see #2236237: Use Reply-To instead of From e-mail headers (Google/Yahoo/etc anti-spoofing policy marks e-mails as spam).
- Let's use this issue to restore compatibility with Webform Reply-To.
- If you absolutely need to define different From/Reply-To headers on a *per-form basis*, continue using Webform Reply-To after compatibility has been restored.

danchadwick’s picture

Status: Active » Fixed

Compatibility has been restored, and hopefully this feature will be incorporated into webform core.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.