291123Re: Could you help me with Postfix + MimeDefang?
- Feb 5, 2013On 5 Feb 2013, at 4:46, Mark Alan wrote:
> On Mon, 04 Feb 2013 22:13:14 -0500, "Bill Cole"Bad idea. Don't put non-postfix stuff in /var/spool/postfix/. The
> <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/MIMEDefang/mimedefang.sock' are fine.
> would theSubstantially wrong. You would need to define a new transport in
> 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.
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
(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.Or irrelevant to them. What you want to do isn't something most people
> 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
> 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.
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 ofThere used to be a wiki, but it got overrun with spam. The docs in the
> selling "canned" solutions (pun intended), than into producing good
> and clear documentation.
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 meansYou might want to consider just writing your own pipe-suitable delivery
>> writing a collection of Perl functions with predefined interfaces to
>> implement the message filtering. If you are not comfortable writing
> 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.
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?
- << Previous post in topic Next post in topic >>