Mailing List Archive

1 2  View All
Re: patch for named acl variables [ In reply to ]
On Tue, Sep 19, 2006 at 02:05:24PM +0100, Philip Hazel wrote:
> On Tue, 19 Sep 2006, Marc Haber wrote:
> > On Tue, Sep 19, 2006 at 12:40:11PM +0100, Philip Hazel wrote:
> > > That's all. Some testing of this new feature would be useful. Since
> > > several people were in favour of this feature, I hope you'll try it
> > > out.
> >
> > Do you want me to package a snapshot for Debian experimental?
>
> Sure, if you think that will get it used.

I am not sure whether packages in experimental are actually used (I
sometimes doubt that since frequently bad bugs show up after the
upload to unstable even if they were present in an experimental
version for weeks), but I'll need to package the snapshot anyway to
get it used on my productive test boxes.

> But maybe wait until the question Jakob has just asked is resolved.

OK, I'll wait until I get your Ok.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: patch for named acl variables [ In reply to ]
On Tue, 19 Sep 2006, Jakob Hirsch wrote:

> Your comments made me think... mabye we should limit the names to
> acl_[cm][_0-9]..., to keep the variable namespace poisoning low.
> Blocking variables with names like $acl_check_fancy or
> $acl_multiple_fails is drastic (even though they are only names).
> acl_msomething and acl_canythin aren't nice to read, anyway, and more
> error prone. The scope identifier (c/m) should be cleary separated from
> the name.

I thought about that, but not enough. We could restrict the names so
that the first character after c or m must be a digit or an underscore,
and thereby retain compatibility. I think perhaps I should do this. Do
you agree? I can probably get it done this afternoon, so it will make
tonight's snapshot before people start using the existing code.

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: patch for named acl variables [ In reply to ]
Quoting Philip Hazel:

>> Your comments made me think... mabye we should limit the names to
>> acl_[cm][_0-9]..., to keep the variable namespace poisoning low.
> I thought about that, but not enough. We could restrict the names so
> that the first character after c or m must be a digit or an underscore,
> and thereby retain compatibility. I think perhaps I should do this. Do
> you agree? I can probably get it done this afternoon, so it will make
> tonight's snapshot before people start using the existing code.

Yes, that's what I meant, and I'm absolutely in favour of the limit.
could save us some grief in the future.
Would be nice if you could do it, I have no time to make the change and
test it until tonight or probably even tomorrow.

The change should be small, something like this around line 819 (based
on my original patch) should do:

if (s[5] != '_' && !isdigit(s[5])
goto BAD_ACL_VAR;

and added conditions in expand.c:1239.

We could also check in spool_in.c, but that would be a little paranoid.


--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: patch for named acl variables [ In reply to ]
On Tue, 19 Sep 2006, Jakob Hirsch wrote:

> Yes, that's what I meant, and I'm absolutely in favour of the limit.
> could save us some grief in the future.
> Would be nice if you could do it, I have no time to make the change and
> test it until tonight or probably even tomorrow.

Done and committed.

Marc, I guess you can go ahead now.

> We could also check in spool_in.c, but that would be a little paranoid.

Indeed. I have not done that.

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: patch for named acl variables [ In reply to ]
On Tue, Sep 19, 2006 at 03:33:13PM +0100, Philip Hazel wrote:
> Marc, I guess you can go ahead now.

Ok, I will take the CVS snapshot tomorrow.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: patch for named acl variables [ In reply to ]
Quoting Philip Hazel:

> Done and committed.

Ok, runs fine, but something else came up. In previous versions, when
comparing integers, an empty string was obviously equal to zero:

> ${if ={0}{} {yessir} {no go}}
yessir

but now it raises an expansion failure:

> ${if ={0}{} {yessir} {no go}}
Failed: integer expected but "" found

(maybe related to PH/07, I didn't look)


--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: patch for named acl variables [ In reply to ]
On Tue, Sep 19, 2006 at 03:33:13PM +0100, Philip Hazel wrote:
> Marc, I guess you can go ahead now.

Doing so, my first time with an exim snapshot. Is it intended that the
exim man page is not in the snapshot?

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: patch for named acl variables [ In reply to ]
On Thu, 21 Sep 2006, Jakob Hirsch wrote:

> Ok, runs fine, but something else came up. In previous versions, when
> comparing integers, an empty string was obviously equal to zero:
>
> > ${if ={0}{} {yessir} {no go}}
> yessir
>
> but now it raises an expansion failure:
>
> > ${if ={0}{} {yessir} {no go}}
> Failed: integer expected but "" found

I'm surprised it worked before. My reaction to this is that I have
accidentally fixed a bug. The manual says "the two strings must take the
form of optionally signed decimal integers..."

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: patch for named acl variables [ In reply to ]
On Thu, 21 Sep 2006, Marc Haber wrote:

> Doing so, my first time with an exim snapshot. Is it intended that the
> exim man page is not in the snapshot?

Yes. The snapshot doesn't contain spec.txt, filter.txt, or exim.8 on the
grounds that these won't have changed since the previous release (so it
keeps it smaller). Furthermore, these files aren't actually available in
the CVS repository. Only the sources from which they are built are
there. So I'd have to automate building them each time - and I'm not
sure if all the relevant software for doing that is installed on the CVS
repository machine (XML processing is still a bit of a black art). And
I'd rather not trust this to happen automatically, anyway. If somebody
updates the source of the spec, say, and inserts a syntax error, there
could be a problem. The snapshot making process just copies files.

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: patch for named acl variables [ In reply to ]
Quoting Philip Hazel:

>>> ${if ={0}{} {yessir} {no go}}
>> Failed: integer expected but "" found
> I'm surprised it worked before. My reaction to this is that I have

Me too. And not only about that, but also that I had such a lousy config...

> accidentally fixed a bug. The manual says "the two strings must take the
> form of optionally signed decimal integers..."

Hm, I'd prefer to call it an undocumented feature. I'm probably not the
only one affected by this behaviour change.

In my case, it was in the data acl, where I have conditional spam
scanning, but compare $spam_score_int later (which is not set without a
spam scan). Now I have to put an additional condition (with ${if
def:spam_score_int}) in every stanza or change the design.




--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: patch for named acl variables [ In reply to ]
On Thu, Sep 21, 2006 at 09:46:56AM +0100, Philip Hazel wrote:
> On Thu, 21 Sep 2006, Marc Haber wrote:
> > Doing so, my first time with an exim snapshot. Is it intended that the
> > exim man page is not in the snapshot?
>
> Yes. The snapshot doesn't contain spec.txt, filter.txt, or exim.8 on the
> grounds that these won't have changed since the previous release (so it
> keeps it smaller).

