>I wonder if someone is using amavisd-new or another content_filter, and the >order it acts. >I mean, how can I say the content_filter to work AFTER all the other UCE >controls ( smtpd_restrictions ) had passed ok ? Just not to waste time/cpu >et all....
This is the whole problem with content-filtering, which requires complete acceptance of the DATA command, when IMGate is oriented towards rejecting after the RCTP TO: command (envelope rejection). The content-filter runs after postfix has accepted/queued the entire msg, but before the smtpd envelope restrictions run. content-filtering was moved forward by the new smtpd proxy delegation (postfix doesn't queue the msg). running amavisd as an smtpd proxy makes sense. Or, you can run the content-filtering alone on a second instance of postfix. Your standard postfix works as it does now, but instead of sending to transport.map, it sends all msgs to another instance of postfix listening on a port above 1024. the second instance does the content-filtering, and then does the delivery to the transport.map destinations. The dual-instance setup is exactly the same at the SMTP level as running IMGate as the MX, and then relaying the accepted msgs to a second box running the content filtering, and finally, the AV. Len
