Email from address won't change

This module stores data in the table called `variable`. You can query it for SMTP module settings with

sql> select * from variable where name like 'smtp%';

Also, this issue duplicates #200415: The sender mail address is always site address.

This is an FYI for all concerned parties. (This message is duplicated on the issues listed below. Read on for the why.)

I don't actually like the way the From e-mail address is handled in the code for the SMTP Authentication Support module. I have plans to change it, but because I think it will be a bit of a paradigm shift to change it so it works better and makes more sense, I was kind of waiting for my last massive changes is settle in a bit to see if they were causing anyone any problems before I potentially created more problems.

Although all the relevant issues are all pretty much duplicates of each other, there are some nuances in each that I want to capture in my work through the code. These are the relevant issues that I'll be working on together:
http://drupal.org/node/200415
http://drupal.org/node/279836
http://drupal.org/node/295655
http://drupal.org/node/300055

Just know that I will be working on these in the next month or so (sooner, if I get my current task list cleared up).

BTW, I'll be making the changes first in the 6.x branch. Once everything is settled, I'll backport them to the 5.x branch.

Updating the above list to call in issue name and status:

#200415: The sender mail address is always site address
#279836: "Name" <email@example.com> FROM name fails
#295655: Email from address won't change
#300055: username <user@example.com> not supported properly

Not quite sure what is proposed here; but i think my comment is a vote to change the logic.

I think the smtp_from var should override the site_mail address. This allows dev installs to set the smtp from address in settings.php which seems likely use case for using this module.

in other words; if smpt_from is set; that should always be used. if not set; then try using site_mail.

ALSO.. the actual logic is incorrect once this check is passed.

this code:

  if ($from == NULL || $from == '') {
    // If from e-mail address is blank, use smtp_from config option.
    if ($from = variable_get('smtp_from', '') == '') {
      // If smtp_from config option is blank, use site_email.
      if ($from = variable_get('site_email', '') == '') {
        drupal_set_message(t('There is no submitted from address.'), 'error');
        watchdog('smtp', 'There is no submitted from address.', array(), WATCHDOG_ERROR);
        return FALSE;
      }
    }
  }

is incorrect as there are () missing around the shortcut used to assign $from and do check all at the same time.

code should be:

  if ($from == NULL || $from == '') {
    // If from e-mail address is blank, use smtp_from config option.
    if (($from = variable_get('smtp_from', '')) == '') {
      // If smtp_from config option is blank, use site_email.
      if (($from = variable_get('site_email', '')) == '') {
        drupal_set_message(t('There is no submitted from address.'), 'error');
        watchdog('smtp', 'There is no submitted from address.', array(), WATCHDOG_ERROR);
        return FALSE;
      }
    }
  }

attaching a patch that works in the following way:

in the smtp admin screen, if a from name is specified, it always appears as the from name in the email header. if no from name is specified, it falls back to the site name

in the smtp admin screen, if a from email is specified, it always appears as the from email in the header. if no from email is specified, it falls back to the site admin email

this also replaces the email header "admin@site.com on behalf of Your Name [you@site.com]", with what we would prefer, "Your Name [you@site.com]"

there was some code that was marked as hack, that i honestly didn't really understand. i've removed it and things still seem ok on my system. could others verify that this patch works as expected for your configuration?

Closing very old (dead) issues, if you think this is still relevant please re-open.