> On Feb 26, 2017, at 11:37 AM, Marek Kozlowski <m.kozlow...@mini.pw.edu.pl>
> wrote:
>
> Let's assume that services defined in `master.cf' are as follows:
> -----------------------------------------------------------------------
> smtp inet n - n - - smtpd
> -o content_filter=spamassassin
> -o receive_override_options=no_address_mappings
Mail that comes in via SMTP is (initially) force-routed to the
above specified content_filter transport.
> spamassassin unix - n n - - pipe
> user=nobody argv=/usr/bin/vendor_perl/spamc -f -e /usr/sbin/sendmail
> -oi -f ${sender} ${recipient}
That transport executes the "spamc" program, which, by the looks of
things, re-injects the message with any modifications via sendmail(1).
> I've checked the log and it seems that mail incoming from remote servers
> addressed to local users is processed according to the following chain:
>
> smtpd -> cleanup (with trivial rewrite) -> qmgr -> spamd -> [sendmail]
> -> pickup -> cleanup -> qmgr -> local
Well, actually "spamc" rather than "spamd". The former communicates
with the latter, but is ultimately resposible for actually delivering
the email onward.
> This transition:
>
> qmgr -> spamd
>
> according to the config must be in fact:
>
> qmgr -> smtp -> spamd
There is no such "must". When using "advanced" filters, the communication
to the filter is via SMTP, when using simple filters, it is via pipe(8)
executing the filter script.
> Why does `qmgr' for the first time use `smtp' delivery agent
It does not. It uses the content_filter transport if added upstream
to the queue file, or otherwise whatever transport table or address
class implies.
> and the second time `local'.
The re-injected message has no content_filter recorded in the queue file.
--
Viktor.
