magento 1.9.0.1 email notification not working - email

I have a pretty weird problem. When I get an order, the order mail is sent. Also all mails relating to the customer account are sent.
However, all notifications of status changes are not sent automatically, even though it is enabled accordingly in System->Configuration->Sales->Sales E-Mails (Set to Yes).
When I check the orders, even completed ones, I get the the note "Customer not informed".
If I let an order go through manually and check the box to send a notification, this notification gets through perfectly.
So the issue is really only the follow up e-mails with status changes. Do you have any idea?
Magento 1.9.0.1

Related

(Google Workspace) Email not being received from one sender only

I have a Google Workspace (I think that is what it is called) that I use to manage a private email address for a small business.
Everything has been working fine, and I can see the user (richard) in the admin area with associated email set up. I have sent test emails to and from their email account to make sure it is working okay and everything seems to be working fine.
I have two email addresses associated with the domain, for example:
emma#domain.co.uk (me) and
richard#domain.co.uk (richard)
I use the first email address as an admin account, and they use the second one.
They've had this email account for a long time, and have had no problems, however recently they have stopped receiving emails from one sender (their accountant).
I can still send emails to the account from my own personal email address to them, and they are receiving emails from other businesses, but just this one person is sending emails to them and they aren't being received.
Things I've tried:
Checked the spam/junk folders and no emails are there
Checked to make sure the sender isn't on the blocked list
Looked at the email logs as per this suggested article and don't see any record of the incoming email that has been sent
Sent a test email to account#accountant.co.uk and richard#domain.co.uk from emma#domain.co.uk and they both receive my email. When the accountant presses "reply all" the email only gets received by emma#domain.co.uk and never arrives at richard#domain.co.uk
Sent a test email from richard#domain.co.uk to account#accountant.co.uk and she receives the email. When she replies, he doesn't get the reply.
All I can think of is she has somehow blocked him via her email client, but I need to check out all the possibilities of it being a problem at our end as she's not great with email and not sure how I'm going to navigate that one :)
Any suggestions welcome!

Why does powermail send an email despite recognizing spam

We wanted to activate spam protection in EXT:powermail and implemented the example configuration from the documentation.
First we switched on the honeypot and the session check and the mails to us (administrators). After a few minutes we received some emails.
At first we thought it was just a transition, but unfortunately it didn't stay that way. We even contacted a website user by phone to see if he noticed anything when submitting the form (session check failed). But he hadn't noticed anything out of the ordinary. He also received a confirmation email and our recipient received the completed form.
Now our question: is it normal that the mails are sent despite a negative session check or honeypot (sometimes both together), or do we still have a configuration error? Why is an email sent at all if the form was detected as spam?
We use:
TYPO3 10.4.23
Powermail 8.2.3
Powermail will not send mails to the sender if the spam check is failing. There are a few checks which then lead to an spam-indication (from 0 to 100%). You can configure which check has which indication and when will be a stop in sending normal mails.
I would turn on logs or notification emails on spam for admins via TypoScript setup - see documentation https://github.com/einpraegsam/powermail/blob/develop/Documentation/ForAdministrators/BestPractice/SpamPrevention.md#configuration-via-typoscript

Magento 1.9.1 After change the order address from admin notification mail is not going to customer

On Magento system, I have placed a 1 order for wholesale customer from the admin. The customer receives a mail of new order place. After placing the order I notice the shipping address which I have selected is wrong.
I edit the shipping address and check on all the 3 checkboxes (Recalculate, Notification[customize],confirm update) below the update button. I have written a note on Notification [customize] section also. After clicking on update the message display “Order update, not yet applied. Customer has been sent an email with a confirmation link. Updates will be applied after confirmation.”
But the customer didn’t get any mail related to address change. We have used mandrill for sending a mail. I have checked is mandrill outbound but seems that the mail is not triggered from the Magento. Other than this mail all the mail is going to customer. Can anyone please tell me what is the problem? Why the address change/notification mail is not triggered from Magento ?
You can do this in this way by making a change in order.php go to this file-
public_html/app/code/core/Mage/Sales/Model/Order.php
create directory structure like this, then copy and paste the file to the path below.
public_html/app/code/local/Mage/Sales/Model/Order.php
Find the below code in that file and Make a change in file from
$mailer->setQueue($emailQueue)->send();
to
$mailer->send();

