Ville Walveranta wrote:
I've been looking for the last day (on and off :-) at Todd Bennett's
smtpprox (see http://bent.latency.net/smtpprox/ ). It would likely do
what you're looking to do with minimal modifications.
My goal is to look for the Subject of the arriving messages
you should have posted this to the other thread:
"Rewriting Subject line, adding an X-header?"
(always think of the archives).
(all
arriving messages will be filtered through an external, commercial
spam filtering service, emails are not accepted from elsewhere except
for relay by local users and via SASL auth), and those messages whose
Subject begins "**SPAM**" are processed so that 1) the subject line is
rewritten so that the "**SPAM**" text is removed,
note that just because you find **SPAM** in the Subject doesn't mean it
was added by your filtering provider. we see such headers in mail to
mailing-lists (and even in mail from customers;-p)... In short, it does
not prove that the message is spam according to your own policy.
not a serious issue, but be aware of that.
and 2) an extra
header ("X-Spam: yes") is added that can subsequently be used by Sieve
plugin in Dovecot to deposit the spam into spam mailbox (which is then
pruned by a cron job to last 30 days).
I have the following items added to the configuration:
---[begin master.cf addition]---
#scanner interface
scan unix - - n - 10 smtp
-o smtp_send_xforward_command=yes
-o disable_mime_output_conversion=yes
-o smtp_generic_maps=
#return interface for the filtered mailman
localhost:10026 inet n - n - 10 smtpd
-o content_filter=
-o
receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_milters
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
---[end master.cf addition]---
---[begin main.cf addition]---
content_filter = scan:[127.0.0.1]:10025
receive_override_options = no_address_mappings
---[end main.cf addition]---
Todd Bennett's smtpprox forks/kills its own children, and it also
expects a port to bind to, such as with a command
/usr/local/etc/smtpprox/smtpprox localhost:10025 localhost:10026
where the `localhost:10025' is the inbound interface referred to from
Postfix's main.cf, and `localhost:10026' is the interface through
which the processed emails are injected back into the queue. For these
reasons I think it may not be a good idea to use Postfix's spawn to
run smtpprox (especially since the number of concurrent processes set
in master.cf would be multiplied by ten as smtpprox forks up to ten
children), so it's probably best to daemonize it separately.
yes, don't spawn it.
With the filter set up, the only thing remaining is to modify smtpprox
(which is written in Perl) to do what you want it to do. That's where
I'm at right now; my Perl-skills are very rusty, so I'm trying to
figure out what smtpprox actually does. Looking at Clifton Royston's
header insert patch has helped some, but if someone here is using
smtpprox for a similar purpose (e.g. for mogrifying header or content
in some way), it would be very useful to see your changes to smtpprox.
use postfix to prepend the spam header (X-Spam: yes) and use the proxy
to "fix" the subject. This way you prepend the new header instead of
adding it to the middle of previous headers (and you don't want to
buffer headers in the proxy).
to fix the subject, you probably only need to change the yammer()
function, just after
s/^\./../;
the quick&dirty way (for testing) is to add
s/^Subject:\s*\*\*SPAM\*\*\s+/Subject: /i;
CAVEAT: this would perform the substitution even in the body. you need a
little more code to prevent this.
