[Mimedefang] Excluding localhost
Hi,
I've tried Googling for this answer on a number of occassions, without a
whole lot of success.
I reinstalled my mailserver recently (new hardware), and since reinstalling,
I've found locally generated mail takes an uncomfortably long time to send.
This is painfully obvious when using Mutt, for example. PHP pages also take
a long time to complete loading as well.
I hadn't noticed this problem previously. I had a filter_begin() sub that
something like this:
sub filter_begin () {
# No need to impact on delivery times for locally generated mail
if (!defined $RelayAddr || $RelayAddr eq '127.0.0.1') {
8.204.2') {
return ACCEPT_AND_NO_MORE_FILTERING
}
However, my reading of things suggests that the return code from
filter_begin() is irrelevant, so I suspect this wasn't ever working before.
I've dicked around with returning action_accept() but this just seems to
generate errors in the log about being called outside a filter, and for the
same reasons, my understanding is it's probably not going to make a
difference anyway.
So, my question is, what is the anatomically correct manner for getting the
MIMEDefang filter to bail out as early and as quickly as possible for
deliveries from specific hosts? Do I need to add a filter_relay sub, and
change how I'm invoking MIMEDefang?
regards
Andrew
___
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MIME::Parser: can't open tmpfile: Invalid argument (solved)
On Tue, Jun 29, 2004 at 05:45:14PM +1000, Andrew Pollock wrote: > Hi, > > I'm rebuilding my primary MX, and I've been trialling MIMEDefang on my > secondary MX. So I duplicated the bulk of the config from my secondary MX to > my (yet to be commissioned) new primary MX. > > I get the following: > > mimedefang-multiplexor: Starting slave 0 (pid 3075) (1 running): About to perform > scan > mimedefang-multiplexor: Slave 0 stderr: MIME::Parser: can't open tmpfile: Invalid > argument > mimedefang-multiplexor: Slave 0 died prematurely -- check your filter rules > mimedefang[1871]: Error from multiplexor: ERR No response from slave > sm-mta[3062]: i5T7K1sb003062: Milter: data, reject=451 4.7.1 Please try again later > [snip] Judicious stracing to the rescue. It highlighted the fact that my /tmp directory had totally bogus owners and permissions, which I fixed, solving the problem. regards Andrew ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] MIME::Parser: can't open tmpfile: Invalid argument
Hi, I'm rebuilding my primary MX, and I've been trialling MIMEDefang on my secondary MX. So I duplicated the bulk of the config from my secondary MX to my (yet to be commissioned) new primary MX. I get the following: mimedefang-multiplexor: Starting slave 0 (pid 3075) (1 running): About to perform scan mimedefang-multiplexor: Slave 0 stderr: MIME::Parser: can't open tmpfile: Invalid argument mimedefang-multiplexor: Slave 0 died prematurely -- check your filter rules mimedefang[1871]: Error from multiplexor: ERR No response from slave sm-mta[3062]: i5T7K1sb003062: Milter: data, reject=451 4.7.1 Please try again later Google has shown a couple of previous instances on this list, but my setup doesn't seem to be the same as these previous problems. I can't work out how to crank out some more debugging, which is what I ideally want to do. I'm running MIMEDefang 2.41 and Sendmail 8.12.11 (on both the secondary MX, which works, and the new primary MX, which exhibits the above). mimedefang.pl -test is happy mimedefang.pl -structure doesn't complain mimedefang.pl -prettyprint spits back an email message if I give it one So I don't feel that there is anything wrong with my mimedefang-filter (as it's the same as the one that works on my secondary MX). A big difference was a 2.6 kernel, as the primary is running 2.6.6 and the secondary 2.4.26, so I booted into a 2.4.26 kernel on the primary MX and the problem persisted, so it's not some bizarre tempfile problem. I guess the next step is an uber strace... I'd appreciate any suggestions. regards Andrew ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
