Ian R. Justman wrote:
Ian R. Justman wrote:
Sahil Tandon wrote:
See the example here, in particular the section that begins with "If
for some reason SASL users connect to port 25":
http://www200.pair.com/mecham/spam/bypassing.html#10
The example is specific to amavisd-new as a content_filter but you
can amend for your needs.
Aha, I hadn't thought of it that way. Since I do happen to use
amavisd-new here, this fits this bill VERY nicely. Thanks for the
angle and I'll try it out in a bit.
The "catch-all" rule described in that article did the trick. As it
turns out, I was thinking of using this very filter action (FILTER) for
if any of my users' IPs matched, i.e. a rule that would NOT trigger
filtering. I'll sheepishly admit that I hadn't thought of using it as a
"condition" to ACTUALLY trigger filtering. :) Of course, I had to turn
off any normal "content filtering" directives
(content_filter/smtpd_proxy_filter for post- and pre-queue respectively).
you can alos leave the content_filter at its "default" and use something
like
smtpd_sender_restrictions =
check_client_access pcre:/etc/postfix/filter_auth
permit_sasl_authenticated
check_client_access pcre:/etc/postfix/filter_default
== filter_auth
#virus scan only
/./ FILTER scan:[127.0.0.1]:10586
# no scan. pass to next smtpd
#/./ FILTER scan:[127.0.0.1]:10025
# no scan, no next smtpd
#/./ FILTER dummy:
== filter_default
/./ FILTER scan:[127.0.0.1]:10024
note that if you disable address rewrite before the filter, you should
pass mail (even if not filtered) to the "after the filter" smtpd so that
rewrite happens. otherwise, your virtual aliases won't be expanded, ...
etc.
one should generally scan all mail for viruses. you can use clamstmp for
this. or you can use amavisd-new with policy banks.
Though a suggestion if it has not been made already: Possibly make it
configurable whether some permit_* rules (particularly permit_mynetworks
and permit_sasl_authenticated on port 25; definitely not "permit") will
allow direct queueing of a message, i.e. bypassing
smtpd_proxy_filter/content_filter. That way, you can make a server
either be both a client and MX server (a server with an MX record
pointed at it) or be one or the other and make switching between
behaviors cleanly configurable.
The "future" is for the separation of flows (25 vs 587). so when 587
becomes more widespread, this "feature" would be obsolete.
note that in the case of permit_mynetworks, you can redirect the flow to
port 587 with a NAT implementation.
