On 2014-03-31 08:05, Jeremy Harris wrote:
> On 31/03/14 07:08, Jacco van Gent wrote:
> > 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.
>
> In the commonly accepted usage of the words, "deferred" means that exim
> does not have the message yet. So it can't send it out.
>
> So either your combination setup is very odd or you're using different
> words. Perhaps you could describe your message flow in more detail.
> Include SMTP protocol-level actions and the interactions between
> Mailscanner and Exim.
> --
> Cheers,
> Jeremy
>
>
The mail flow is as follows:
mail arrives at exim as normal smtp traffic. When certain acl statements have been satisfied, exim accepts the message (stuff like Recipient verification, SPF checks, black list checks)
Instead of directly sending the message out to the SMTP backend server (the domain exim relays for) it actually queues the message, so that mailscanner can run malware and spamassassin checks.
this is done by putting:
message_checks:
driver = redirect
allow_defer
data = :defer: queued for message checks
no_verify
no_address_test
at the top of the routers section. Which is pretty much in line with the suggested setup instructions from mailscanner here :
http://mailscanner.info/exim.html
Now after Mailscanner has scanned the message, it will call exim (using the specified config file in mailscanner.conf) to sent the scanned message out to the backend smtp server. In this case the outgoing config file of course uses a normal router to deliver the scanned messages to the backend SMTP server, such as :
deliver_clean_randomize:
driver = manualroute
domains = +relay_sql_rand_smtp
transport = remote_smtp
hosts_randomize = true
route_data = ${lookup pgsql {ROUTE_QUERY}}
Now my initial feeling is that since this setup is using two different configuration files. one for the running daemonized version of exim, that waits for incomming smtp connections and one for mailscanner to actually send out the email, it uses two retry databases.
the incomming spool directory is set in the relevant exim config file as:
spool_directory = /var/spool/exim.in
whilst the outgoing spool directory is set to Outgoing Queue Dir = /var/spool/exim4/input
if I issue exim_dumpdb /var/spool/exim.in retry
it returns:
R:localhost -1 0 queued for message checks
26-Mar-2014 23:32:20 26-Mar-2014 23:55:19 27-Mar-2014 00:10:19
and similar records for other relay domains.
when I issue exim_dumpdb /var/spool/exim4 retry
I actually get back data from mailscanner sending out the messages using exim.
Now my theory is that because the initial message deferral for the relay domain in /var/spool/exim.in/db/retry never gets "reset" by a successfull delivery as the outgoing configuration is actually using /var/spool/exim4/db as location for it's database files.
Sent from Windows Mail
