On 5 Feb 2013, at 4:46, Mark Alan wrote:
On Mon, 04 Feb 2013 22:13:14 -0500, "Bill Cole"
<postfixlists-070...@billmail.scconsult.com> 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_lis...@example.com mailing_list_1@localhost.mlmmj
...
postconf -e 'transport_maps = /etc/postfix/virtual-transport'
# /etc/postfix/virtual-transport
mailing_list_1@localhost.mlmmj 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?
