Hi All,
I posted an email some time back asking about MD slaves that were
unexpectedly terminating with a signal 14. David Skoll mentioned at the time
that it was possibly a perl module generating this signal 14 which was
somehow not being handled and was causing the slaves to die.
At the time, I
Seems to be working:
Jan 17 08:10:01 mail sendmail[24471]: NOQUEUE: connect from
san-cust-208.57.14.2.mpowercom.net [208.57.14.2]
Jan 17 08:10:01 mail sendmail[24471]: AUTH: available mech=DIGEST-MD5
ANONYMOUS
CRAM-MD5, allowed mech=EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
Jan 17 08:10:
David F. Skoll wrote:
(Btw, I've noticed that almost no patch submitters remember to update
the man pages! :-))
Not true! ;-)
I updated the man page, but that also included edits for changing
filter_sender(),
which I then had to back out...
-Philip
>
> Philip wanted an opportunity from MIMEDefang to change how Sendmail
> reacts to the HELO/EHLO command. Right now, you can't; you have to wait
> for MAIL FROM: to do anything based on the HELO argument.
>
OK, and what about the question raised as to how incoming mailers
might react if, for
Gary Funck wrote:
> I've kind of lost the thread here what is the
> recommended use for filter_helo?
Philip wanted an opportunity from MIMEDefang to change how Sendmail
reacts to the HELO/EHLO command. Right now, you can't; you have to wait
for MAIL FROM: to do anything based on the HELO ar
I've kind of lost the thread here what is the
recommended use for filter_helo?
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://w
Hi, Philip.
> Here's the patch again. I was hoping to get some answers about the
> set_dsn() stuff before posting...
Thanks! I believe set_dsn() will work in the HELO callback. I will
integrate your patch.
(Btw, I've noticed that almost no patch submitters remember to update
the man pages! :-
David F. Skoll wrote:
Not in filter_sender if we use your patch, unless we parse the
commands file manually.
If you re-work your patch to leave filter_sender as it was, I will
include it in the official release.
Here's the patch again. I was hoping to get some answers about the
set_dsn()
Matthew Schumacher wrote:
If we had gone with iptables we wouldn't be able to leave our abuse,
postmaster, and support addresses open, and users would be rejected
without an error message explaining exactly what happened. Since
rejected email only costs us one ldap and one sql lookup we will liv
Jan Pieter Cornet wrote:
>Also, your code assumes you cannot call smfi_setreply in the helo()
>callback, but that assumption is wrong. At least, it is according to
>the milter API documentation. It's probably very useful to set a reply
>after HELO!
>
Ok, here are part of the revised diffs to mi
David F. Skoll wrote:
But it breaks existing filters; we need the helo arg back.
And there's a good reason to pass HELO in filter_sender (and
filter_recipient, for that matter): You may WANT to defer your
HELO processing until later. Our commercial products, for
example, let individual recipien
Philip Prindeville wrote:
>> But it breaks existing filters; we need the helo arg back.
>> And there's a good reason to pass HELO in filter_sender (and
>> filter_recipient, for that matter): You may WANT to defer your
>> HELO processing until later. Our commercial products, for
>> example, let in
Jan Pieter Cornet wrote:
Also, your code assumes you cannot call smfi_setreply in the helo()
callback, but that assumption is wrong. At least, it is according to
the milter API documentation. It's probably very useful to set a reply
after HELO!
Ok, here are part of the revised diffs to m
Richard,
>
> Before I spend a lot of time searching... Did you post the script, or
> just notes on the idea?
Notes on the idea - I have a working Perl script to do the iptables changes,
and a couple of useful shell scripts to lookup addresses and match names, but
having seen the post by Matthew,
Philip Prindeville wrote:
> It was previously passed in filter_sender() because it wasn't
> available earlier (since obviously there was no support for
> "helos"). This was a design short-coming. And it's an attempt to
> KISS, by dividing and conquering the problem...
But it breaks existing filte
Richard Laager wrote:
> On Tue, 2006-01-17 at 17:30 +, Paul Murphy wrote:
>
>>For more background, search the mailing list archives for "Blocking spam
>>senders using IPTables?".
>
>
> Before I spend a lot of time searching... Did you post the script, or
> just notes on the idea?
>
> Thanks
Jan Pieter Cornet wrote:
On Tue, Jan 17, 2006 at 02:15:25AM -0700, Philip Prindeville wrote:
Ok, some progress... I've installed the package, I'm running it currently.
Anyone have any comments on it?
Yes: why do you remove the HELO argument in filter_sender? This means
you're breaki
On Tue, 2006-01-17 at 17:30 +, Paul Murphy wrote:
> For more background, search the mailing list archives for "Blocking spam
> senders using IPTables?".
Before I spend a lot of time searching... Did you post the script, or
just notes on the idea?
Thanks,
Richard
> I don't know if it's the same place, but I've got a bunch of these
> going back to Dec 20 (as far back as my logs go).
>
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> I'm guessing the ret@ e-mail is a particular spam bot signature.
Probably. However, bl
At work here at 180 I am handling 200K/day easily with a Dell 2650 w/ twin
2.8 Xeon, 4Gig Ram NFS mounted maildirs running SM, MD, SA & Clamd. The
only bottleneck is a 1999 vintage NetApp which is about to be replaced. LA
~1 most of the time except when the NetApp gets clogged
At 09:20 AM 1
On Tue, 2006-01-17 at 08:20 -0800, Gary Funck wrote:
> > From: Michael Lang
> > Sent: Tuesday, January 17, 2006 7:50 AM
> [...]
> >
> > at my last company we did with 4 machines, 3Mil/Day Messages without any
> > problem. The machines where HP DL360 2G Ram 1 CPU ;)
>
> With Mimedefang and SA?
ye
> From: Michael Lang
> Sent: Tuesday, January 17, 2006 7:50 AM
[...]
>
> at my last company we did with 4 machines, 3Mil/Day Messages without any
> problem. The machines where HP DL360 2G Ram 1 CPU ;)
With Mimedefang and SA?
___
NOTE: If there is a di
Nik Clayton wrote:
>> I hate to say this, but switch from SPARC to a commodity Intel box.
>> Intel and AMD chips far outperform SPARC for the kind of processing
>> MIMEDefang/SpamAssassin do. Even a mid-range dual Xeon at 2.4GHz with
>> a couple of gigs of RAM can handle 40K emails/day with ease.
On Tue, 2006-01-17 at 14:48 +, Nik Clayton wrote:
> David,
>
> David F. Skoll wrote:
> > Stephen Ford wrote:
> >> I'm running Solaris 9 on a dual processor 220R with 2
> >> gigs of ram and the box is having trouble keeping up
> >> with spam!?!?
> >
> > I hate to say this, but switch from SPAR
David,
David F. Skoll wrote:
Stephen Ford wrote:
I'm running Solaris 9 on a dual processor 220R with 2
gigs of ram and the box is having trouble keeping up
with spam!?!?
I hate to say this, but switch from SPARC to a commodity Intel box.
Intel and AMD chips far outperform SPARC for the kind o
Philip Prindeville wrote:
> Anyone have any comments on it?
Looks OK except for one thing: You've removed the HELO argument
from filter_sender. We need to restore that; lots of people rely on it.
With that change, I will add the patch to the official release.
Regards,
David.
_
Philip Prindeville wrote:
> I was wondering about moving the:
>write_mx_command(data->cmdFD, 'E', (unsigned char *) data->heloArg);
> into the helo() function from envfrom() instead.
Won't work; you don't have a queue-ID yet.
--
David.
___
NOTE: I
Philip Prindeville wrote:
> Hmmm... I'm looking at MXRelayOK, MXSenderOK, MXRecipientOK, etc.
> and wondering about why there's duplication of both passing the same
> arguments again (ip, name, helo, etc)... As well as duplicating the
> validation logic for arguments...
Because the filter_relay
> -Original Message-
> From: Ashley M. Kirchner
>
> ...spam e-mails coming from an e-mail <[EMAIL PROTECTED]> where the
> domain name is generally has the word 'deluxe', 'luxury', or
> some form thereof in it? Over the past few days I've gotten
> hundreds upon hundreds of hits from
Hi
I relatively new to using mimedefang.
Im having a problem where for some reason mimedefang is failing and mail is
rejected with a 451 4.7.1 Please try again later
Im trying to get to the bottom of what the mimedefang problem is, but in the
meantime I wanted to set it to just accept the mail i
Quoting Gary Funck <[EMAIL PROTECTED]>:
From cf/README:
confQUEUE_LAQueueLA [varies] Load average at which
queue-only function kicks in.
Default values is (8 * numproc)
On Tue, Jan 17, 2006 at 02:15:25AM -0700, Philip Prindeville wrote:
> Ok, some progress... I've installed the package, I'm running it currently.
>
> Anyone have any comments on it?
Yes: why do you remove the HELO argument in filter_sender? This means
you're breaking compatibility for those who d
Ok, some progress... I've installed the package, I'm running it currently.
Anyone have any comments on it?
Thanks,
-Philip
--- examples/init-script.in.bak 2005-10-14 10:16:27.0 -0600
+++ examples/init-script.in 2006-01-17 00:58:34.0 -0700
@@ -39,16 +39,19 @@ [EMAIL PROTECTED]@
Tomasz Ostrowski wrote:
On Mon, 16 Jan 2006, [EMAIL PROTECTED] wrote:
I already know what this means. But it is only because I did read
previous David's message. I'm just saying that this "INCOMPATIBILITY"
note should be more verbose and give an example for those, who do not
know perl very
On Mon, 16 Jan 2006, [EMAIL PROTECTED] wrote:
> > > *** NOTE INCOMPATIBILITY *** filter_begin NOW TAKES ONE ARGUMENT,
> > >NOT ZERO. IF YOUR FILTER HAS A
> > >PROTOTYPE FOR filter_begin, YOU SHOULD
> > >
35 matches
Mail list logo
