On Tue, Feb 7, 2023 at 5:41 AM Quelrond <quelr...@gmail.com> wrote: > Hello, > > We use several OpenSMTPD servers to relay mails from a PHP application > through an external relay. > > The problem is that *sometimes* we get "550 Invalid recipient" for 100% > valid destination addresses: > > Feb 6 15:37:43 <mail.info> mta8 smtpd[33893]: c56196830ac72397 smtp > connected address=10.192.20.131 host=<unknown> > Feb 6 15:37:43 <mail.info> mta8 smtpd[33893]: c56196830ac72397 smtp > failed-command command="RCPT TO: <to...@xxxx.xx> <to...@xxxx.xx>" > result="550 Invalid recipient: <to...@xxxx.xx> <to...@xxxx.xx>" > Feb 6 15:37:43 <mail.info> mta8 smtpd[33893]: c56196830ac72397 smtp > failed-command command="DATA" result="503 5.5.4 Invalid command arguments: > No recipient specified" > Feb 6 15:37:43 <mail.info> mta8 smtpd[33893]: c56196830ac72397 smtp > bad-input result="500 5.5.1 Invalid command: Pipelining not supported" > Feb 6 15:37:43 <mail.info> mta8 smtpd[33893]: c56196830ac72397 smtp > disconnected reason=quit > > (The domain xxxx.xx is an external valid domain, the IP address is present > in senders-consul table - see below) > > If I manually test the relay - it works perfectly. The same mail from app > will pass after some delay. > > .... > > The table senders-consul is refreshed regularly by an external script, > calling "/usr/local/sbin/smtpctl update table ..." after refresh. I > supposed that the errors are related to table update, but the log > timestamps don't confirm this. The logs of the script have no errors. > > The error comes ~twice per day on random destination addresses. The same > addresses work for other mails. > > Does anyone have an idea about any possible reason for this? > > Peter > > > > Thanks for the context.
This happens regularly, but you don't say if the times when the external script runs, is before, during, or after the mail log errors occur. Or maybe I'm not following what you are saying closely enough. You talk about expecting to see log errors (from the script?) which you don't. Are the times when the external script runs, low utilization times of the day, so that a stop/start of smtpd would be tolerable? If I were in your shoes, I would modify the senders-consul external script to create a new file, instead of directly updating the table file. Compare that new file to the old table file, and only if there is reason to update it, stop smtpd, update the file and then start smtpd again. What you've done in this step is make sure that you have a closed/complete replacement file, and you've determined that it needs to be updated, and you are doing the simplest workflow to update it possible. If something like that runs error free consistently, then you know that the update of that file is the root cause. Then consider if there are other workflow changes you want to do to improve it. Good Journey, -lenlynch
