Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
the module isn't using the From address which is set in the admin; which is a pretty big deal as most SMTP servers won't authenticate with any from address.
the attach patch has the module use the From variable which is already on the admin form.
Comment | File | Size | Author |
---|---|---|---|
#101 | smtp-1686588-101.patch | 4.52 KB | jlscott |
#98 | smtp-n1686588-98.patch | 6.9 KB | arvana |
#97 | smtp-n1686588-97.patch | 6.75 KB | arvana |
#94 | smtp-n1686588-94.patch | 5.1 KB | arvana |
|
Comments
Comment #1
spring.oracle CreditAttribution: spring.oracle commentedMarking as duplicate of #1456422: Problem with emails from different domain as the mail server with the contact module
Comment #2
spring.oracle CreditAttribution: spring.oracle commentedliquidcms, the patch will overwrite sender email. This way one will not be able to reply to the Contact module's messages.
Comment #3
jpjanze CreditAttribution: jpjanze commentedHi 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?
Comment #4
spring.oracle CreditAttribution: spring.oracle commentedHi 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)
Comment #5
spring.oracle CreditAttribution: spring.oracle commentedSome 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.
Comment #6
rodmaz CreditAttribution: rodmaz commentedIn 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.
Comment #7
Simon Georges CreditAttribution: Simon Georges commentedClosing #1147786: "E-mail from address" is not used as a duplicate of this one.
Comment #8
cac2s CreditAttribution: cac2s commentedI 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
Comment #9
Simon Georges CreditAttribution: Simon Georges commentedComment #10
cac2s CreditAttribution: cac2s commenteddelete
Comment #11
Simon Georges CreditAttribution: Simon Georges commentedComment #12
wundo CreditAttribution: wundo commentedA 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.
Comment #13
spring.oracle CreditAttribution: spring.oracle commentedHi 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?
Comment #14
spring.oracle CreditAttribution: spring.oracle commentedTo 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.
Comment #15
wundo CreditAttribution: wundo commentedspring.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
Comment #16
spring.oracle CreditAttribution: spring.oracle commentedwundo,
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.
Comment #17
spring.oracle CreditAttribution: spring.oracle commentedComment #18
Simon Georges CreditAttribution: Simon Georges commentedComment #19
berte CreditAttribution: berte commentedsubscribing...
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).
Comment #20
brunorios1 CreditAttribution: brunorios1 commented@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.
Comment #21
paulrooney CreditAttribution: paulrooney commentedThe 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
Comment #22
mvcfwiw 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
Comment #23
Anders Kallin CreditAttribution: Anders Kallin commentedI too can confirm that the patch in #17 indeed solves this major problem.
Comment #24
Anders Kallin CreditAttribution: Anders Kallin commentedFYI: I just saw that this excellent patch is incompatible with the patch in https://drupal.org/node/1500296.
My vote is on this patch.
Comment #25
marktompsett CreditAttribution: marktompsett commentedI 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
Comment #26
djinn23 CreditAttribution: djinn23 commentedNot 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.
Comment #27
RunePhilosof CreditAttribution: RunePhilosof commented17: smtp-authentication-support-742962.patch queued for re-testing.
Comment #28
ericwongcm CreditAttribution: ericwongcm commentedI 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
Comment #29
dxx CreditAttribution: dxx commentedNo problems, it's good.
Comment #30
alphex CreditAttribution: alphex commentedJust 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.
Comment #31
Zekvyrin CreditAttribution: Zekvyrin commentedGuys 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.
Comment #32
glynster CreditAttribution: glynster commentedIssue 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.
Comment #33
bserem CreditAttribution: bserem commentedPatch 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.
Comment #34
achapI 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.
Comment #35
andriyun CreditAttribution: andriyun at Skilld commentedRerolled patch
Comment #37
andriyun CreditAttribution: andriyun at Skilld commentedTrue rerolled patch :)
Comment #38
andypostsuppose all should be empty() checks
Comment #39
ehj-52n CreditAttribution: ehj-52n as a volunteer commentedI am using the latest release version and still have to adjust the code to get my from used. I applied the following patch:
Hope this helps.
Comment #40
glynster CreditAttribution: glynster commentedLooks like we are getting very close to a complete resolve @ehj-52n
Comment #41
andypostThis needs to be optimized in next merged reroll
And new release
Comment #42
andypostFrom 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)
As said
#111702-122: Set fixed "from:" and add "Reply-to:" to comply with DMARC
Comment #43
vprocessor CreditAttribution: vprocessor at Skilld commentedAndypost, please, check patch, do you mean something like this?
Comment #44
vprocessor CreditAttribution: vprocessor at Skilld commentedComment #46
andypostYep, looks rtbc, just need another pair of eyes
Comment #47
DamienMcKennaI tidied up the patch a little and removed the shortened PHP 5.4 array syntax with the PHP 5.2-compatible longer syntax.
Comment #49
DamienMcKennaChanging 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 ).
Comment #50
pinin4fjords CreditAttribution: pinin4fjords commentedI 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?
Comment #51
DamienMcKennaI think this would be safe to include in the next release.
Comment #52
gadaniels72 CreditAttribution: gadaniels72 as a volunteer commentedTested #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:
Comment #53
jordanpagewhite CreditAttribution: jordanpagewhite as a volunteer commentedYep, 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.
Comment #54
vlad.dancerCan't apply patch from #47 against a dev (7.x-1.x-dev - 2016-Jan-25). We need a reroll for the patch.
Comment #55
andriyun CreditAttribution: andriyun at Skilld, Drupal Ukraine Community commented@Vlad thanks for report
Rerolled #47 patch.
Comment #56
vlad.dancerBack 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.
Comment #57
wundo CreditAttribution: wundo at Chuva Inc. for Chuva Inc. commentedThere 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.
Comment #58
danwonac CreditAttribution: danwonac commentedI'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.
Comment #60
danwonac CreditAttribution: danwonac commentedJust 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.
Comment #61
himanshugautam CreditAttribution: himanshugautam commentedpatch 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
Comment #62
himanshugautam CreditAttribution: himanshugautam commentedComment #65
himanshugautam CreditAttribution: himanshugautam commentedComment #66
andypostComment #69
Konstantin Korepin CreditAttribution: Konstantin Korepin as a volunteer commentedHello!
This version of the patch in the addition to solve our problem.
Comment #70
andypost@Konstantin Korepin, your patch is incomplete, please check previous patches and approach used
Comment #71
DamienMcKennaThe 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.
Comment #72
DamienMcKennaBumping to v7.x-1.5 as 1.4 is already out.
Comment #73
blasthaus CreditAttribution: blasthaus commentedThe 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:
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:
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.
Comment #74
DamienMcKennaRerolled, and I fixed two typos in the last patch.
Comment #75
blasthaus CreditAttribution: blasthaus commentedPatch 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.
Comment #76
DamienMcKennaI 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.
Comment #77
andypostI see no chages about #111702: Set fixed "from:" and add "Reply-to:" to comply with DMARC
trailing white space
Comment #78
blasthaus CreditAttribution: blasthaus commentedCould we just make default settings for these smtp_from and smtp_fromname variables and then just validate that the two are never empty?
Comment #79
DamienMcKenna@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.
Comment #80
citricguy CreditAttribution: citricguy as a volunteer and commentedI'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?
A string such as
"Firstname Lastname" <test@example.com>
may be the original from address, but then is set to justtest@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.
This keeps my programmatically set $from address intact.
Comment #81
sanjay.maharjan CreditAttribution: sanjay.maharjan commentedI cannot still solve this issue. Still cant use From address and name while sending emails via smtp configuration. Any progress on this one??
Comment #82
ryanfc78 CreditAttribution: ryanfc78 commentedI think I am having the same issue, so following this thread to see what happens.
Comment #83
citricguy CreditAttribution: citricguy as a volunteer and commentedI 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.
Comment #84
mariusisi CreditAttribution: mariusisi as a volunteer commentedWe 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.
Comment #85
vladan.me CreditAttribution: vladan.me as a volunteer commentedBumping this to critical as basic functionality isn't working properly.
There are also many issues that are referring to the same problem.
Comment #86
vladan.me CreditAttribution: vladan.me as a volunteer commentedFrom #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?
Basically, there's no way for end users to set 'from' properly, it's either default smtp_from or default site_mail.
Comment #87
eightygrit CreditAttribution: eightygrit commentedAgreed 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.
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.
Comment #88
Mykola DolynskyiIt is some nonsence ...
after this $from_name is never used. I expect to have a site name in "From". But i always have nothing in From.
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
then all works as should
Comment #89
pauldolphin CreditAttribution: pauldolphin as a volunteer commentedI 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.
Comment #90
wmcmillian-coalmarch CreditAttribution: wmcmillian-coalmarch commentedJust 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.
Comment #91
xaris.tsimpouris CreditAttribution: xaris.tsimpouris commentedFor me #84 solved the issue.
Version: 7.x-1.4
Comment #92
Chris Matthews CreditAttribution: Chris Matthews commentedComment #93
Chris Matthews CreditAttribution: Chris Matthews commentedPlease correct me if I'm wrong, but based on the most recent comments it sounds like this issue still needs work.
Comment #94
arvana CreditAttribution: arvana as a volunteer commentedOn 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:
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:
Re: #90 I am using this with webform and it is working for me.
Comment #95
Chris Matthews CreditAttribution: Chris Matthews commented@arvana, thanks for the patch! Changing the status to 'Needs review' accordingly.
Comment #96
Mykola Dolynskyi@arvana, thanks a lot for this job! (I still have not managed to study how do publish patches)
Comment #97
arvana CreditAttribution: arvana as a volunteer commentedI had a problem with the last patch where it was adding two addresses in the Reply-To header in some circumstances. Updated patch attached.
Comment #98
arvana CreditAttribution: arvana as a volunteer commentedUgh, found another bug that was causing it to generate two From addresses.
Comment #99
thomasmurphy CreditAttribution: thomasmurphy at Xequals commentedTried 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.
Comment #100
thomasmurphy CreditAttribution: thomasmurphy at Xequals commentedComment #101
jlscott CreditAttribution: jlscott commentedPatch #98 has been re-rolled to apply to latest 7.x-1.x-dev version.
Comment #102
marcoka CreditAttribution: marcoka commentedThis patch is GOLD,.
Tested #101 sucessfully. Without this patch the module is useless ony most servers.
Comment #103
arvana CreditAttribution: arvana as a volunteer commentedComment #104
DamienMcKennaComment #106
joseph.olstad