Use From address properly

Marking as duplicate of #1456422: Problem with emails from different domain as the mail server with the contact module

liquidcms, the patch will overwrite sender email. This way one will not be able to reply to the Contact module's messages.

Hi spring.oracle and liquidcms - couldn't this be easily solved by modifying the patch to include a 'replyto' and set the original from address to the 'replyto' address?. I am not a coder, so can't figure it out myself?

And/Or, could you not put the original senders email address in the body somehow "this email is from [sender email] sent via [site name] with links?

Hi jpjanze,

I'm not familiar with email headers, if in some way it could be possible to set "reply-to" address, that would solve the problem I think.

As for your second point, I think this will require changes in Contact module, and this change might not be appropriate for other users of that module (those who not use SMTP Authentication Support)

Some explanation on headers: http://stackoverflow.com/questions/4728393/should-i-use-the-reply-to-hea...

From this explanation I can conclude that we need to change 'Sender' header. Right now the Sender header is set equivalent to From header. If we set Sender to a parameter from the admin, and leave From as it is now I think we will solve the problem.

I tested, this approach works for me.

In my tests using this module, the emails only contain the header "Sender:" and no "From:" header.
The module seems to be using the "Sender:" field associated w/ the site and not the field defined by the module.

Closing #1147786: "E-mail from address" is not used as a duplicate of this one.

I have a similar situation.

Module is configured to authorize when sending mails (for example, user name is user@server.com, and some password).

If in the submission form (Webform 7.x-3.18) you specify sender's address as user@server.com, then sending a content of the form is without error.

But if you specify (in the submission form settings) sender's address, which will be different from user@server.com, then there is an SMTP server error: 5.7.1 Sender address rejected: not owned by auth user.

P.S.: sorry for my English

delete

A code really similar with the one provided in the patch was already committed a long time ago (lines 73 ~ 100), marking this as work as designed.

Hi wundo,

My suggestion above was different from the original patch. I suggest to change the Sender header so that no need "to hack to fix reply-to issue". This will also fix "You are not allowed to send mail from domain" error, which still exists.

Here is my patch for the current code in repository. Can you please review it?

