I'm new to Drupal, just made my first site and having some issues with email. Two questions:
I've enabled the site-wide contact form, and sometimes though not always, I'll receive two identical emails from my site when someone submits a message via the contact form.
I've found documentation on Drupal's email handling very sparse. Can someone give me a brief rundown on how Drupal sends email? I have it installed on a godaddy server, and I have my own domain name, but I never set up any email services from godaddy or configured any emails settings for Drupal (e.g. SMTP, POP), so I was surprised it could send emails right off the bat. On this topic, is there a better way to handle simple email tasks like the contact form than by using the built-in email features of Drupal core?
Thanks.
I'm not sure. Can you replicate this
problem yourself or is the just an occasional happening?
By default Drupal will
use the PHP mail() function
(http://php.net/manual/en/function.mail.php)
which (usually) does not require you to do any
explicit email configuration.
You can use the hook_mail_alter (http://api.drupal.org/api/drupal/developer--hooks--core.php/function/hook_mail_alter/6) in a custom module to peer more deeply into the emails that are being sent. This does require an understanding of PHP.
A very widely used (and better) alternative to the Contact Form is the Webform module (http://drupal.org/project/webform). It provides a very easy to use interface to generate custom forms and does not require any programming knowledge.
If you wish to send more sophisticated emails you may want to investigate the SMTP module (http://drupal.org/project/smtp) which allows you to send to an SMTP server. Also, check into the MimeMail module (http://drupal.org/project/mimemail) as it allows for things like attachments and HTML emails without having to crack open and modify an email's headers via hook_mail_alter.
Answers
Hard to say, it could be a few things, but answering question 2 may give clues about question 1. I am guessing it is due to the configuration of your current email server.
Drupal can be configured to send mail LOTS of different ways, but by default it uses the built in php mail() function. This is configured in your php.ini. I would imagine that godaddy probably set up an SMTP or sendmail server by default.
For both of these issues, I would look at how things are configured (which, due to the nature of godaddy, may not work very well) or by talking to godaddy.
My recommendation would be to use google apps to host your email. Then you can have email sent from your domain but with google reliability, and having it be free!. To connect with drupal, use this module which requires PHPmailer, which may or may not be installed already by godaddy (they should support it though!).
Hope that helps. Leave any more questions in the comments.
Related
The “WP Mail SMTP” revoked the connection from my G-mail account again and again.
No password changed.I missed my order notification again and again.Please tell me why it is happening.
WordPress Version:- 5.6
PHP Version:-
WP Mail SMTP Version:- 2.6.0
Web Server:- Apache
PHP version:- 7.3.5
License key type:- lite
To solve it I accessed WP Mail SMTP settings on WP Admin Dashboard and, in the Authorization, pressed "Removed the Connection"
And then allowed the connection again ("Allow plugin to send emails using your Google account")
And that redirected to the following screen (after login), and had to allow
Note: One needs to be in the Google Account that one configured the API (see here how to configure WP Mail SMTP for Google Workspace/Gmail Mailer)
Token has been expired or revoked, but it is hard to know exactly what is the problem.
My guess is that it could be happening for a variety of reasons, such as resetting the password of the account one is using.
A WPMail SMTP creator wrote (here) the following:
Hi everyone,
it looks like this is happening to more and more users, but we don’t
know what the reason behind this account disconnect is. We have a lot
of testing sites set up, and we never experienced this issue. I just
rechecked my testing sites.
One of the main things that could cause this issue is if your
Google/Gmail API app is in “Testing” mode. Could you please check if
the google API project is in the “Production” mode by going to the
Google API console, opening the project for our plugin integration,
then go to “OAuth Consent Screen” and check the “Publishing status”.
More info can be found in this screenshot. It should say “In
production”.
If that’s not the reason, then we have to go over all the Gmail API
project options together and see what the differences are. I think it
has to be something on Google’s side since they are the ones that
invalidate the token, not us.
And to answer bst7’s questions: The Google API app is created by you,
to be used just by you, even though on the free Gmail accounts you
have the app set to “External use” (no other option is available), but
nobody else will use this app apart from you, since you are the only
one that knows the project credentials and have logged into it from
your secured WP admin dashboard.
Our plugin requires top-level permission because that’s the best way
to future-proof our plugin development. If we were to improve our
plugin and would have required only the minimal permission level, upon
the plugin update, your connection would be invalidated and the newly
added plugin functionality would not work. For example, we added the
support for aliases a few versions ago and if we didn’t have the
top-level permission, after the update all users would have to reset
the connection manually in order for the Gmail mailer to work properly
again. It’s just a way to make sure we can keep improving our plugin
without any issues for our users.
However, in my case the Publishing status is "In production" and the problem also happened.
We just open a new e-commerce website and recently noticed Gmail treat our e-mails as spam (notice the red question mark). Our website run behind CloudFlare so the email server IP address is different than the domain.
We also did not send a bulk email at least not yet. There are some explanations in Google FAQ but not sure what it means or how I need to implement it. Can you please explain how to set these DKIM (preferred) or SPF.
Our website uses nopcommerce (3.70) and developed with ASP.Net.
Disclaimer: I'm not a "pro" at these things (more later):
IMHO, this is probably the simplest explanation of DKIM
SPF: in my own words: providing a DNS TXT record that identifies "where" all your emails (smtp/mta servers) can come from. The more complete/formal spec is here
You can implement both
Opinionated:
SPF is easier to implement
identify all the origins of your email, set them in your SPF record, which is a TXT record in DNS
DKIM: is more complex - your mail/smtp server/s must implement it.
As a "web developer" one can see how this would be done in ASP.Net/C#/VB - e.g. sign some payload and using HttClient send some signature in an HTTP header in some outbound request.
But this is done on an SMTP server, so unless you have one that already implements it, it's something you'll have to do...
IMHO, for DKIM, unless your SMTP/MTA implements it, I'd go for services that provide it. There are 2 types:
Transactional email services:
Not for bulk email. These are the usual "order confirmation" emails, standard support/customer service, etc. emails. They will likely have APIs for you to implement (e.g. sending your MailMessage using thier servers and/or constructing something that equates to it and send that "object" to their API).
Bulk email services
these providers will already have implementations because one of their core value propositions is "deliverability" of your bulk/marketing emails. They should (of course do your due diligence) have both implementations inherently. Will also have their own APIs for bulk email context.
Hth
I am currently doing work for a client and am running into a bit of an issue when an email receipt is sent to the user. What is happening is that once the email address is delivered the from address is completely different then the one I am using. I have tried using a few different email addresses and they work fine. It's only the one that they really want to use that is causing the problem.
I don't have access to their site and am also unsure of how the mail is sent. What I am wondering is if anyone knows the questions that I can ask to figure out what is going on on there end. They recently changed who was handling their site so I have a feeling something may be getting mixed up.
The site is built with WordPress and is using Gravity Forms. From the changed email address I can see that they are using Bluehost since the email changes from #companyname to #boxXXX.bluehost.com.
Email servers are not my area of expertise so I really appreciate any help.
Very likely their Wordpress website is sending emails through the wp_mail() function which is nothing more than the usual mail() function from PHP.
By default if you send an email through this method it will display either the hostname of the server where the website is sitting or the SMTP server, in this case boxXXX.bluehost.com depending on what's the policy of Bluehost regarding sending e-mails.
Generally hosting provider switch off the php mail() function in shared hosting environments to prevent spam and they provide you with the details to connect to their SMTP server and send legit e-mails, if their server is sitting on a shared hosting I think you might need support from Bluehost directly, explain to them the situation and they will help you throughout the process.
If the website is sitting on a virtual dedicated server then they need to do additional configuration on it. In this case what I do is to access onto cPanel and create a new mailbox with the address I want to send from (wordpress#domain.com, info#domain.com, whatever the client wants to be displayed) and configure Wordpress to send with through the VPS SMTP (you can do that easily with this nice plugin: http://wordpress.org/plugins/wp-mail-smtp ) with the address and password you chose when creating the email account on cPanel.
From now on the email will show the correct address.
Also you might want to increase the deliverability of your message and to instruct the email servers that are receiving the email that you're using a legit account, so you should add to their DNS both DKIM and SPF server records.
Note: I suggest you to be extremely cautious when playing around with DNSes, especially when touching email related records. If you are not familiar on how setup new and change the current existing records ask for help from someone who has quite good experience and to guide you through the process so you understand how it works and the consequences of a bad formatted or clashing records.
We recently had a really bad couple of hours at work when someone touched the company records without any clue of what was doing and we ended up with no email and website working for several hours.
I am using Contact Form 7 with Dynamic Text Extension on a WordPress site. The information does not get stored to a database, rather it is sent only via email. Is there a way that I can encrypt the information that is sent in the email?
We are going to purchase and install an SSL certificate to use for these forms, but I'm not fully familiar with how SSL works. Does any form data sent from an https link automatically get encrypted, or is this something that I have to implement? If so, how does it get unencrypted when it hits our mail server?
Thanks for any insight you can give.
Old question, but incorrect (or rather a partial) answer I believe. The question was whether HTTPS will secure the email being sent by CF7.
Back to basics...there are two transfers of the data that potentially could/need to be secured. The first is from the user's browser to the CF7 plugin form on the Wordpress server. This can be sent over an encrypted channel using https.
The second is when the form data is sent by the CF7 plugin by email. Setting up https/an SSL cert. on the Wordpress server does nothing to improve the security of this. Email is sent by SMTP from CF7 so all standard caveats regarding security of emails apply.
Stuart
https secures the communication between the client/user <-> server using a SSL certificate. This would be the best method to use if you do not want to code your own custom plugin that will encrypt it without the communication being encrypted. Since the communication to the server is secured it does not require you to decrypt anything as the server will obtain the information securely (which prevents man in the middle attacks and so on). More about https - http://en.wikipedia.org/wiki/HTTP_Secure
You can use a plugin to help you implement the communication to your site being secured:
http://wordpress.org/extend/plugins/wordpress-https/
Otherwise you can code your own plugin or contact form under PHP and directly encrypt the content that is being sent to your email or just to the submit form depending on how you would like this information encrypted
You're looking for the WP PGP Encrypted Emails plugin for WordPress. Install it, paste in your PGP public key (or your S/MIME certificate, whichever email encryption scheme you want to use), and it makes sure outgoing email your site or contact form plugins generate addressed to you are encrypted (and, optionally, even signed).
If you don't know much about email privacy or encryption, be sure you read the plugin's FAQ, which has a bunch of links to additional information.
Full disclaimer: I'm the developer of this plugin.
I'd like to be able to use these "best of breed" opensource solutions, with the only requirement of some sort of single-sign-on between the different sites. I don't want my users having to log-in in 3 different places, so I though it could be possible with OpenId.
Has anyone tried something similar?
OpenID will not avoid the problem of having to sign in 3 separate times. It was allow the user to share the same login credentials between the sites, but they will have to actually log in to each of the three systems. If that is not a problem, go with OpenID. If it is, you have two options:
Use an LDAP server to authenticate on all three sites. I think all three software packages have modules/plugins for LDAP (Drupal, Moodle, MediaWiki). Once you have the LDAP server running, the rest should be easy.
Write custom modules/plugins for each platform that authenticate against a single database. Maybe you could use the Drupal database as the primary one, and have MediaWiki and Moodle authenticate with that. So, effectively, the user will only have an account on the Drupal site, but will get access to all three. This is basically the same idea as an LDAP server, but might save you some overhead and complication.
There is also the Moodle Integration module for Drupal that attempts to accomplish the same thing, only without MediaWiki in the mix. I would check that out.
Good luck!
here are three possible solutions: (1) sigle sign-in site, (2) inject login/register forms into all sites using server site includes - SSI and (3) - ajax.
Single sign-in site.
suppose you have site1.domain.com and site2.domain.com and you want to login/register at both simultaneously. Probably the easiest way to do it will be to create another domain e.g. login.domain.com that will do the job. Your login/register application will need access to databases for site1 and site2 and/or their api's. Since login status usually resides in the cookies, your login application will need to set those login cookies to both sites simultaneously (on successful login/registration) and delete on logout.
To set cookies for all sites from login.domain.com - all of the must sit on .domain.com and cookie domain parameter must be .domain.com
If your solution needs both api access (to the other applications) and access to the same database by several applications - you may need to deal with database transactions. This is because new registrations won't be visible on other sites until transaction is committed - so for example - you can not call api from within login code to retrieve cookies before committing the transaction with the new registration.
One important detail. If you already have users separately registered at site1 and/or site2 but not on both your signon site will either have to handle those cases or you'll need to sync registrations manually yourself upon deployment of your new registration system. Manual fix won't be possible when extra user input is required to complete the cross-site registration. This point also becomes important when you add new sites requiring some new user input for the registration.
Finally, carefully choose domain name handling OpenID. To the best of my knowledge it is impossible to transfer openid endorsements across subdomains without users consent - please correct me if I am wrong. You don't want to ask users to re-register just because you decide to rename the sub-domain.
server side include (ssi) method
Another solution is to inject those forms via sever-side includes into all sites. This may be considerably harder and will depend on the type of webserver in use and will work slower.
A pre-requisite here is that all your applications run on the same subdomain - so that openid works for all of them.
I've once built common user registration for MW (php) and cnprog (python/django).
My solution was to display the same exact registration form on the wiki and the forum site, while generating and processing this form with django. I did it this way because wiki and forum "skins" are so different that I did not want to surprise visitors with the dramatic change of site appearance when they go to the registration page. This is complicated and I will not do it again :) and instead would go with single sign-in method.
in order to display django output through mediawiki I've created a wiki extension printing apache "include virtual" call to glue django-generated content with the wiki output. This comes with problems.
Apache include virtual on my installation cannot POST to subrequests and cannot pass cookies from subrequests and cannot pass redirect responses (all http headers will be thrown out) to the upstream user requests.
So I've added "was_posted=true" to mark the posts for django and a secret code to prevent cross-site forgery. To get the cookies out - had them printed with cookie_morsel.output_js() in python. So javascript must run on the client for this to work. Any redirects will have to be done with javascript too. Extra work will still be needed to upload files (like avatar picture).
So single sign-on may be the best solution.
ajax may be a neat way around - just build forms in all of your sites with javascript and submit them via ajax. Will work fast and will not break appearance of your various sites,
but this won't please the folks allergic to javascript.
Actually, the only method that does not require any javascript is single sign-in site.
Posted this because I've spent enough time building this thing for MW and django - an hour of typing did not make a difference :).