On Jan 2, 2009, at 3:20 PM, mouss wrote:
Jeff Weinberger a écrit :
content_filter=lmtp:unix:/path/to/dspam args
No.
content_filter=lmtp:inet:127.0.0.1:10024
where the 10024 is the same port used in dspam.conf:
ServerPort 10024
of course, dspam must be running in daemon mode.
dspam is running in daemon mode. This makes sense as a setup.
The example in the dspam docs for postfix shows
content_filter=lmtp:unix:/path/to/dspam.sock
which is why I thought unix: instead of inet:
it's ok to use a unix socket, but it's a socket, not the dspam binary
with args.
OK, thanks. I will set up dspam to listen on port 10024 - seems to
make the most sense. I don't need a localhost:10024 entry in master.cf
then? right?
is there any difference, other than performance?
I wouldn't put performances into the equation without measurements
(one
should tune where the bottleneck is, not in every small piece).
if you use a unix socket, you'll have to make sure it is accessible.
In
particular, if someday you decide to chroot postfix, you'll need to
put
the unix socket in the chroot jail.
exactly. Thanks
On a related question (if more broad): some content_filter examples I
see use content_filter in main.cf and some as "-o
content_filter=..." in
master.cf.
I understand from prior conversations here that you can't override
content filters, they are global. (yes?)
no, they are not global. each smtpd may have its own content_filter.
(don't confuse with: "one message, one filter". The latter simply
means
that postfix won't split a single message into one message per
recipient
before passing it to the content filter).
That makes sense. thank you.
So is there an advantage/disadvantage to specifying the content
filter
in main.cf vs. master.cf?
I guess an example is better than literature, no?
here is a "not uncommon setup":
- port 25 is used for "MX" mail (aka inbound mail). it uses the
content_filter defined in main.cf
right, as I do right now.
- port 587 is used for "submission" (authenticated, ...). such mail is
scanned for viruses but not for spam (there's not much things a
bayesian
filter could do here, except in simple setups with a site-wide bayes).
so -o is used to set the filter for this service
I need to set this up also - seems easy, but is there an example of
the localhost:587 master.cf entry somewhere I could start with?
- sendmail mail is not filtered, because we "trust" the box (there's
no
user, ... etc) and we don't want anything blocking such mail. or we
use
sendmail to reinject mail after filtering, so we don't want to
create a
loop. for this, we set "-o content_filter=".
do you mean the re-injection into postfix? I have "-o content_filter="
there already. I'm re-injecting mail via SMTP, not sendmail...
I am new to pre-queue filtering and am clearly still confused :)
- content_filter refers to after-the-queue filtering. This means
postfix
saves the mail on disk, says "ok" to the client, and sometimes after
that, postfix passes the message to the filter
- proxy_filter refers to pre-queue: postfix keeps the client
connected,
passed the message to the filter and waits for the filter response
before responding to the client. This assumes SMTP, because the
message
was received via SMTP, so the client wants a single response for the
whole message, and not one response per recipient.
the pipe method that you were using is an example of a content_filter,
and is referred to as a "simple filter" in postfix docs. but a
content_filter need not be a pipe.
you had asked:
why do you want to run it in pre-queue mode? This is not needed
and is
not simple to setu
so I thought it might be hard.
and it is. reread what I said about dspam and lmtp...
Thank you!
It's not important for now...getting dspam working as LMTP will be
fine
(assuming it passes along all the right information once it works)
