Persistent issue with internal SMTP emails (order notification)

[Scratchilito]

Hello Phoenix Cart Team,

I'm seeking your expertise for a long-standing issue regarding order notification emails, which I've experienced across several versions of Phoenix Cart (I recently upgraded to v1.1.0.6).

My Setup:

• Phoenix Cart Version: 1.1.0.6

• Host: Infomaniak (Switzerland)

• Email Configuration: SMTP. In an attempt to resolve this, I installed the SMTP-Auth v1 addon, but the behavior remains the same. The credentials are valid.

• Payment Modules: The issue occurs with offline payment modules like moneyorder.php (and custom versions based on it).

• DNS Configuration: SPF and DKIM records are correctly set up for my domain and have been validated by external tools.

The Problem in Detail:

The issue only occurs when sending the order notification to the administrator, depending on the email address set in "Configuration > My Store".

Here is a summary of my tests:

• Test 1: Notification to an external address (Yahoo)

- Setup: Admin email address is set to my-address@yahoo.com.
- Result: SUCCESS. After an order is placed, the notification email is sent and received perfectly.
- Conclusion: The shop can authenticate with the SMTP server and send emails. The notification trigger itself is working.

I should clarify that I do not wish to use this as a permanent solution, as my Terms of Service state that my business email is shop@mydomain.fr, and it is also more professional to use it.

• Test 2: Notification to an internal address (on the same domain)

- Setup: Admin email address is set to shop@mydomain.fr. (That I want!)
- Result: FAILURE. After an order is placed, no email is received at this address.
- Conclusion: The problem occurs specifically when Phoenix Cart attempts to send an email to an address on the same domain as the sender.

• Test 3: Host's Server Test (to rule out a server issue)

- Action: I used an external email client (Thunderbird) to send an email from shop@mydomain.fr to shop@mydomain.fr using the exact same SMTP credentials.
- Result: SUCCESS. The email was sent and received perfectly.
- Conclusion: My host's server allows this type of "send-to-self" routing.

Important additional context: Email communication works correctly in other parts of the shop. Customers can send me emails to shop@mydomain.fr from their account area, and I can send them emails from the admin panel (which is configured with shop@mydomain.fr as the sender). Therefore, the issue is truly isolated to the automatic order notifications.

Problem Summary:
The issue, which has persisted through Phoenix Cart updates, seems to be in how the shop builds the email when the destination is on the same domain as the sender. The email generated by Phoenix Cart is likely considered "suspicious" by the sending server and blocked, whereas an email from a robust client like Thunderbird (with more complete headers) is accepted.

Have you ever encountered this scenario? Is there a specific configuration or a known code modification to force the creation of more robust email headers, so that the SMTP server will accept these internal emails?

Thank you in advance for your help.

[BrockleyJohn]

It is quite common for hosting platforms to treat as spam emails sent from the platform with the from and to addresses the same, so I am not surprised that the sendmail is blocked.

However it makes no sense to me that the SMTP addon is handled differently to Thunderbird - this I have never come across.

My suspicion would be that the order emails are not being sent by SMTP but still by sendmail.

As an aside, there's no reason I can see that your copy emails must be sent to shop@domain.fr - why not orders@domain.fr? No one sees it but you.

[azpro]

Therefore, the issue is truly isolated to the automatic order notifications.

You "think" or you "know" - that's a big difference - espacially for debugging. Just do not "Jump to conclusions" - you will miss the obvious ... Happened a lot to me in the past.

Can't really help you on the technicalities - but hope this helps!

A

[Scratchilito]

Hello @BrockleyJohn and @azpro,
Thank you both for taking the time to reply. I appreciate you trying to help. Let me clarify a couple of points based on your feedback.

As an aside, there's no reason I can see that your copy emails must be sent to shop@domain.fr - why not orders@domain.fr? No one sees it but you.

You are right, the name of the email address itself is not critical. My apologies if I wasn't clear. The core issue remains the same whether I use shop@mydomain.fr, orders@mydomain.fr, or any other address. The problem specifically occurs when the notification email is sent to any address on the same domain as the sender. The successful test to an external @yahoo.com address confirms this.

You "think" or you "know" - that's a big difference - espacially for debugging. Just do not "Jump to conclusions" - you will miss the obvious ... Happened a lot to me in the past.

You make a fair point about the difference between "thinking" and "knowing". The reason my post is so detailed is precisely to move from "thinking" to "knowing" by eliminating variables one by one.
Your analogy is a good one, but I see it from the patient's perspective: I am describing all the symptoms to the doctors (the developers here) as precisely as I can, so they can make an accurate diagnosis. I have confirmed what works (sending to Yahoo, sending from Thunderbird) and what fails (automatic notifications to the same domain). The one thing I don't "know" yet is why it fails, and that's where I'm hoping the core developers' expertise can shed some light.

