Hi,
2008/2/10, mouss <[EMAIL PROTECTED]>:
>
> Dan wrote:
> >   smtpd[1441]: connect from some.ip
> >   smtpd[1441]: NOQUEUE: filter: RCPT from some.ip: <[EMAIL PROTECTED]>:
> >         Recipient address triggers FILTER
> > dspam:unix:/var/run/dspam/dspam.sock;
> >         from=<[EMAIL PROTECTED]> to=<[EMAIL PROTECTED]> proto=ESMTP helo=<
> > some.ip>
> >
>
> so you are using a check_recipient_access to select the FILTER. are you
> aware that this doesn't work as intended with multi-recipient mail? only
> one filter will be used, and the last FILTER statement wins.


Hmm, no I am not. This doesn't quite sound good ;-( Thanks for pointing it
out.


> Also, when changing [EMAIL PROTECTED] to be redirected to e.g.
> > [EMAIL PROTECTED] (i.e. external address), I afterwards see
> > [EMAIL PROTECTED] in the output of dspam_stats. This is actually
> quite
> > annoying, as I'll have a few addresses where the incoming mail is split
> into
> > multiple (2-4) emails to different (external) addresses, and I would
> rather
> > that dspam would not handle them (and esp not store them). Any ideas how
> > this could be done? I see how it makes sense if the new address is
> local,
> > but for external addresses I think this doesn't really make sense (they
> will
> > have their own spam filter at their site).
> >
>
> you can remove the auto_increment from dspam virtual uids table, and
> fill it manually.
>
> alternatively, if you don't want to filter outbound mail, then don't set
> a filter for outbound mail. for mail submitted via sendmail, just add
> "-o content_filter=" under the pickup service in master.cf. for mail
> submitted via smtp, you can do something like this
>
> smtpd_sender_restrictions =
>     check_client_access pcre:/etc/postfix/filter_outbound
>     permit_mynetworks
>     permit_sasl_authenticated
>     check_client_access pcre:/etc/postfix/filter_inbound
>
> == filter_outbound
> /./      FILTER dummy:
>
> == filter_inbound
> /./   FILTER dspam:
>
> note however that any FILTER returned by subsequent checks will override
> the above. once again, only one filter is set for a message. so the last
> FILTER statement wins.


Okay.

Thanks for the suggestions and info, this has been really helpful.

I think I will follow Jeff's advice and just add it as the delivery agent,
though, this seems to be the simpler solution and should do the trick.


Dan

Reply via email to