Mail stuck after queue but before delivery (dovecot/exim setup)

[harro]

Hi all,

after some strange problem my exim (and some other files) changed ownership and as a result Exim could not deliver emails into the recipients mailboxes during this time.

I fixed the ownership (back to root.root and chmod 4755), but there are about 50 emails that have been processed by the exim.in part (so scanned and accepted) that have not been delivered to the users though! (this set-up of having two instances of Exim is to do with Mailscanner or Dovecot, I forgot which).

I tried to tell exim to work on the emails again (eg. "exim -M <msg-ID>), but since the mails are not in the /var/spool/exim.in/input dir anymore, they are not in the mail-queue anymore either!

So my question is... how do I get the emails from the /var/spool/exim/input folder to the recipients' maildirs?

I use exim and dovecot. Maybe I need to use dovecot to process the mails? I really don't know how this works

I hope one of you can shed some light on my problem - thanks!

Harro

 

[harro]

I am still interested in hearing how the 'proper' solution works...

but what I did first for the most important emails (what a horrible task, to go through 50 emails in the shell), is to remove the line containing "-frozen" from the <mail id>-H file. Then I moved the two files (ending with -H and -D) to the /var/spool/exim.in/input/ folder and it was delivered.

For the rest I did:

cp -p <mail id>-* /var/spool/exim.in/input && exim -Mt <mail id>

This thawed (unfreeze) the emails too. Had to give the command in one line otherwise the copied email would be gone already before I could issue the exim -Mt command.

This is not something I'd wish anyone else to do ... hope this never happens again!!

I wonder why it is not possible to thaw/unfreeze files that are in the /var/spool/exim/input folder?

Bye,

Harro

 

[pucky]

Hi all,

after some strange problem my exim (and some other files) changed ownership and as a result Exim could not deliver emails into the recipients mailboxes during this time.

I fixed the ownership (back to root.root and chmod 4755), but there are about 50 emails that have been processed by the exim.in part (so scanned and accepted) that have not been delivered to the users though! (this set-up of having two instances of Exim is to do with Mailscanner or Dovecot, I forgot which).

I tried to tell exim to work on the emails again (eg. "exim -M <msg-ID>), but since the mails are not in the /var/spool/exim.in/input dir anymore, they are not in the mail-queue anymore either!

So my question is... how do I get the emails from the /var/spool/exim/input folder to the recipients' maildirs?

I use exim and dovecot. Maybe I need to use dovecot to process the mails? I really don't know how this works

I hope one of you can shed some light on my problem - thanks!

Harro

exim.in? There is no such directory unless you followed one of those HOWTO's on the forums where exim.in was created for mailscanner.

To fix perms you need to;

chown -R mail:mail /var/spool/exim
chown -R root:daemon /var/spool/mqueue

Then restart exim. I really wouldnt be fiddling with existing incoming outgoing email if was you. Just change the perms and relax.

 

[harro]

Thanks for your help Pucky!

I do indeed have the set-up for MailScanner and therefore the exim.in and exim.

Because of this I could not unfreeze/thaw emails that had been semi-processed (they end up in a different directory, namely /spool/exim/input, not /spool/exim.in/input (needed as the input directory in this set-up).

The mails that got 'caught' in the middle would never have been delivered without manual intervention, so I had to do something. Of course I will not meddle with emails while everything is working fine

Once again, thank you.

Harro

p.s. my /var/spool/mqueue is actually called /var/spool/mqueue.in because of the exim.in