Hi, There is a minor bug in the logic of OpenSMTPD that can cause bounce warning messages to be generated at the wrong interval, (and with the wrong details of the delay).
This is tested and reproducible on OpenBSD 7.3, but it's actually been around for several releases. The bug is not likely to be triggered during normal operation, but might happen during troubleshooting of unrelated mail issues on the same system and cause confusion to users receiving erroneous bounce reports. To reproduce the issue, simply queue some mail that cannot be delivered immediately, (e.g. network is unreachable), and then repeatedly issue: # smtpctl schedule all ... to force re-delivery attempts, as might be done whilst trying to diagnose network issues, etc. Assuming that smtpd is running with the default config for bounce warn-interval, we would expect to have a bounce mail sent only after four hours. But in fact the warning is sent much sooner, after just a few forced re-schedules, yet the bounce message still informs the user that the mail has been queued for four hours. What is happening: The logic in scheduler.c which actually issues the bounce message checks for the following condition: si.nexttry >= (si.creation + env->sc_bounce_warn[i]) Every time the 'schedule all' command is issued and a delivery fails, the value of si->nexttry is incremented to a new timestamp. This new timestamp is __calculated as if the current value of si->nexttry has already been reached__ ... which is not the case when forcing an immediate re-schedule. In other words, issuing 'schedule all' will kind of 'fast-forward' through however many attempts _would_ have been made before sending a bounce, and then send a bounce, regardless of the _actual time_ that has passed since the mail was sent. There are several ways to fix it, but I'm not sure which would be preferred approach as I don't often touch the smtpd code or really follow development.
