Milter-greylist

Hello...

 I recently updated milter-greylist from 2.1.12 (on a rhel3 server that
had been working great for years) to 4.1.1 from EPEL on a new rhel5
server both running sendmail.  It seems that the older 2.1.12 version
only looked at the envelope of an email message and the newer 4.1.1
version will also look at the data of the email (dacl ?).   I ran into a
problem with a 18 Gig email (yes!).  milter-greylist seemed to suck the
entire message into ram.  Since the new mail server only has 6Gigs of
ram, "bad things" happened.  Specifically ram usage and swap usage maxed
out, the milter-greylist daemon stopped working, the message was
rejected with a 4xx error.  After restarting the milter daemon, all was
good until the message was tried again.  lather, rinse, repeat.  I
eventually found the root cause and deleted the large emails ( all six
of them).

questions:
1: Has anyone else run into this?

1a:  If so has this been fixed in a newer version?

2: Is there a way to stop milter-greylist from processing the data stage
completely?

I realize limiting message sizes either within sendmail or the milter
msg size max will work around this, but sometimes large messages need to
be sent and received.
  

I am also running clamav milter and spamass milter and IIRC, they both
handle large messages gracefully by using disk space in /tmp.




-- 
Christopher McCrory
 "The guy that keeps the servers running"
 
chrismcc@...
 http://www.pricegrabber.com
 
Let's face it, there's no Hollow Earth, no robots, and
no 'mute rays.' And even if there were, waxed paper is
no defense.  I tried it.  Only tinfoil works.

On Fri, Aug 14, 2009 at 10:25:44AM -0700, Christopher wrote:
> It seems that the older 2.1.12 version
> only looked at the envelope of an email message and the newer 4.1.1
> version will also look at the data of the email (dacl ?).   I ran into a
> problem with a 18 Gig email (yes!).  

You want to look at the maxpeek configuration option.

-- 
Emmanuel Dreyfus
manu@...

Hello...

On Fri, 2009-08-14 at 17:27 +0000, Emmanuel Dreyfus wrote:
>   
> On Fri, Aug 14, 2009 at 10:25:44AM -0700, Christopher wrote:
> > It seems that the older 2.1.12 version
> > only looked at the envelope of an email message and the newer 4.1.1
> > version will also look at the data of the email (dacl ?). I ran into
> a
> > problem with a 18 Gig email (yes!). 
> 
> You want to look at the maxpeek configuration option.
> 

cool!


I would humbly recommend:


1: Have the code set maxpeek to some smaller default than unlimited
under the Principle of least astonishment.  I would rather have a large
email not get fully processed with a " ignoring message beyond maxpeek"
syslog entry than have the milter fail completely (or in one case of
mine crash the entire server that required pulling the power cord to
recover).  


2: adding maxpeek to the default .conf file # I would have seen it right
away

2a: adding all config options in the man page to the default .conf file,
possibly commented out.

2b: I can do the default .conf over the next couple days and send a
patch if you like.



> -- 
> Emmanuel Dreyfus
> manu@...
> 
> 
> 
> 
-- 
Christopher McCrory
 "The guy that keeps the servers running"
 
chrismcc@...
 http://www.pricegrabber.com
 
Let's face it, there's no Hollow Earth, no robots, and
no 'mute rays.' And even if there were, waxed paper is
no defense.  I tried it.  Only tinfoil works.

On Fri, Aug 14, 2009 at 11:36:22AM -0700, Christopher wrote:
> 1: Have the code set maxpeek to some smaller default than unlimited
> under the Principle of least astonishment.  I would rather have a large
> email not get fully processed with a " ignoring message beyond maxpeek"
> syslog entry than have the milter fail completely (or in one case of
> mine crash the entire server that required pulling the power cord to
> recover).  

IIRC, if there is no DATA-stage ACL, the body is not looked at.

> 2b: I can do the default .conf over the next couple days and send a
> patch if you like.

Sure, please send it.

-- 
Emmanuel Dreyfus
manu@...

On Fri, Aug 14, 2009 at 10:25:44AM -0700, Christopher wrote:
> 
>  I recently updated milter-greylist from 2.1.12 (on a rhel3 server that
> had been working great for years) to 4.1.1 from EPEL on a new rhel5
> server both running sendmail.  It seems that the older 2.1.12 version
> only looked at the envelope of an email message and the newer 4.1.1
> version will also look at the data of the email (dacl ?).   I ran into a
> problem with a 18 Gig email (yes!). [..]

Nice ...
I think most of us never run into this problem because of an active (e.g.
sendmail) MaxMessageSize limitation ... no one is really interested in
to allow denial of service caused by just a single e-mail ...

Good n8,

Johann K.

--- In milter-greylist@yahoogroups.com, Christopher <chrismcc@...> wrote:
> syslog entry than have the milter fail completely (or in one case of
> mine crash the entire server that required pulling the power cord to
> recover).  

Jesus, 18GB mail??? Our server runs on a 9GB SCSI! I don't think MTAs and MUAs are coped to deal with that. I am sure something would timeout somewhere. What mail client are you using?

As far as crash is concerned, most OS'es would not crash on something as trivial as running out of memory. Garbage collector routines would kill the memory hog process. My server is on 256MB and it has never crashed due to running out of memory.

An email larger than 5MB is in violation of the Geneva Conventions.

On Oct 10, 2009, at 2:29 PM, d d wrote:

> --- In milter-greylist@yahoogroups.com, Christopher <chrismcc@...>  
> wrote:
> > syslog entry than have the milter fail completely (or in one case of
> > mine crash the entire server that required pulling the power cord to
> > recover).
>
> Jesus, 18GB mail??? Our server runs on a 9GB SCSI! I don't think  
> MTAs and MUAs are coped to deal with that. I am sure something would  
> timeout somewhere. What mail client are you using?
>
> As far as crash is concerned, most OS'es would not crash on  
> something as trivial as running out of memory. Garbage collector  
> routines would kill the memory hog process. My server is on 256MB  
> and it has never crashed due to running out of memory.
>
>
>