Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Message

Re: [milter-greylist] Can milter-greylist run after sendmail checks users?

2011-02-18 by Johann Klasek

On Fri, Feb 18, 2011 at 02:44:04AM +0100, manu@... wrote:
> Les Mikesell <lesmikesell@...> wrote:
> 
> >   Sendmail is very quick at rejecting local addresses that are not in
> > the aliases or virtuser tables so that is normally not a problem, but
> > when milter-greylist is active it wants to greylist even the 
> > undeliverable addresses.

What does this look like in maillog?

> 
> milter-greylist runs before sendmail checks the address is valid. I do
> not think you can change that.

As far as I understand sendmail internal processing including milter
callbacks this is not true at least in my sendmail environment. 

In general: in state envelope recipient processing sendmail runs already
rule 0 on this address to see if this address is valid. This result is
later used to route the mail to the recpient (don't know actually
whether rule 0 is called again or the result is recalled from the call
before). If an address is not routeable (invalid) sendmail responds
immediatly with an error. If this check shows that this address could be
valid the recipient address is passed to all active milters call back
hooks (probably in order the milters are defined in sendmail.cf).

I have feature access_db and delayed checks enabled on some servers, on
some not. In both groups I have noticed the same behaviour.

A case from my logs:

Feb 18 00:00:01 mri1 sendmail[3994]: p1HMxsQB003994: <joachim.fabinir@MYDOMAIN>... Generic address unknown
Feb 18 00:00:02 mri1 milter-greylist: p1HMxsQB003994: addr [151.59.218.228][151.59.218.228] from <infod@...> to <joachim.fabini@MYDOMAIN> delayed for 00:03:00 (ACL 566)
Feb 18 00:00:02 mri1 sendmail[3994]: p1HMxsQB003994: Milter: to=<joachim.fabini@MYDOMAIN>, reject=451 4.7.1 Greylisting in action, please come back later
Feb 18 00:00:03 mri1 sendmail[3994]: p1HMxsQB003994: <jso1209jens@MYDOMAIN>... Generic address unknown
Feb 18 00:00:03 mri1 miltrassassin[4445]: p1HMxsQB003994: Message aborted (abort by milter)
Feb 18 00:00:03 mri1 sendmail[3994]: p1HMxsQB003994: lost input channel from [151.59.218.228] to MTA after data
Feb 18 00:00:03 mri1 sendmail[3994]: p1HMxsQB003994: from=<infod@...>, size=1016, class=0, nrcpts=0, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=[151.59.218.228]


A mail for 3 recipients @MYDOMAIN arrives. One of this recipients is an
existing address (checked via an equivalent mechanism to virtuser
table). The others are invalid. Miltergreylist adds only the entry for
joachim.fabini@MYDOMAIN (the valid address), the other address are
rejected. The sending source gives up and terminates the session because
no recipient can be reached. Another milter (miltrassassin) which is
still active recognizes the termination of the session (which is logged)
- miltergreylist is already done at this state and keeps quiet (or does
not log it anyway).


> > For the moment I am working around it by 
> > tracking the 'real' users, including them in the milter-greylist config,
> > and restricting greylisting to the specified addresses.  However, it 
> > would be nicer if this could be handled automatically by letting 
> > sendmail reject addresses it can't deliver first.  Is there any way to
> > do that?
> 
> I solve this problem by having milter-greylist performing LDAP queries
> for the recipient address. If there is no match, the mail is rejected.

Any other milter (look ahead milters) which determines a invalid address
should able to terminate a recipient. Maybe it the order of milters is
substantial.

> 
> > Also, the extra log line about 'skipping greylist because this is the
> > default action' for the unprocessed addresses is filling my disks up to
> > the point that I had to change the log rotation.  Is there any way to
> > turn that off?  When it doesn't do anything, I don't need to know about it.
> 
> Patch the sources?

Or ...
Insert a filter statement/script for logrotate (removing the all
lines "skipping greylist because this is the default action").
Alternatively (in case you have syslog-ng) you may set up a filter rule
removing this kind of messages on entrance ;)


Johann Klasek

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.