News:

Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

450 Message not queued: recipient is suppressed

Started by nc3man, January 28, 2025, 02:44:24 PM

Previous topic - Next topic

nc3man

When a new post occurs on our forum, we always get a few (maybe half dozen out of a few hundred subscribers) messages in the error log: "450 Message not queued: recipient is suppressed".   Clearly some notifications are not going out. Sometimes I can guess by looking at items in the mail queue that have not been pushed out. If I look at the activity on our 3rd part mail service,  many folks have received their notifications, so there are just a few having  difficulty. I would like more information beyond "recipient is suppressed." How can I find out which recipient this refers to, so that I can figure out if they have a bad email or whatever?

[added] full message: "Ran into problems sending mail. Error: 450 Message not queued: recipient is suppressed"

nc3man

from backtrace:
Called from /home/nccc/northcountycycleclub.org/smf/Sources/Subs-Post.php on line 1544

nc3man

The upstream call in the backtrace to Subs-Post is
#1: smtp_mail()
Called from /home/nccc/northcountycycleclub.org/smf/Sources/ScheduledTasks.php on line 795

Examining the code there, failed emails to a recipient are tried a few times, but if errors continue, it looks like the failed email is placed manually onto the unsent Mail Queue. If that's the case, then that would have to be all I check. Correct?

Aleksi "Lex" Kilpinen

That's a hard one - A 450 should usually be a temporary issue, not a failure code, and as such you shouldn't have to do anything. "Recipient is suppressed" however usually means that your mail provider has refused to relay messages to the intended recipient, because they have already tried and failed enough times to not try again.

Since it's a temporary issue code though, I think you should find the message(s) stuck in your forum's mail queue Admin -> Maintenance -> Mail -> Browse queue, as SMF should keep them there to try again later.

4** (Transient Negative Completion Reply): The command was not accepted, and the requested action did not occur.
However, the error condition is temporary, and the action may be requested again.

5** (Permanent Negative Completion Reply): The command was not accepted and the requested action did not occur.
The SMTP client SHOULD NOT repeat the exact request (in the same sequence).
Slava
Ukraini!
"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

How you can help SMF

nc3man

Thanks for that reply. It turns out there was just a single email that was stalled in the mail queue and when I forced a resend, it just generated a few more of those 450 errors. Obviously that email was the fault so I just disabled notifications for that user who hadn't been engaged in a couple years anyway. So, I will just continue to browse the mail queue as you suggest when and if these occur in the future.

nc3man

I would add that an improvement would be to replace the unknown "recipient" with either the user name or the email generating the message.

Aleksi "Lex" Kilpinen

Quote from: nc3man on January 28, 2025, 05:01:17 PMI would add that an improvement would be to replace the unknown "recipient" with either the user name or the email generating the message.
That's an SMTP error, so the contents of it are not up to SMF.
Slava
Ukraini!
"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

How you can help SMF

nc3man

I shouldn't have said replace "recipient." It seems to me that SMF in source/ScheduledTasks.php(795) understands when this condition occurs, so why not append the username or email to the admin error log entry?

Aleksi "Lex" Kilpinen

I'm not saying it's impossible, and I haven't checked the routine - but I believe we currently simply catch the error message, and SMTP error messages do not usually include those details. It's simply a one row response including a response code, possible status code, and text explaining the first two.
Slava
Ukraini!
"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

How you can help SMF

nc3man

Understood, but prior to the smtp call, all the data is in the header, and when the error is received, it seems like info from the header could be added to the exception handler which is generating what we get in the admin error log. Since I'm unfamiliar with SMF exception architecture, I don't know whether it's easy or not. Whenever I undertake exception handling, I find it useful to provide data so that the person receiving the error can take corrective action. In this case, it seems like browsing the mail queue is a good clue, but for us, seeing a number of these messages only raises questions about the real source of the error and what corrective action we can take other than reporting to this forum. Since I found no issues similar to ours searching this forum, perhaps ours is simply a rare use case and not worth the effort to improve the error message.

Aleksi "Lex" Kilpinen

@Sesquipedalian You might be more familiar with this than I am, thoughts?
Slava
Ukraini!
"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

How you can help SMF

nc3man

Here is a quick hack which uses a global (bad practice) to get the mail_to variable into the log message. In the server_parse function in Subs-Post.php which is where our 450 error message originates, I appended this global to the log message as so:

    if (substr($server_response, 0, 3) != $code)
    {
        log_error($txt['smtp_error'] . $server_response . $khr_mailto);
        return false;
    }

$khr_mailto is global to the functions in Subs-Post.php and it is set to the variable $mail_to in the smtp_mail function. An arguably better way to do that would be to pass $mail_to in as an extra argument to server_parse.

nc3man

Using a test "sandbox" board watched only by a membergroup of a couple test accounts, one with a bogus email "[email protected]" the update described provides the data to diagnose the issue.


Aleksi "Lex" Kilpinen

At first glance, that looks like a good little improvement to me. Something like that with email errors could be useful.
Slava
Ukraini!
"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

How you can help SMF

nc3man

That is a simple change, but an OOP approach to an error handler that wouldn't rely on the use of globals would be cleaner. I know there is work going on for SMF 3.0 and perhaps that is already in the works. Even having to pass error strings in the large associative array $txt as globals everywhere might be nicer as private data in an SMF error handler. For now, I will keep these changes on our website (btw, all changes I make contain my initials "khr" to persist them over SMF upgrades that might wipe them out  8) )

nc3man

Should anyone care for full details, attached is the modified Subs-Post.php

Advertisement: