Yahoo Groups archive

Milter-greylist

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

Thread

sendmail m4 issue

sendmail m4 issue

2011-01-20 by Joe Pruett

i recently upgraded to 4.2.6 with no troubles. i then installed it fresh
on a new system and sendmail wouldn't start.  i tracked it down to a
trailing comma in the sendmail.cf left there by the milter-greylist.m4
config file.  the update didn't get triggered because the sendmail cf
logic isn't smart enough to rebuild if a feature file changes.

i'm working on a tweak to the m4 to deal with this, but wanted to give a
heads up to folks.

Re: [milter-greylist] sendmail m4 issue

2011-01-20 by manu@netbsd.org

Joe Pruett <joey@...> wrote:

> i recently upgraded to 4.2.6 with no troubles. i then installed it fresh
> on a new system and sendmail wouldn't start.  i tracked it down to a
> trailing comma in the sendmail.cf left there by the milter-greylist.m4
> config file.  the update didn't get triggered because the sendmail cf
> logic isn't smart enough to rebuild if a feature file changes.

We recently fixed such a problem in milter-greylist.m4
As far as I understand, the latest tarball contain the fixed .m4. Are
you regenerating sendmail.cf with the updated milter-greylist.m4?

Or is it another new problem?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Re: [milter-greylist] sendmail m4 issue

2011-01-20 by Joe Pruett

i've attached my diff that fixes the issue.  i'm not sure it is the 
"correct" way to do sendmail m4 stuff, but it seems to function and fix 
the issue.

Re: [milter-greylist] sendmail m4 issue

2011-01-20 by Joe Pruett

i used the milter-greylist.m4 from 4.2.6 and it had the problem.  why i
(and maybe others) didn't see it earlier is that updating the .m4 file
doesn't cause a rebuild of the sendmail.cf, only a change to sendmail.mc
will cause that.

look at my diff and see what i did.  maybe the change you made didn't
make it to the release?
Show quoted textHide quoted text
On 01/19/2011 06:43 PM, manu@... wrote:
> We recently fixed such a problem in milter-greylist.m4
> As far as I understand, the latest tarball contain the fixed .m4. Are
> you regenerating sendmail.cf with the updated milter-greylist.m4?
>
> Or is it another new problem?
>

Re: [milter-greylist] sendmail m4 issue [1 Attachment]

2011-01-21 by manu@netbsd.org

Joe Pruett <joey@...> wrote:

> i've attached my diff that fixes the issue.  i'm not sure it is the 
> "correct" way to do sendmail m4 stuff, but it seems to function and fix
> the issue.

The patch does not apply against latest sources, neither does it against
4.2.6. Since the change is subttle and I am not a user of that file, I
will not try to guess. 

Can you check out the 4.2.6 tarball and do a diff -U4 against it?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Re: [milter-greylist] sendmail m4 issue

2011-01-23 by Joe Pruett

it was definitely done against the 4.2.6 tarball and i was just able to 
apply the patch with no hassles.  and i just looked at the development 
tarball and it has the same file and my patch applied directly to it as 
well.

i have remade the patch with -U4 and attached it just in case that helps.
Show quoted textHide quoted text
On 2011-01-20 18:21, manu@... wrote:
> The patch does not apply against latest sources, neither does it against
> 4.2.6. Since the change is subttle and I am not a user of that file, I
> will not try to guess.
>
> Can you check out the 4.2.6 tarball and do a diff -U4 against it?
>

Re: [milter-greylist] sendmail m4 issue [1 Attachment]

2011-01-24 by manu@netbsd.org

Joe Pruett <joey@...> wrote:

> it was definitely done against the 4.2.6 tarball and i was just able to
> apply the patch with no hassles.  and i just looked at the development
> tarball and it has the same file and my patch applied directly to it as
> well.

Ok it works. I don't know what happened last time, perhaps I used a
wrong file.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

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.