On Sun, 07 Jul 2024 21:55:01 +0100, Qingyao Sun <sunqingyao19970...@icloud.com> wrote: > > Description: > I drafted a problem report with sendbug(1) and sent it. However, it did > not appear on > https://marc.info/?l=openbsd-bugs after a while, so I checked > /var/log/maillog and it > turns out that the message never went through due to some "Connection > timeout". Now > the text of the PR is lost and I have to rewriting everything. > > (Okay, it's actually still available in > /var/spool/smtpd/queue/1e/1ecd789e/message, > but accessing it requires root privilege, so let's not rely on that.) > > I think this behavior is confusing because sendbug(1) happily exited > with status 0 > after I sent the PR, so I just assumed everything went well. I didn't > expect that > smtpd(8) could sliently fail. > How-To-Repeat: > $ sendbug > Fix: > I propose a few options here for discussion: > 1. make sendbug(1) block on smtpd(8) until the mail goes through, and > then print > a URL of the message on > https://marc.info/?l=openbsd-bugs&m=XXXXXXXXXX as a > confirmation. > 2. move the temporary problem reports to /tmp/sendbug/p.XXXXXXXXXX and > never delete > anything in /tmp/sendbug. In this case smtpd(8) could still sliently > fail, but > at least we keep a copy of the message available (until reboot). >
When you run sendbug, it passes delivery of your mail to smtpd, which tries to deliver it. If something goes wrong, it puts a message in the queue. If a message is in the queue for some time, smtpd will send a warning email that delivery is delayed. By default, the warn message is sent after 4 hours of delay. See the bounce warn-interval option. If a mail has been in the queue longer than some time, it will be removed and an email will be sent that the message can't be delivered. The default TTL is 4 days, but you can increase it, see: queue ttl option. After your message is delivered to the mailing list, it needs some time to be processed and sent to marc.info. Yes, everything is asynchronous and can be delayed for minutes or hours. Such a design tolerates failures and unavailability of some servers, and what you're proposing is just the opposite. Your way means that if one server is down, no bug report can be sent until all servers are up and running. Frigiel design, isn't it? -- wbr, Kirill