I see. I'll need to special-case this.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: patch for named acl variables [ In reply to ]
On Thu, 21 Sep 2006, Jakob Hirsch wrote:

> > accidentally fixed a bug. The manual says "the two strings must take the
> > form of optionally signed decimal integers..."
>
> In my case, it was in the data acl, where I have conditional spam
> scanning, but compare $spam_score_int later (which is not set without a
> spam scan). Now I have to put an additional condition (with ${if
> def:spam_score_int}) in every stanza or change the design.

<hack>
Try 0$spam_score_int instead. The spec does say "decimal integer" so a
leading 0 should be OK.
</hack>


--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: patch for named acl variables [ In reply to ]
Quoting Philip Hazel:

> Try 0$spam_score_int instead. The spec does say "decimal integer" so a
> leading 0 should be OK.

Oh, I forgot to mention I tried this already, but $spam_score_int can
also be negative... it would work with ${eval10:0$spam_score_int}, but I
prefer the additional "condition" line over this (even though it's not
exactly the same behaviour then).

I may be wrong, but I guess other people will also stumble over this.


--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: patch for named acl variables [ In reply to ]
On Thu, 21 Sep 2006, Jakob Hirsch wrote:

> Oh, I forgot to mention I tried this already, but $spam_score_int can
> also be negative... it would work with ${eval10:0$spam_score_int}, but I
> prefer the additional "condition" line over this (even though it's not
> exactly the same behaviour then).

In that case, how about ${spam_score_int}0 ? (With a suitable adjustment
as to what you are comparing it with, of course.)

Philip

--
Philip Hazel, University of Cambridge Computing Service.

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: patch for named acl variables [ In reply to ]
On Thu, Sep 21, 2006 at 11:31:06AM +0200, Marc Haber wrote:
> On Thu, Sep 21, 2006 at 09:46:56AM +0100, Philip Hazel wrote:
> > On Thu, 21 Sep 2006, Marc Haber wrote:
> > > Doing so, my first time with an exim snapshot. Is it intended that the
> > > exim man page is not in the snapshot?
> >
> > Yes. The snapshot doesn't contain spec.txt, filter.txt, or exim.8 on the
> > grounds that these won't have changed since the previous release (so it
> > keeps it smaller).
>
> I see. I'll need to special-case this.

Since it was non-trivial to special-case this and I needed some svn
experience anyway, I have branched an experimental branch for exim's
Debian packaging and have packaged the snapshot of September 21 for
Debian experimental, numbered as 4.63.20060921-1.

I am running the snapshot myself on my personal mail host, and have
adapted my spam and malware filtering ACLs to use named ACLs. I can
say "works for me". Thanks, this is a great feature from a packaging
point of view.

I have posted a heads-up on pkg-exim4-devel and hope that people will
try the snapshot.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

1 2  View All