diff --git a/smtp.module b/smtp.module
index 4f61170..ea46cb6 100644
--- a/smtp.module
+++ b/smtp.module
@@ -342,7 +342,7 @@ function smtp_drupal_mail_wrapper($message) {
 
   $mail->From     = $from;
   $mail->FromName = $from_name;
-  $mail->Sender   = $from;
+  $mail->Sender   = variable_get('smtp_from', '');
 
 
   // Create the list of 'To:' recipients.

To make clear bug description.

This module works only when From address is same as SMTP account. This is good when you just send notifications. But Contacts module uses different From address. And most SMTP servers deny to send contact form messages (to prevent spam, as you pretend to be other domain).

So, the module should handle different From address properly. Right now it doesn't.

spring.oracle, could you provide a patch file?
Also, when you do it, could you please remove the code that your change will make deprecated?

thanks

wundo,

The patch is attached. This fixes "You are not allowed to send mail from domain". I do not touch section with reply-to, I must be was wrong about it.

subscribing...
My version: 7.x-1.0
Both patches posted above do not solve the issue. From field in emails is always the username of the smtp authentication (it happens in my case that it's a valid email address).

@berte, please don't change the module version of the issue to the module version you are using.

patches are created to be applied to dev versions, and not to stable versions.

please consider downloading the dev version and testing the patches again.

also, you don't need to "subscribe" manually anymore, on the top right corner you can click "Follow".

thank you.

The patch at #17 works. Anonymous and authenticated users are able to send mail by submitting the core contact form. The from address they enter is retained as the sending address.

thanks

The from address they enter is retained as the sending address.

fwiw this behaviour will change in D8: #111702: Set fixed "from:" and add "Reply-to:" to comply with DMARC

this will help drupal send email to services that implement DKIM/SPF/DMARC anti-spam tests, like yahoo: https://help.yahoo.com/kb/mail/SLN24016.html

I too can confirm that the patch in #17 indeed solves this major problem.

FYI: I just saw that this excellent patch is incompatible with the patch in https://drupal.org/node/1500296.
My vote is on this patch.

I would love to use this module as a solution to a DMARC policy issue I am encountering with the Contact form on the site that I am responsible for.
To do that I would need the From header in the message to correctly be the "E-mail from address" that I specify in the "E-mail options" of the "SMTP Authentication Support" screen, which currently it is not.

Mark

Not to be that guy, but what expectations would there be to roll this into a stable build or is more testing against this patch required. I have just installed this on my site and seeking as how it is confirmed resolved in the dev build I considered adding that to my sites .... but seeing as how the last Stable release was in Feb I figured it may be rolling out soon. Regardless. Anders brings up an interesting consideration and I am logging this in part to subscribe so I can track the progress.

Thanks for all the efforts.

17: smtp-authentication-support-742962.patch queued for re-testing.

I can also confirm the development version fixed the contact form e-mail from field problem for Drupal 7 described here.

Looks like there is no fix for Drupal 6 yet?
https://www.drupal.org/node/1180946

No problems, it's good.

Just installed smtp-7.x-1.x-dev via drush.

SMTP email through google apps isn't using the FROM address, it uses the authentication user name in who the message is from when it hits my inbox.

See attached screen shots.

The SMTP user name for authentication is who the email is "FROM", despite there being an address and name provided for "E-mail from address"

SMTP SETTINGS.

TEST MESSAGE RESULTS.

Guys can you check this patch:
#2309875-9: Error in 'from' using site-wide contact form and multiple recipients

I think that one has the most expected behaviour.

Issue still remains with patch @Zekvyrin suggests. Simply put the from name is working int he SMTP settings but not the email, it always defaults to the SMTP username as @alphex screenshots demonstrate.

Patch on #17 doesn't apply against latest git checkout. I did tha changes manually, but it still doesn't solve the fact that Drupal tries to connect to the SMTP server using the site-wide email (admin/config/system/site-information) instead of the email defined in the SMTP settings.

I'll give it a second try in the night.

I am using 7.x-1.2 and having a similar issue. The email address that is set in /admin/config/system/site-information for site wide usage is overriding the setting used at admin/config/system/smtp. It doesn't matter what I put in to the smtp settings it is always overridden by the site wide setting.

Rerolled patch

True rerolled patch :)

+++ b/smtp.mail.inc
@@ -100,21 +100,32 @@ class SmtpMailSystem implements MailSystemInterface {
     if ($from == NULL || $from == '') {
...
+    if ($from == '') {
...
+    if ($sender == '') {

suppose all should be empty() checks

I am using the latest release version and still have to adjust the code to get my from used. I applied the following patch:

diff --git a/sites/all/modules/smtp/smtp.mail.inc b/sites/all/modules/smtp/smtp.mail.inc
index a9314b0..94b140b 100644
--- a/sites/all/modules/smtp/smtp.mail.inc
+++ b/sites/all/modules/smtp/smtp.mail.inc
@@ -88,11 +88,6 @@ class SmtpMailSystem implements MailSystemInterface {
 
     //Hack to fix reply-to issue.
     $properfrom = variable_get('site_mail', '');
+    // Hack to use smtp_from as from
+    $tmp = variable_get('smtp_from','');
+    if (isset($tmp) && valid_email_address($tmp)) {
+       $properfrom = $tmp;
+    }
     if (!empty($properfrom)) {
       $headers['From'] = $properfrom;
     }
@@ -105,7 +100,6 @@ class SmtpMailSystem implements MailSystemInterface {
       }
       $headers['Reply-To'] = $reply;
     }
+    $from = $properfrom;
 
     // Blank value will let the e-mail address appear.
 

Hope this helps.

Looks like we are getting very close to a complete resolve @ehj-52n

This needs to be optimized in next merged reroll
And new release

From should be built properly aka #2236237: Use Reply-To instead of From e-mail headers (Google/Yahoo/etc anti-spoofing policy marks e-mails as spam)

sender@theirdomain.example.org via Site Name

As said
#111702-122: Set fixed "from:" and add "Reply-to:" to comply with DMARC

Andypost, please, check patch, do you mean something like this?

Yep, looks rtbc, just need another pair of eyes

I tidied up the patch a little and removed the shortened PHP 5.4 array syntax with the PHP 5.2-compatible longer syntax.

Changing the status back to "needs review" because of a problem with the testbots (see #2645590: Ensure that simpletest job doesn't "fail" testing if no tests are present ).

I used the patch at #47 applied to 7.x-1.3 (doesn't work with current dev). But the test email still uses the site-wide address, and I still get 'Client does not have permissions to send as this sender' when I try to send the test email. Frustratingly this is even the case when I remove all references to 'site_mail' in smtp.mail.inc and hard code an email address. Any idea why?

I think this would be safe to include in the next release.

Tested #47 against 7.x-1.x-dev. Works as expected with the email being sent using the from address in the SMTP configuration and not the site information configuration. Steps taken:

• Set sitewide email to gdaniels@[mydomain]
• Set smtp from email to info@[smtp server domain]
• Sent test email to three email addresses
• All received as from info@[smtp server domain]

Yep, I can confirm the same as @gadaniels72. "If you receive this message it means your site is capable of using SMTP to send e-mail." I'm going to move this to RTBC unless anyone has an objection.

Can't apply patch from #47 against a dev (7.x-1.x-dev - 2016-Jan-25). We need a reroll for the patch.

patching file smtp.mail.inc
Hunk #1 FAILED at 87.
Hunk #2 succeeded at 107 with fuzz 1.
1 out of 3 hunks FAILED

@Vlad thanks for report

Rerolled #47 patch.

Back to RTBC after reroll.
But actually for me this patch isn't helpful so much without #50 and I'm kinda to see fix for #50 in 1.4 release.

There is an error on the proposed patch, as around line 111, there is this line
$properfrom = variable_get('site_mail', '');

that overrides the $properfrom variable.

Also, calling variable_get several times for the same variable is not a pretty solution, I'm committing a quick patch that fixes the major issues from previous patches, but a proper due diligence is necessary before sending this upstream.

I'm trying to get this working with webform but I've encountered a couple of issues.

Firstly, possibly down to PHP 5.6, if the test against $smtp_from_var (~line 96) is successful and AddReplyTo is called, the subsequent AddReplyTo doesn't work later when testing the headers for 'reply-to' (~line 261). Removing this call and adding it after the iteration of the headers works for me.

Secondly, the from name should be set to via if there is a reply to.

Just realised that if subsequent calls to AddReplyTo work for < PHP 5.6 and don't for PHP 5.6, this will break PHP < 5.6. Of course I may be barking up the wrong tree.

patch is same
removed one trailing white space from line: 36

Don't know why this is not working
On my local repo patch applies cleanly
please help

Hello!

This version of the patch in the addition to solve our problem.

@Konstantin Korepin, your patch is incomplete, please check previous patches and approach used

The patch in #65 has a typo where it defines a variable named $smpt_from_var but then tries to use one named $smtp_from_var.

I'm also finding myself in a position whereby the 'from' and 'sender' have to match or otherwise the server won't send the email, but we'd like the 'reply-to' address to be something else.

Bumping to v7.x-1.5 as 1.4 is already out.

The current version 7.x.1.4 of this module defines the variable $from_name in the SmtpMailSystem class, however it is never used or even considered for use afterwards.

I assume the idea was to use it as the $mailer->FromName as was the case in version 7.x.1.3. As a result, recent patches like allow different smtp servers to be used in a multilingual site provide nothing.

Here's what is happening:

<?php
   $from_comp = $this->_get_components($from);

    // Defines the From value to what we expect.
    $mailer->From     = $from_comp['email'];
    $mailer->FromName = $from_comp['name'];
    $mailer->Sender   = $from_comp['email'];
?>

Furthermore, as per 'site_mail' variable override 'From' header, the $from variable will always be the 'site_mail' variable as long as it's not empty. Since it defaults to ini_get('sendmail_from'); is an empty 'site_mail' even possible? Additionally, 'site_mail' gets validated as being simply an email address (No from name). So what's likely happening to most everyone is that the from_name will be empty on any emails sent via SMTP module.

For the meantime, we've changed the above to:

<?php
   $mailer->FromName = !empty($from_comp['name']) ? $from_comp['name'] : $from_name;
?>

Since the module provides a means to set the variables 'smtp_from' and 'smtp_fromname', should not those be used by default if set? I don't understand the logic of that not being the case.

Rerolled, and I fixed two typos in the last patch.

Patch looks ok, but does not address the situation in #74 ($from_name is defined but never used) which I think is in the context of this issue. If not, please let me know so I can create a separate issue.

I wonder if we should expand the options so there are specific fields for each possible "from"-like address and then document in the UI exactly what will be used in what scenario? Right now it's a little confusing.

I see no chages about #111702: Set fixed "from:" and add "Reply-to:" to comply with DMARC

+++ b/smtp.mail.inc
@@ -133,27 +143,35 @@ public function mailWithoutQueue(array $message) {
+      return FALSE;      ¶

trailing white space

Could we just make default settings for these smtp_from and smtp_fromname variables and then just validate that the two are never empty?

<?php

$smtp_from = variable_get('smtp_from', '');

$form['email_options']['smtp_from'] = array(
  '#type'          => 'textfield',
  '#title'         => t('E-mail from address'),
  '#default_value' => !empty($smtp_from) ? $smtp_from : variable_get('site_mail', ''),
);

$smtp_fromname = variable_get('smtp_fromname', '');

$form['email_options']['smtp_fromname'] = array(
  '#type'          => 'textfield',
  '#title'         => t('E-mail from name'),
  '#default_value' => !empty($smtp_fromname) ? $smtp_fromname : variable_get('site_name', 'Drupal powered site'),
);

?>

@wundo: What do you think? I'm happy to put together a patch to clean this up, but I'm not sure what direction to take at this point.

I'm trying to understand this bug, but it seems that we might be trying to fix a few different issues throughout this thread.

Are we trying to fix where programmatically set $from strings are being obliterated by this code or would this be a new bug report?

    //smtp.mail.inc:123-136
    if (!empty($properfrom)) {
      $headers['From'] = $properfrom;
      $from = $properfrom;
    }

A string such as "Firstname Lastname" <test@example.com> may be the original from address, but then is set to just test@example.com at runtime.

The call to $this->_get_components() never has the chance to see the original $from address as it's already been overwritten by the block of code at smtp.mail.inc:123

As a workaround/hack I've commented out line 125.

    //smtp.mail.inc:123-136
    if (!empty($properfrom)) {
      $headers['From'] = $properfrom;
      //$from = $properfrom;
    }

This keeps my programmatically set $from address intact.

I cannot still solve this issue. Still cant use From address and name while sending emails via smtp configuration. Any progress on this one??

I think I am having the same issue, so following this thread to see what happens.

I had this issue as well and found that commenting out line 125 (see #80) allowed me to add the name to the address. For example, I can now put "Firstname Lastname <example@example.com>"

Maybe we should add a check to see if the From field is already populated with a valid value before obliterating it on line 125? I'm not sure what the flow at this point is trying to accomplish though.

We have used #73 solution.

We have changed:
$mailer->FromName = $from_comp['name'];
To:
$mailer->FromName = !empty($from_comp['name']) ? $from_comp['name'] : $from_name;
in smtp.mail.inc file

And now it shows From name.

Bumping this to critical as basic functionality isn't working properly.
There are also many issues that are referring to the same problem.

From #74 and #77, variable name definitely doesn't look right

$smtp_from_var = variable_get('smpt_from', FALSE);

"smpt" instead of "smtp"

Other than that, I really don't understand why are we enforcing 'from' to be loaded from variable?

//Hack to fix reply-to issue.
$properfrom = $smtp_from_var ? $smtp_from_var : variable_get('site_mail', '');
if (!empty($properfrom)) {
  $headers['From'] = $properfrom;
}

Basically, there's no way for end users to set 'from' properly, it's either default smtp_from or default site_mail.

Agreed with #85/#86. This is critical. SMTP function should not change values it is explicitly provided. It should only fill in default values where necessary and log errors if the attempt fails.

The problem here is that the basic hierarchy of which setting to use is being ignored. The hierarchy should be ... Instance > Instance Module > SMTP Module > Drupal Site Settings > Error

For example, I have a Rules Action set up to send an HTML email.

1. I have specified a "From" address where it should go in this instance.
2. If that's blank, MimeMail module will fill in a default.
3. If that's blank SMTP module will not receive a "From" value, at which point it should provide it's own setting.
4. If that's blank, use the site-wide email,
5. and failing all that, throw an error.

How in the world does it make any sense to just overwrite the from address with no warning, no error, no logging and no knowledge of the actual addresses a particular SMTP server is permitted to send from? My SMTP server can send from multiple domains, and this module should make no attempt to block that. But even if I do send from a completely unauthorized domain, let it happen. Let the SMTP server handle it and throw an error. By changing the From address, the issue becomes silent and difficult to track down. It's bad practice.

It is some nonsence ...

    if (!$from_name) {
      if (variable_get('smtp_fromname', '') != '') {
        $from_name = variable_get('smtp_fromname', '');
      }
      else {
        // If value is not defined in settings, use site_name.
        $from_name = variable_get('site_name', '');
      }
    }

after this $from_name is never used. I expect to have a site name in "From". But i always have nothing in From.

    $properfrom = variable_get('site_mail', '');
    if (!empty($properfrom)) {
      $headers['From'] = $properfrom;
      $from = $properfrom;
    }
.....
    $from_comp = $this->_get_components($from);
.....
// Defines the From value to what we expect.
    $mailer->From     = $from_comp['email'];
    $mailer->FromName = $from_comp['name'];
    $mailer->Sender   = $from_comp['email'];

This means that "Site Email" should be "MySite " and the $from_name is always ignored.
Please fix this, before update all was working proper: if from was defined in /admin/config/system/smtp it was used and if not defined - site_name was used. Now always from name is empty, because i need to define it in site_mail now

if i add the

$from_comp['name'] = empty($from_comp['name']) ? $from_name : $from_comp['name'];

then all works as should

I am in a similar situation as eightygrit (#87). I have a rule that defines the "From" address and using smtp to send mime emails. My smtp server allows for emails to be sent from multiple domains. I agree that we should rely on the smtp service itself to handle errors. There are assumptions being made by changing the from address in this module that appear to limit my ability to set "From" information within my rule.

In my case I am using a rule to trigger an email with "From" information supplied. (IE verified-user@example.com). When I send this using SMTP it is changed to site-email@example.com.

@eightygrit... have you found a solution for your use case? I've been up and down this board don't see a clear way to accomplish this.

Thank you to everyone who have contributed their hard work to this module. It's made it incredibly easy to obtain email tracking using services like mailgun and sendinblue. This "From" issue is the last peice in the puzzle for me. Any help would be greatly appreciated.

Just a note, the current version also break's the Webform module's functionality.

Webform allows you to pick a From name and From address per form, but the current version overrides that with the site mail and site name (respectively).

I've implemented the patch from this: https://www.drupal.org/node/2714749 which seems to have solved the issue.

For me #84 solved the issue.
Version: 7.x-1.4

Please correct me if I'm wrong, but based on the most recent comments it sounds like this issue still needs work.

On my server, I found that I had to set the message 'From' to an email address matching the originating domain, as well as ALL of the relevant headers:

$headers['From'] = email@originatingdomain.com;
$headers['Sender'] = email@originatingdomain.com;
$headers['Return-Path'] = email@originatingdomain.com;

And then set the $headers['Reply-To'] to the original sender's email address.

I've attached a patch based on #84 that addresses this. I've also taken into account #86, #87, #88 comments and I believe that the From Name and the From Email are handled gracefully:

1. use variables passed to the function first
2. if there is an 'E-mail from address' and/or 'E-mail from name' set in /admin/config/system/smtp, use those for the sender
3. fall back to the site's email address if no other From email address is set
4. fail with an error message if none of the above are available.

Re: #90 I am using this with webform and it is working for me.

@arvana, thanks for the patch! Changing the status to 'Needs review' accordingly.

@arvana, thanks a lot for this job! (I still have not managed to study how do publish patches)

I had a problem with the last patch where it was adding two addresses in the Reply-To header in some circumstances. Updated patch attached.

Ugh, found another bug that was causing it to generate two From addresses.

Tried applying patches #98 and #97 to the latest dev release.

Hunk #1 FAILED at 85.
Hunk #2 FAILED at 103.
Hunk #3 FAILED at 123.
patch: **** malformed patch at line 168:

Patch #97

Hunk #1 FAILED at 85.
Hunk #2 FAILED at 103.
Hunk #3 FAILED at 123.
Hunk #6 FAILED at 245.

Patch #98 has been re-rolled to apply to latest 7.x-1.x-dev version.

This patch is GOLD,.
Tested #101 sucessfully. Without this patch the module is useless ony most servers.