I have a client that keeps getting the customer service reply to emails in his mail box when they should be going to the customer service email. I've searched everywhere for record of his email and it is nowhere. I am guessing now that because the customer service emails are of a different domain the replies are getting marked as spam and being sent to the server admin account instead. I have downloaded this extension: http://www.magentocommerce.com/magento-connect/ASchroder/extension/1865/aschroder.com-smtp-pro. Would a different domain email be SMTP? Advice appreciated.
We had this problem with a few of our recipients as well.
Mainly Comcast users and Century Link to name a few. What the problem is, is that you are sending from (for example) www-data#thisdomain (this will be the machines domain name ie. www-data#WebServer01) -- in the header, regardless of who is in the FROM field. Your actual domain in the FROM field is customer_service#yourstoredomain.com. You will need to do one of two things.
If you host the Magento install on your own operating system and you have control of it, you'll need to change the machines hostname to match that of your web domain name. ie yourwebsite.com.
If that isn't an option, then you will need to use a Magento plugin like the one you mentioned, and have it log in via SMTP to your email service provider (We use Office365) and send the email from a "real" email address that you have created.
The reason this fails is due to the SPF record on the providers (ie Comcast CenturyLink) not allowing emails from a domain that is other than that which is specified in the header. This is usually to prevent spam etc to their customers. So companies like these simply block or, in some cases, redirect that email back to the user at the originating FROM domain.
If at all possible, the easiest route is going to be to try to change the domain in the header of the email. Hopefully you manage your own operating system so you have control over this. IF not, try to see if your hosting provider will provide you access to a "jailed" area so that you can change said settings. The SMTP route is NO FUN ...
Related
I've looked at similar questions and AWS documentation, but so far I don't know what the issue can be.
In my SES dashboard, I have two verified identities.
example#abc.com
xyz.com (uses easy DKIM and Custom Mail From). All DNS entries have been created.
Using my Laravel 9 application, I'm able to send emails using the verified email address, but using the domain, no errors are thrown, and no email gets delivered either.
Both scenarios use the same IAM user API keys and permissions.
The email I'm using to send from the domain is noreply#xyz.com which is not a real email. And the Custom Mail From I've specified is mail.xyz.com. As I mentioned, I can see all the DNS entries have been created for the domain.
I am developing an ASP.NET Core web application with user management functionalities. My question is about the email address changing algorithm. Almost every web app I saw before have the following flow:
User authorized
User requested an email address change
User received a message on the new mailbox with the confirmation link
User clicks the link and the email address updates
But I think, this algorithm might be a bit insecure and that is what I want to discuss here.
How about this flow:
User authorized
User requested an email address change
User received a message on the old mailbox with the confirmation link
User received a message on the new mailbox with the second confirmation link
User clicks the link and the email address updates
With this additional step in the middle of the algorithm, things may be much better from the security perspective, but would it be too complex or not? How do you think what algorithm I should implement? And what would you prefer if you will be in my shoes?
The second options might sound great, and it's not too much headache to implement too. But I'll stick with the first approach due to some reason:
Common work flow pattern.
As the backend side can be wrote by many language, by various developers, so common pattern would make things more standard when we need some kind of migration, and even maintaining by new developer. If the project doesn't require ultra-secure authentication flow, the simplicity of first approach was enough.
From user convinient pespertive
Let's just imagine when changing an email address, what case the user likely want to change email address ? I was register my facebook account long ago using yahoo mail, that's no-longer active, and i need to switch to a gmail one. What's the point of sending the email back to the old one ? Cumbersome... and i can do nothing in this case except get some help from the staff.
I totally aggree with the second approach on security angle. But that's not suitable for most of the case, only implement if the project have some requirement. And even in that case, I suggest don't even do that too, build some thing like sub-admin account role and grant permission to someone have responsible. Like Google enterprise email organize some account called admin if anything wrong happen to user account. As long as it has this kind of security level requirement, it's not gonna serve massively user.
The intension of all the flow
The User got authorized first, right, that's mean we Identified what the user are, and what she capable to do. Imagine when we hide a hotel room then request to change to another due to some reason. What's the point of proving that's I booked my own room, since we all know that's the fact ? Kinda weird... right ?
To conclusion, I think we shouldn't mess with something that's become common pattern that widely acknowledged, except we have some special requirements and the project have something uniquely to satisfy, and we consider ourself, as developer that's reasonable.
The main problem with this approach is: what happens if the user no longer has access to their original email account? Perhaps it was a work/school/uni account that they no longer have, or perhaps they've just forgotten their password or otherwise lost access to it.
With your second approach, they are not going to be able to update to the new account, because they'll never receive the first confirmation link.
How about the following approach instead:
User requests an email change.
Require the user to re-authenticate with their current password (just like when they change their password).
Send a confirmation link to their new email.
Send a notification to their old email, with the details of the change, and instructions of what to do if they didn't initiate the change.
User clicks the link to update or contacts your support to say their account has been compromised.
This way you still provide them with an alert that someone is trying to change their email (and potentially a means to stop it), but a user who has lost access to their old account will still be able to update their email.
The Forgot Password link in our Prestashop 1.7 site is not working. After setting the admin email on the following, we still do not receive any reset password
Shop Parameters > Contact > Stores tab: <set the admin email>
When I try to send a test email using the links below, I receive the test email
Advanced Parameters > Email > Test Your Email Configuration
I am able to receive a test email from the admin email address I set on Shop Parameters. So that means, the email sending is working.
On the Forgot Password page, I entered my email and clicked the Send Reset Link. I checked the Inbox and Spam and did not see any reset link email.
Do you check that you have a mail template for sending forgotten emails in the corresponding language folder?
Regards
I'm having the same issue (Prestashop 1.7.2.5) From what I can find, if your email setup is configured as PHP, Password Reset works only occasionally depending on email account you are sending to.
It is better to configure your email setup for SMTP. Due to the high amounts of spam being circulated, most email servers will flag email sent from PHP as potential spam and most times will be blocked and not even sent to the junk folder. The fact that some mail gets through and others just disappear is because Spam traps set thresholds. Depending on the body text, subject line, type of links, etc.
Make sure your theme have mails folder and have password_query mail templates in
corresponding language folder.
Go to Preferences > Customers, and check the value of password reset delay. Make the delay value higher like 360 minutes.
I am using SparkPost to handle all my email. I already have verified the domain and everything but recently I transferred my domain to another hosting site do I need to verify the domain there?Thanks in advance
Is it possible to create an order for guests in the backend without the customer email?
I know how to create orders for registered or new users but most of the time I need to create an order without knowing the customer's email.
Thanks
Without making changes to the code, you could achieve this by using an internal convention (similar to #Joseph's answer but a little cleaner) e.g.
firstname.lastname#guest.insertstoredomainnamehere.com
You could configure your mail server or MX records to drop emails sent to the "guest." subdomain.
Magento requires an email address to complete an order (and uses that email address elsewhere, depending on it entirely). You could hack it by using some store email address or a temporary email address, but you'll have to enter one.
If you remove the javascript required field validation from the email address when placing admin orders, Magento will generate a dummy email address for the customer.
This functionality looks to be deprecated as of 1.4.0.0 so test this on your version.