Closed Error 550 not in bounce log

beerForo

beerForo

Well-known member
Licensed customer
Affected version
2.3.9
"Email to * from * failed: Expected response code "250/251/252" but got code "550", with message "550-The mail server could not deliver mail to *. The 550-account or domain may not exist, they may be blacklisted, or missing the 550 proper dns entries."

Why do these show up as server errors, but not logged as a bounce, so our email lists are not kept clean? These users stay in the Valid state and these do not appear in the bounce log. (Also a 451 error.) I understand they may not "bounce" but why are the users still marked Valid?
 
Last edited:
Yes, that should be processed as a hard bounce.
Other 550 errors are processed in the bounce log, but often erroneously processed as soft bounces instead of hard bounces.

See:
Alpha1

Fixed Thread '550 permanent failure processed as Soft Bounce'

This bounce message is incorrectly processed as a Soft Bounce:
Code: 
Action: failed
Final-Recipient: rfc822; xxx@evansinc.com
Diagnostic-Code: smtp; 550 permanent failure for one or more recipients (xxx@evansinc.com:550 5.4.1 Recipient address rejected: Access denied. For more information see https://aka.ms/EX...)
Status: 5.3.0
This clearly should be treated as a hard bounce.
Alpha1

Fixed Thread '550 'Account Closed, Please Remove' processed as Soft Bounce'

Clearly this should be a hard bounce:
Code: 
Action: failed
Final-Recipient: rfc822; xxx@comcast.net
Diagnostic-Code: smtp; 550 5.2.0 <xxx@comcast.net> - Account Closed, Please Remove
Status: 5.2.0
xenforo.com

bounce handling

xenforo.com xenforo.com
 
Can you confirm if you are seeing this fixed now?

The thread linked has a Fixed tag and says: Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.3.10).

However, in 2.3.10 it still logged a "550-The mail server could not deliver mail to" as a server error, but not in the bounce error log.

1.) Are there some 550 mail errors that will still not be handled by the bounce handler (this one didn't bounce back to the bounce mailbox; instead this failed to send because it was rejected by the remote mail server so it couldn't be sent)
2.) would these show up in the bounce email log, or no?
 
I noticed this again when upgrading from 2.3.10 to 2.3.13 today --
Under Server Errors have been logged there are a few "550-The mail server could not deliver mail to ..."

Is there a way to get such SMTP errors where a "550-The mail server could not deliver mail to..." is returned upon SMTP to go to the XF bounce handler instead of being logged as an XF server error?
 
Automated triage: Design issue

Thank you for reporting this issue. Bounce handling only processes bounce messages that arrive in the bounce mailbox. When the remote server rejects an email while it is being sent, no bounce message is created, so the rejection is only recorded as a server error and the user's state is not changed.

This is an automated assessment. A member of staff may review and update it.
 
That is the technical explanation but not the logical one, which would be to set the user to "User state: email invalid" because it is literally an invalid email there is a user state for that, and so our mailing lists are clean.

This was the more important part...
beerForo said:
These users stay in the Valid state
Click to expand...
...not that is needs to be in the log.
 
Last edited:
It seems to me that a Design issue means a Software Functionality Design issue. I.e. issues in this classification are not a code quality bug, but caused by the way XenForo Functionality is designed. Functional Design choices can lead to unwanted and unforseen consequences.

Such Design issues may still need to be addressed, but the XenForo team may prefer to do so on second point releases instead of minor releases .

Maybe the XenForo team can elaborate on this.
 
Alpha1 said:
Does the bot read related bugs if they are linked in the thread? It seems not.
Click to expand...
Yes it does; although it may not understand EMBED BB code yet. That being said, the linked threads are only tangentially related. Yours were real bugs in actual bounce processing. This bug report is not about automated bounce processing. It’s about an immediate email sending response that happens when the email is being sent.
 
Alpha1 said:
Such Design issues may still need to be addressed, but the XenForo team may prefer to do so on second point releases instead of minor releases .
Click to expand...
It's been moved to Resolved so I assume that means no further action, which is why the prefix is confusing.
 
Design issue generally means we acknowledge it doesn’t function in the way you expect and we may, if we were rewriting it or extending in future, reconsider it, but for now it’s not being considered as a bug we can or would want to fix.

Posting a suggestion is a valid next step.
 
Tbh I could see us trimming down the number of closure prefixes we have. There’s nuance in all of them but some of them do amount to the same thing.

I do think a few of our closure statuses could just be encapsulated quite simply as “Closed” 🤷‍♂️
 
As the suggestions forum and guidelines work now, in many cases there's very little point to post a Design Issue / Design Flaw as a suggestion. Because they are likely to be marked duplicate if there's something similar and will rarely attract votes. Then they are automatically binned. Its a non-starter in most cases IMHO. Design issues have always been an odd class that are neither suggestions, nor code bugs, but can still result in unwanted and buggy results.