Cancel pending mail in Mandrill

For my Magento webshop I use Ebizmarts with Mandril to send autoresponder mails to customers. By an incorrect setting in Magento I activated accidentally an abandoned cart email sent to a large number of customers. I have tried to cancel sending. (there are still 2000 mails pending/ready to send) Unfortunately I can not find the option to delete the pending mails.
Meanwhile I paused the account so that no more e-mails are sent. Is this possible to delete this mailing?
If the emails are in the account's backlog, you can clear (delete) them all: https://mandrill.zendesk.com/hc/en-us/articles/205582587. If they're already on Mandrill's servers ready to be delivered (i.e. you see a status of "Sent" on the Activity page), there's nothing you can do/you can't 'cancel' them from sending.

Sending emails in web applications

I'm looking for some opinions here, I'm building a web application which has the fairly standard functionality of:
Register for an account by filling out a form and submitting it.
Receive an email with a confirmation code link
Click the link to confirm the new account and log in
When you send emails from your web application, it's often (usually) the case that there will be some change to the persistence layer. For example:
A new user registers for an account on your site - the new user is created in the database and an email is sent to them with a confirmation link
A user assigns a bug or issue to someone else - the issue is updated and email notifications are sent.
How you send these emails can be critical to the success of your application. How you send them depends on how important it is that the intended recipient receives the email.
We'll look at the following four strategies in relation to the case where the mail server is down, using example 1.
TRANSACTIONAL & SYNCHRONOUS
The sending of the email fails and the user is shown an error message saying that their account could not be created. The application will appear to be slow and unresponsive as the application waits for the connection timeout. The account is not created in the database because the transaction is rolled back.
TRANSACTIONAL & ASYNCHRONOUS
The transactional definition here refers to sending the email to a JMS queue or saving it in a database table for another background process to pick up and send.
The user account is created in the database, the email is sent to a JMS queue for processing later. The transaction is successful and committed. The user is shown a message saying that their account was created and to check their email for a confirmation link. It's possible in this case that the email is never sent due to some other error, however the user is told that the email has been sent to them. There may be some delay in getting the email sent to the user if application support has to be called in to diagnose the email problem.
NON-TRANSACTIONAL & SYNCHRONOUS
The user is created in the database, but the application gets a timeout error when it tries to send the email with the confirmation link. The user is shown an error message saying that there was an error. The application is slow and unresponsive as it waits for the connection timeout
When the mail server comes back to life and the user tries to register again, they are told their account already exists but has not been confirmed and are given the option of having the email re-sent to them.
NON-TRANSACTIONAL & ASYNCHRONOUS
The only difference between this and transactional & asynchronous is that if there is an error sending the email to the JMS queue or saving it in the database, the user account is still created but the email is never sent until the user attempts to register again.
What I'd like to know is what have other people done here? Can you recommend any other solutions other than the 4 I've mentioned above? What's a reasonable way of approaching this problem? I don't want to over-engineer a system that's dealing with the (hopefully) rare situation where my mail server goes down!
The simplest thing to do is to code it synchronously, but are there any other pitfalls to this approach? I guess I'm wondering if there's a best practice, I couldn't find much out there by googling.
My 2 cents:
Once you have a user sign up, never roll back the registration if sending the E-Mail fails. For simple business reasons: They may not come back or re-register if it doesn't work out at the first try. Rather tolerate an incomplete registration and nag the user to confirm their E-Mail address as soon as possible.
In most cases when sending an E-Mail goes wrong, your app will not get immediate feedback anyway - non-existent E-Mail addresses on valid servers will send back a "undeliverable" message with some delay; if the mail gets eaten by a spam filter, you'll get no feedback at all; in other scenarios, it may take several minutes (greylisting) to several days (mail server temporarily down) for an E-Mail to get delivered. A synchronous approach waiting for the delivery of the mail is therefore doomed IMO. Even an immediate failure (because the user entered a obviously fake address) should never result in the registration getting rolled back.
What I would do is, make account creation as easy as possible, allow the user access to the account before it is confirmed, and then nag the hell out of them to confirm their E-Mail (if necessary, limit access to certain areas until confirmation). I would prevent the creation of a second account with the same E-Mail, though, to prevent clutter.
Make sure you allow changing the E-Mail address even if the previous address hasn't been confirmed yet, and enable the user to re-request the confirmation message to a different address.