E-mail from address: Custom; E-mail from name: Custom > Not being passed in e-mail

I am having this same problem, the webform is grabbing the default email from the site information.
Even the default email name is not displaying when looking at the email response.

I am also having the same problem. I am on D 7.14 and Webform 7.x-3.13

I am using the select options component and am having the same issue. Instead of pulling the email address from the list of options it always uses the default email address. Please let me know if you find a workaround.

Thanks

same here. the "from" address is not pulling the form value, but rather the default address - subscribing

Installing the Mime Mail module seems to have fixed this problem for me. I didn't have to configure anything just enabled and everything worked perfect again.

http://drupal.org/project/mimemail

Can confirm this, running Drupal 7.19, with 7.x-3.18 Webform. The Custom 'From Address' is not working, it is always sending out the default 'From Address'. Will take a closer look and see if there's any patch I can come up with, but wanted t confirm. Would rather not install another module as a "fix" as in #5.

Also having this problem running d7.20 and webform 7.x-3.17

thanks

I haven't been able to confirm this problem. I did the following:

Make a new Webform with 3 fields:

Subject (Textfield)
To E-mail (E-mail)
To E-mail Select (Select list)

Then I set up two e-mails.

One e-mail:
E-mail to address: "To E-mail"
E-mail subject: Custom: Test subject
E-mail from address: Custom: test@localhost.localhost
E-mail from name: Custom: Test Name

And a second e-mail:
E-mail to address: "To E-mail select"
E-mail subject: Custom: Test subject2
E-mail from address: Custom: test2@localhost.localhost
E-mail from name: Custom: Test Name2

Both e-mails came through to my inbox fine with the proper subjects, from names, and from addresses. I tried with and without MIME Mail installed and both worked as expected. I'll need more information on how to reproduce this problem.

Oh... I just looked at the versions here. I'm running Webform 4.x. I'll need to reconfirm with 7.x-3.18. As an alternative, users might try upgrading to 4.x if you can, as my testing above did not exhibit the behavior.

Not able to produce this problem in one of my project , where I have used webform.

had same problem of From address always using the site address. i think it had something to do with the SMTP server not being local to the web server (i.e., MX is set to REMOTE MAIL EXCHANGER in DNS).

what got it working for me was to change drupal_mail in includes/mail.inc as shown below. i don't like changing core and this is probably not the best fix anyway. so i'm looking for other ideas here.

if ($default_from) {
    // To prevent e-mail from looking like spam, the addresses in the Sender and
    // Return-Path headers should have a domain authorized to use the originating
    // SMTP server.
    $headers['From'] = $headers['Sender'] = $headers['Return-Path'] = $default_from;
  }
  if ($from) {
-    $headers['From'] = $from;
+    $headers['From'] = $headers['Sender'] = $headers['Return-Path'] = $from;
  }

At this point, 7.x-3.x is receiving critical bug fixes only. Please update to 7.x-4.x.

I am having this issue in version 7.4.3. Do I need to submit a new issue or can it be handled here?

No matter what I choose for E-mail from address and E-mail from name it uses the site default.

@esquareddesign - Visit admin/config/content/webform and uncheck 'Use Reply-To header'. Almost certainly your From address is being moved to the Reply-To address and your site address used as the From address. This prevents most major e-mail hosts from mis-classifying your email as spam. If this isn't your issue, open a new issue .

Solution in #15

Visit admin/config/content/webform and uncheck 'Use Reply-To header'.

Solved my problem!

Thanks.

Solution in #15

Visit admin/config/content/webform and change email solved my problem - but it took me a long time to figure it out (ie. searching here.)

Isn't this something that should be fixed for Webform 4 as well?

It helps to uncheck 'Use Reply-To header', but that means that webforms that require this setting (because messages are sent to a Gmail address for instance), still have to deal with this?

I'm asking first before reopening this thread for Webform 4. Maybe there's no other way…

Set Site Name in FROM : (in Mail) Custom Domain Basis :
Example

function hook_mail_alter(&$message) {
if($message['id'] == "id" && $domain_id == 368){
$default_from = variable_get('site_mail', ini_get('sendmail_from'));
if($message['from'] == $default_from){
$message['from'] = '"'. variable_get('site_name', 'Drupal') .'" <'. $default_from .'>';
$message['headers']['From'] = $message['from'];
}
}
}

solution in #15 worked for me.

To stop everyone that installs webform from eventually ending up here…

Feature Request:

On the:

Tab: Webform » E-mails, Edit (/node/10120/webform/emails/1)
Section: E-mail header details, E-mail from address

- Please install logic such that the sub-section “E-mail from address” is grayed out if 'Use Reply-To header' is checked.
- Also please add the instructions, in the same sub-section, “Visit admin/config/content/webform and uncheck 'Use Reply-To header' to enable this section.”

I fixed this by combining a few solutions found here in this thread and modifying them a little to be more generic.

Uncheck "Use Reply-To header" here: /admin/config/content/webform

Create a custom module and put this in it:

function YourModuleName_mail_alter(&$message)
{
   //Only do this for webform submissions
   if ($message['id'] == 'webform_submission' && !empty($message['headers']['From']))
   {
      //Attempt to set every "from" address to whatever is coming from the webform.
      //Used by some email clients I think,  unsure if needed,  but why not.  Its there,  change it.
      $message['headers']['Sender'] = $message['headers']['From'];
      //Yes, return-path really does have to be changed,  otherwise the "from" address still reverts to the default which is unwanted.
      $message['headers']['Return-Path'] = $message['headers']['From'];
      //This replaces the broken "Reply-To" feature of webform (the checkbox thing mentioned above)
      $message['headers']['Reply-To'] = $message['headers']['From'];
   }
}

Create a webform and change it's "From" address either with a component or a custom value.

Doing all of the above should result in the "From" addresses changing from the default which is usually the site's admin email.

In my case helped following:
admin/config/system/smtp -> E-MAIL OPTIONS -> E-mail from address (The e-mail address that all e-mails will be from.)

LET THIS FIELD EMPTY!

@Xisuthros - thank you! that fixed my issue as well!

@xisuthros 's solution fixed it for me as well.

Another +1 for #23

Does this solution need to be documented somewhere?

@#21: Would you still like to have the feature implemented this way or does #23 do what is needed?

Something that should be noted, but is heavily dependent on people's SMTP setup. By modifying this setting and having the from address be completely dynamic based on form input you may have messages refused by your mail transport agent because they are not "from" the main domain.

Hi Liam,

Ah, 2yrs ago, let me review and I'll edit this post Tuedsy(ish) [+3days from now].

Best,
Michael

Hi Liam, (@#27)

#23 is just a user forced work-around for what I wrote in @21. Yes it works, but no it doesn’t really solve the problem to stop the need for “everyone that installs webform from eventually ending up here.”

So, yes, my suggestion is to still implement something* along the lines of what I suggest in @21, as that saves the most man hours for the most people.

Best,
Michael

* I’m not against something like @22, but logic as such would need to be documented in the README file (or nobody will have a clue where the From gets set from).

Hello Michael-IDA, agree with your feature request.

It took time to figure this out but in my case the SMTP solution #23 was quick and simple. As I want all outgoing emails to use only one from address it worked form me but it might not be case for other. I am happy to work on patch. Thanks

Drupal 7 is no longer supported. If this applies to a supported version, please re-open.