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

291123Re: Could you help me with Postfix + MimeDefang?

Expand Messages
  • Bill Cole
    Feb 5, 2013
    • 0 Attachment
      On 5 Feb 2013, at 4:46, Mark Alan wrote:

      > On Mon, 04 Feb 2013 22:13:14 -0500, "Bill Cole"
      > <postfixlists-070913@...> wrote:
      >
      >> alternative to hooking the MD milter into your main smtpd would be to
      >> define a transport in master.cf running smtpd with MD as a milter,
      >> and use postfix's transport map to route just the one address there.
      >> This would also allow you to avoid the ugly problem of envelope
      >> recipient splitting inside MD.
      >
      > Well, that was also my gut feeling, that was why I posted here to try
      > to find some (solid) evidence.
      >
      > So, assuming MD SPOOLDIR='/var/spool/postfix/mimedefang' and
      > SOCKET='/var/spool/postfix/mimedefang/mimedefang.sock',

      Bad idea. Don't put non-postfix stuff in /var/spool/postfix/. The
      default
      SPOOLDIR='/var/spool/MIMEDefang' and
      SOCKET='/var/spool/MIMEDefang/mimedefang.sock' are fine.

      > would the
      > following do the job?
      >
      > postconf -e 'virtual_alias_maps = /etc/postfix/virtual-alias-maps
      > # /etc/postfix/virtual-alias-maps
      > mailing_list_1@... mailing_list_1@...
      > ...
      > postconf -e 'transport_maps = /etc/postfix/virtual-transport'
      > # /etc/postfix/virtual-transport
      > mailing_list_1@... filteredmlmmj:mailing_list_1
      > ...
      > # /etc/postfix/master.cf
      > # transport for the mlmmj mailing lists
      > mlmmj unix - n n - - pipe
      > flags=ORhu user=mlmmj argv=/usr/bin/mlmmj-receive -F
      > -L /var/spool/mlmmj/$nexthop
      > # filtered transport for the mlmmj mailing list manager
      > filteredmlmmj unix - - - - - mlmmj
      > -o smtpd_milters = unix:mimedefang/mimedefang.sock
      >
      > Please note, in this last statement, 'unix', 'mlmmj' and '-o
      > smtpd_milters' nad the 5 dashes.

      Substantially wrong. You would need to define a new transport in
      master.cf running *smtpd* in the manner used for a submission daemon or
      the transport used for amavisd output. e.g. something like this:

      localhost:10025 inet n - n - - smtpd
      -o smtpd_milters=unix:/var/spool/MIMEDefang/mimedefang.sock
      -o transport_maps=
      (maybe other -o lines to override main.cf)

      I don't use MD or Postfix that way myself, so I'm a bit leery of cooking
      up anything that looks like a complete example. The concept is that you
      are routing some mail through another postfix SMTP daemon instance with
      its own independent configuration.

      >> You can probably get a more complete answer on the MD mailing list.
      >
      > Not at all. The stated problem is an old problem. I have researched
      > extensively a lot of discussions about this subject both in MD list
      > and
      > in the postfix list (and a lot of useless 'recipes' too). People tend
      > to see this issue as some sort of magically solved hit or miss issue.

      Or irrelevant to them. What you want to do isn't something most people
      using MD or Postfix want to do, and most people using one or the other
      are not using them together. It seems to me that the best way to do this
      would be to let MD see everything rather than to try to route around it,
      but in any case most of your work will be in writing the filter
      routines, not doing the plumbing. The experts in that aspect will be on
      the MD list more than they will be here.

      > And the people that develop MD seems to be more in the business of
      > selling "canned" solutions (pun intended), than into producing good
      > and clear documentation.

      There used to be a wiki, but it got overrun with spam. The docs in the
      distribution are pretty solid and the code is not hard to follow. The
      LISA '04 presentation on the website is actually quite good at providing
      a high-level view. If you're looking for 'recipes' that will work for
      your particular need you aren't going to find them because that's just
      not the sort of tool MD is. It is written for Perl coders who also run
      mail systems, not mail admins who can read Perl. Manipulating mail
      content has become increasingly unpopular over the past decade for
      mostly good reasons and it's relatively rare to use MD solely for that
      purpose or to only deploy it for some addresses. It's not remarkable
      that no one has a setup for addressing your issue that they feel
      comfortable sharing. I've been using MD for a decade with both Sendmail
      and Postfix and only have a general idea of how to approach it.


      >> Also note that configuring MD means
      >> writing a collection of Perl functions with predefined interfaces to
      >> implement the message filtering. If you are not comfortable writing
      >> Perl,
      >
      > No problem with the needed Perl functions.
      >
      >> MD may not be the right tool for you.
      >
      > MD is certainly resources hungry. But I do not know any other app
      > that meets the specs:
      > convert html->text,
      > remove unsafe attachments (offenders with known ext's),
      > remove+webserve file attachments larger than 500KB
      >
      > Right now we are piping email into "altermime --input=- --removeall",
      > but altermime is orphaned/abandonware and it does not do that file
      > attachment remove+webserve job.

      You might want to consider just writing your own pipe-suitable delivery
      filter using the MIME-Tools suite rather than loading up all the
      superstructure of MD. It seems like you would be using a small subset of
      MD itself and coding most of what you actually want done in your filter
      and filter_multipart functions, so why bother with MD?
    • Show all 10 messages in this topic