Loading ...
Sorry, an error occurred while loading the content.

247627Re: Finding the envelope-sender after always_bcc? (SOLVED)

Expand Messages
  • mouss
    Jan 2, 2009
      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.

      > 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.

      > 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).

      > 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

      - 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

      - 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=".


      >
      > 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...

      > 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)
      >
    • Show all 28 messages in this topic