I hope that the XF team will keep Software Design Issues as a separate class, so that these can be easily found, re-evaluated and eligible issues addressed when there is time to do so. With the help of LLM I'd expect that the future will allow for addressing more issues than before.
Its nice to see XF going through the backlog of bug reports. Maybe at some point after the backlog is cleared, it would be nice if the design issues can be considered.
 
I would say even "Design issue" was generous tbh. I'd have closed it as "As designed" or “Not a bug” (under the original prefixes).

At the end of the day, this thread is not reporting a bug in the bounce handling itself, automated bounce handling and logging is working correctly. But those bounces come in from the bounce handling system itself. Connection level failures are technically not bounces. It's not like the email ever successfully sent. It isn't a bounce. It doesn't belong in the bounce log.

What does the bounce log help with? Well it notifies a user that you’re sending email to a problematic address and action needs to be taken.

In this case, the email never gets sent and it gets rejected immediately and you get notified immediately as it’s in the server error log.

The equivalent work is basically 90% done at that point. You’d just need to manually set an account as bounced or reject the account or whatever is appropriate.

I don’t see that automatically being the responsibility of anything to do with the bounce log or automated bounce handling.

So at best it’s a suggestion. And you’re right to imply it’s a low priority one at best. It’s really not worth a debate over.

That’s the decision, post it as a suggestion or don’t. But it’s not a bug.
 
My comments were intended as general remarks about Design Issues. The current thread is not the best example of it. I hope that issues that are true Software Design Issues will someday be queued for evaluation.
 
Automate the Injection (Recommended)
If you have a large number of these errors and do not want to send emails manually, you can parse your XenForo server logs or mail logs (/var/log/mail.log or Exim/Postfix logs) using a simple script.
Below is an example of a Python script you can run on your server to find 550 delivery failures and automatically forward them as formatted bounce emails to your XenForo bounce address:

Python: 
import smtplib
from email.mime.text import MIMEText

# --- CONFIGURATION ---
SMTP_SERVER = "localhost"
SMTP_PORT = 25
BOUNCE_TARGET_EMAIL = "your_bounce_box@yourdomain.com"  # Your XF bounce email address
# ---------------------

def inject_fake_bounce(failed_user_email):
    bounce_body = f"""Action: failed
Final-Recipient: rfc822; {failed_user_email}
Status: 5.5.0
Diagnostic-Code: smtp; 550 Forced injection from synchronous SMTP error log."""

    msg = MIMEText(bounce_body)
    msg["Subject"] = "Delivery Status Notification (Failure)"
    msg["From"] = f"bounce-daemon@{SMTP_SERVER}"
    msg["To"] = BOUNCE_TARGET_EMAIL

    try:
        with smtplib.SMTP(SMTP_SERVER, SMTP_PORT) as server:
            server.send_message(msg)
        print(f"Successfully injected bounce for {failed_user_email}")
    except Exception as e:
        print(f"Failed to send injection email: {e}")

# Example usage:
# You can tie this into a log-parser loop that extracts failed emails.
# inject_fake_bounce("user-to-remove@domain.com")

Setting Up the Cron Job

Because 550 errors happen throughout the day, you should run the script frequently (e.g., every 5 to 15 minutes).

1. Prepare the Script on Your Server

Save your completed script on your server (for example, at /opt/scripts/xf_bounce_injector.py) and make it executable:
bash
chmod +x /opt/scripts/xf_bounce_injector.py
Use code with caution.

2. Open the Crontab

Open your server's cron configuration tool as a user who has permissions to read the mail logs (often root or a user in the adm group):
bash
sudo crontab -e
Use code with caution.

3. Add the Cron Line

Add a line at the bottom of the file to run the script.
• To run it every 10 minutes:text
*/10 * * * * /usr/bin/python3 /opt/scripts/xf_bounce_injector.py > /dev/null 2>&1
Use code with caution.
• To run it once an hour (at the top of the hour):text
0 * * * * /usr/bin/python3 /opt/scripts/xf_bounce_injector.py > /dev/null 2>&1
Use code with caution.
(Note: /usr/bin/python3 is the standard path, but you can verify yours by running which python3 in your terminal).
To make the script fully functional for your specific server, where are you currently seeing these 550 errors?
• In the XenForo Admin Control Panel under Server Error Logs?
• Inside your server's Postfix/Exim mail logs (e.g., /var/log/mail.log)?
If you let me know, I can provide the exact code needed to read those logs so you can plug it straight into Cron.
Click to expand...
 
Last edited:
Back
Top Bottom