Re: [exim] retry timeout exceeded

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Jacco van Gent
Date:  
À: Exim-users
Sujet: Re: [exim] retry timeout exceeded
On 2014-03-30 17:29, Evgeniy Berdnikov wrote:
> On Sun, Mar 30, 2014 at 11:05:08AM +0000, Jacco van Gent wrote:
> > I am using exim (4.82) together with mailscanner. Exim is setup to
> > defer messages so that mailscanner can scan the messages. After
> > mailscanner has scanned the message and if the message passes as
> > clean, mailscanner calls exim to sent the message to the backend
> > smtp server (exchange).
>
> Jacco,
> what do you mean by "defer"? If message rejection with temporary
> error, it seems ridiculous. Messages should be processed immediately
> on arrival.
>
> You have better to look for another processing scheme, without any
> deferral for scanning. Just call mailscanner utility from your
> custom transport.
>
> > Now the obvious question is why are message defers for content
> > scanning being reported as error in the retry db ?
>
> Because non-error situation is "mail accepted", others are errors.
> --
> Eugene Berdnikov
>
>


I am using Mailscanner together with Baruwa 2.0, their setup suggest deferring the message, so that Mailscanner can process it and write message data to a postgresql database. If I am not mistaken, this is the same approach Mailscanner suggests on their website.

They to suggest deferring the message (for message scans), scanning the message and then calling exim to send it out. The missing link to me seems the part where the retry database isn't updated when that second step successfully sends the message to the backend SMTP server.



The whole point here is to not use any content scanning or anti-spam processing using exim's content scanning extension, as then messages are rejected in case of malware or being spam, whereas Mailscanner is capable of guaranteeing the message rather than reject it at the SMTP server, with database logging as a bonus. The messages are processed immediately in any case, just seems the subsequent successful delivery to the backend server isn't being reflected in retry db, hence my problem.