Based on the tests, the only remaining variable seems to be the way the Phoenix Cart notification email is constructed, which might be perceived differently by the SMTP server compared to an email from a client like Thunderbird, but only during internal routing.
I hope this clarifies my methodology. I'm looking forward to any technical insights on this specific scenario.

[BrockleyJohn]

Turn on debug and compare the logging for an email that you receive and one that you don't.

If you haven't found it yet, in the override for the phoenix email class line 40, change to

Code: Select all

    private $debug = 1;

The debug output will go to your php error_log file

[ecartz]

The people to help you with this are whomever manages the emails for mydomain.fr

I very much doubt the email headers have anything to do with this, as you say that you can send emails from admin manually. It's only order notifications that are a problem.

What's different between order notifications and other emails? Not the headers (incidentally, you should be able to check for differences there by looking at the raw emails) but the content. In particular, what is different between order notifications for moneyorder.php and other payment modules? The moneyorder.php has a section that says something like "Mail your check to this name and address." Apparently that looks like spam.

To confirm this, order something with a test account whose address is my-address@yahoo.com

You should get two emails. One to my-address@yahoo.com and one to shop@mydomain.fr

If you get the first (yahoo) but not the second, now use Thunderbird to send an email with the identical content to shop@mydomain.fr, particularly the "Mail your check to this name and address" part. I strongly suspect that you won't get the email, because it doesn't like that content as it looks like fraud (don't use your credit card with anti-fraud on it; instead send a check manually with no fraud protections).

You could further check by using Thunderbird to send from a different email address (not mydomain.fr) to shop@mydomain.fr -- I suspect that this would also fail if it uses the same content. I.e. it may not be the self-to-self email routing that's the issue, but purely the content of the email.

If this is the problem, then you have at least three options:

1. Switch hosts.
2. Make your host fix it.
3. Turn off SEND_EXTRA_EMAILS_TO, duplicate the order notification email module, remove the part that puts in "Mail your check to this name and address" from the second module's template, change the TO address to the store's admin email, and install the duplicate module. Yes, you can have multiple notification modules enabled at once for a particular notification type. One (the original) sends to your customer; the other (the duplicate) sends to you. Presumably, you already know your name and address, so you don't need that in your email.

Note that these won't fix the problem of your customers not receiving the email. They only fix the problem of you not receiving the email.

[Scratchilito]

Hello everyone,

First and foremost, I want to extend a warm thank you to @BrockleyJohn and @ecartz for your quick responses and insightful suggestions.

To provide some context, my choice to base my modules on moneyorder is related to historical French purchasing habits, such as payment by check. I have been using these custom modules for many versions of Phoenix Cart.

Both of your suggestions arrived at nearly the same time. To avoid getting sidetracked, I decided to first follow the path suggested by @BrockleyJohn, which was to enable debug mode with private $debug = 1;.

This path proved to be decisive and led me to the solution.

The Final Diagnosis:

Thanks to the debug log, I was able to determine that the issue was not that the email was being blocked, but that the trigger to send it to the administrator was entirely missing. The confirmation email was being sent correctly to the customer, but the copy for the shop owner was never even attempted.

The Solution:

The problem stemmed from the fact that the moneyorder module (and my derivatives) does not, by default, contain the code to notify the administrator. The solution was to manually add this trigger by integrating the following after_process() function into my payment module files (moneycheque.php and moneybank.php who are my personalised clones):

Code: Select all

public function after_process() {
    // This function forces a second email to be sent to the store owner,
    // as it is not triggered by default in this module.

    $email_subject = "New Order Notification";
    $email_body = "A new order has been placed on the shop. Please log in to the admin area to view it.";

    $email = new Email();
    $email->add_text($email_body);
    $email->send(
        STORE_OWNER,
        STORE_OWNER_EMAIL_ADDRESS,
        $email_subject,
        STORE_OWNER,
        STORE_OWNER_EMAIL_ADDRESS
    );

    return false;
}

With this code in place, I now receive a simple but reliable notification for every order, which was my main goal.

@ecartz: Your hypothesis about the email content potentially being a spam trigger was very insightful and would have been my next testing step. However, in my case, the debug log proved that since the email was never sent, it couldn't have been filtered. This is a very important point to keep in mind for other deliverability issues.

Thank you both again for your valuable help, which set me on the right track. The issue is now resolved.