Hi Gilles, Ok. So course of action is indeed just to rm the files? Which works for me. ;)
Mischa > On 4 Jun 2020, at 05:16, Gilles Chehade <[email protected]> wrote: > > this is due to a short-coming with how inflight envelopes are handled: > > when a mail is passed from scheduler to mta, it is marked as "inflight" and > can't be removed until it comes back to scheduler. > > this is usually not a big deal because an envelope is marked inflight only a > few seconds usually... > > ... except that eric@ and I came with an optimization to avoid envelopes > going back and forth into the scheduler when they have multiple routes or > when there's a chance a route gets enabled soon, they are kept in the MTA for > a bit longer, but this means that they can't be removed either. > > we had discussed a quick fix for this but since the MTA layer is supposedly > going to be simplified a lot, it was not worth the effort. > > I don't know where eric@ stands wrt this as of today > > > On Sun, May 31, 2020 at 8:00 PM Chris Bennett <[email protected] > <mailto:[email protected]>> wrote: > On Sun, May 31, 2020 at 05:24:18PM +0200, Mischa Peters wrote: > > Hi All, > > > > I just noticed something strange on one of my mailservers running OpenSMTPd > > 6.7.0p1 (OpenBSD 6.7). > > The mailserver was trying to deliver a spam mailbounce to fedex, it kept > > failing so I removed it from the queue. > > The logs kept showing it was being delivered, eventhough nothing was > > showing in the queue. > > After a restart of smtpd the message did show up in the queue again. > > > > root@smtp1:~ # smtpctl show queue > > cd9b0933db878954|local|mta|auth|@|[email protected] > > <mailto:[email protected]>|[email protected] > > <mailto:[email protected]>|1590676002|1590676002|1590937323|0|inflight|99| > > > > root@smtp1:/var/spool/smtpd/queue/cd/cd9b0933 # smtpctl remove > > cd9b0933db878954 > > 1 envelope removed > > root@smtp1:/var/spool/smtpd/queue/cd/cd9b0933 # smtpctl remove > > cd9b0933db878954 > > 0 envelope removed > > root@smtp1:/var/spool/smtpd/queue/cd/cd9b0933 # ls -la > > total 52 > > drwx------ 2 _smtpq wheel 512 May 28 16:26 . > > drwx------ 3 _smtpq wheel 512 May 30 20:49 .. > > -rw------- 1 _smtpq wheel 316 May 28 16:26 cd9b0933db878954 > > -rw------- 1 _smtpq wheel 19296 May 28 16:26 message > > root@smtp1:/var/spool/smtpd/queue/cd/cd9b0933 # smtpctl show queue > > root@smtp1:/var/spool/smtpd/queue/cd/cd9b0933 # rcctl restart smtpd > > smtpd(ok) > > smtpd(ok) > > root@smtp1:/var/spool/smtpd/queue/cd/cd9b0933 # smtpctl show queue > > cd9b0933db878954|local|mta|auth|@|[email protected] > > <mailto:[email protected]>|[email protected] > > <mailto:[email protected]>|1590676002|1590676002|1590937456|0|inflight|1| > > root@smtp1:/var/spool/smtpd/queue/cd/cd9b0933 # ls -la > > total 52 > > drwx------ 2 _smtpq wheel 512 May 28 16:26 . > > drwx------ 3 _smtpq wheel 512 May 30 20:49 .. > > -rw------- 1 _smtpq wheel 316 May 28 16:26 cd9b0933db878954 > > -rw------- 1 _smtpq wheel 19296 May 28 16:26 message > > > > I assume this is not the expected result. :) > > What else can I collect to pinpoint what is going on, before I rm the files? > > > > Mischa > > > > > > I also had this same problem. I rm'd the files. > However, what is the right solution? > (I was in a big rush and had to quickly solve the problem.) > > Chris Bennett > > >
