Lähettäjä: Graeme Fowler Päiväys: Vastaanottaja: exim users Aihe: Re: [exim] SMTP error from remote mail server after pipelined MAIL
On 28 Sep 2019, at 07:48, necktwi via Exim-users <exim-users@???> wrote: > you made me to compramise my identity? does strace.log and exim.log even contain my private key?
No, he’s not “made” you do anything, he suggested some diagnostics be provided for the issue you’ve reported.
Luckily for you the message with the attachments has gone to Heiko directly but is stuck on the moderation queue for the mailing list, so I’ve checked it and there’s nothing compromising in there at all. I can release them to the list if you so desire.
Given Heiko is likely to be busy today running a release process, here’s the salient bits from your strace:
19:46:17 22980 locking /var/spool/exim/db/retry.lockfile
19:46:17 22980 locked /var/spool/exim/db/retry.lockfile
19:46:17 22980 EXIM_DBOPEN: file </var/spool/exim/db/retry> dir </var/spool/exim/db> flags=O_RDWR
19:46:17 22980 returned from EXIM_DBOPEN: 0x1263c60
19:46:17 22980 opened hints database /var/spool/exim/db/retry: flags=O_RDWR
19:46:17 22980 dbfn_read: key=T:mta7.am0.yahoodns.net:67.195.228.111:1iCT23-0004Cd-Hg
19:46:17 22980 dbfn_write: key=T:mta7.am0.yahoodns.net:67.195.228.111:1iCT23-0004Cd-Hg
19:46:17 22980 dbfn_read: key=T:mta7.am0.yahoodns.net:67.195.204.74:1iCT23-0004Cd-Hg
19:46:17 22980 dbfn_write: key=T:mta7.am0.yahoodns.net:67.195.204.74:1iCT23-0004Cd-Hg
19:46:17 22980 dbfn_read: key=T:mta7.am0.yahoodns.net:67.195.204.79:1iCT23-0004Cd-Hg
19:46:17 22980 dbfn_write: key=T:mta7.am0.yahoodns.net:67.195.204.79:1iCT23-0004Cd-Hg
19:46:17 22980 Berkeley DB error: BDB0058 page 36968: illegal page type or format
19:46:17 22980 Berkeley DB error: BDB0061 PANIC: Invalid argument
It’s successfully writing to the retry db, but then blows up.
Is /var, /var/spool or /var/spool/exim mounted on the SD card in your RPi rather than the external drive?
You still haven’t answered the question about how all these messages got into your system in the first place, which I would suggest is rather more troubling than not being able to deliver messages to remote systems that at present don’t want them…
