Re: [AMaViS-user] README.postfix/FILTER_README.html differences

[Mark M. <Mar...@ij...>]

ste,

| Perhaps I should have been more specific, when I originally posted. I 
| had read both documents, and what I saw in the new postfix document 
| looked like a very different way of running the filter than I had seen 
| before - spawning it, instead of it running standalone. Also, the 
| configuration of it look different in that the postfix document adds 
| another line to the filter setup in master.cf - the scan line - so that 
| three lines were needed to use the filter. Plus the two new options you 
| mentioned above.

There is an increasing number options that can be specified in Postfix,
and one should consult Postfix documentation to see which ones
are desired/needed/required for a particular application.
Amavisd-new documentation just points out the more interesting ones.

The only crucial options are turning on the 'content_filter' on incoming mail,
and having it disabled on mail accepted back from the content filter.
All the rest is more or less optional. Whether content_filter is specified
globally, or on a particular smtpd or pickup service, or in FILTER action
is irrelevant to amavisd - suit it to your needs. Same for pre- or post
virtual/canonical mapping. The feeding protocol can be SMTP or LMTP or even
a Unix pipe - and on re-entry: SMTP or a pipe.

| I simply want the best configuration of amavisd-new, as a post-queue 
| content filter in postfix, utilizing any of the newest postfix features 
| that might make it an even more effective filter than it already is, 
| which is why I was reading both documents.

It is good that people _are_ reading and cross-checking doscmentation :)

The smtp_send_xforward_command becomes useful when using the amavisd-new
development snapshots.

The spawn service is not terribly useful with amavisd-new, as we only want
exactly one parent amavisd process, an it takes care of its children in turn.

It is a pitty that the Postfix 'receive_override_options' can not
specify separate settings for virtual_alias and canonical mapping.
The 'receive_override_options=no_address_mappings' turns both of them off.

If one wants to do canonical mapping before, but virtual alias mapping
after content filtering, one still needs to resort to two cleanup
services (this is desired if one wants amavisd to always see external
addresses: on incoming mail before virtual alias maps turn them into
local addresses, and on outgoing mail after internal addresses are
canonicalized. It makes it easier to specify *_lovers, bypass_*,
white/black lists, and local_domains if one needs to have only
external addresses/subdomains in mind).

If someone cares, this can be brought to Wietse's attention,
e.g. that instead of parameter 'no_address_mappings' to the
option 'receive_override_options' it would be nice to be able
to specify canonical/virtual_alias separately.

  Mark