headers
Philip Hazel | 1 Dec 2005 10:13
Picon
Picon

Re: Preliminary testing of a new Exim test suite

On Wed, 30 Nov 2005, John Jetmore wrote:

> > ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/Testing/exim-testsuite-0.00.tar.bz2
> 
> Did you take this file down on purpose?

Oops, no, accident. It probably happened when when I was clearing out
the -RC copies of 4.60. I have put it back, but later today I expect to
be replacing it with yet another copy.

-- 
Philip Hazel            University of Cambridge Computing Service,
ph10 <at> cus.cam.ac.uk      Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book:    http://www.uit.co.uk/exim-book

--

--
Permalink | Reply | 0 comments |
headers
Daniel Tiefnig | 1 Dec 2005 11:00
Picon

Re: Preliminary testing of a new Exim test suite

Philip Hazel wrote:
> On Tue, 29 Nov 2005, Daniel Tiefnig wrote:
>> For me, with openssl 0.9.8, it says:
>> 
>> tiefnig <at> orion:~$ openssl s_client -cipher RSA-AES256
>> error setting cipher list
> 
> I think that definitely points to a problem of some sort with 0.9.8,
>  because with 0.9.7e I get:
> 
> $ openssl s_client -cipher RSA-AES256
> connect: Connection refused

Hmm, this may be a "feature" of your OpenSSL installation, an other
0.9.7e doesn't do that. (According to a short discussion on
openssl-users.) As one may enable and disable specific ciphers at
compilation time, this sure does vary. According to this, it would be
the safest thing to reduce requirements to an absolute minimum. Like
require just AES encoding on the server and disable it in the client:

  {AES}{!AES:3DES}}

Should do the trick quite everywhere, shouldn't it?

lg,
daniel

--

--
Permalink | Reply | 8 comments |
headers
Philip Hazel | 1 Dec 2005 16:13
Picon
Picon

Re: Preliminary testing of a new Exim test suite

On Thu, 1 Dec 2005, Daniel Tiefnig wrote:

> According to this, it would be the safest thing to reduce requirements
> to an absolute minimum. Like require just AES encoding on the server
> and disable it in the client:
> 
>   {AES}{!AES:3DES}}
> 
> Should do the trick quite everywhere, shouldn't it?

Yes, I think you are right there. I have made that change, and I have 
just refreshed the tarball with the latest sources.

ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/Testing/exim-testsuite-0.00.tar.bz2

Another 50 or so test scripts have been added. While doing this, I
discovered a bug in Exim - annoying, since 4.60 is freshly out - that
affects FreeBSD and probably other BSD-derived systems. If you are using
FreeBSD, test 1002 (an IPv6 test) will fail unless you apply the patch
below. At least this shows the value of making the tests run in
different environments. If anyone wants to know what this patch does,
here's the ChangeLog entry:

PH/01 The code for finding all the local interface addresses on a FreeBSD
      system running IPv6 was broken. This may well have applied to all BSD
      systems, as well as to others that have similar system calls. The broken
      code found IPv4 interfaces correctly, but gave incorrect values for the
      IPv6 interfaces. In particular, ::1 was not found. The effect in Exim was
      that it would not match correctly against  <at> [] and not recognize the IPv6
      addresses as local.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Daniel Tiefnig | 1 Dec 2005 18:38
Picon

Re: Preliminary testing of a new Exim test suite

Philip Hazel wrote:
> ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/Testing/exim-testsuite-0.00.tar.bz2
> 
> Another 50 or so test scripts have been added.

Great, couldn't find any problems with these, just "ipliteral/5301
domain literals (IPv6)" is not omitted even if there is no IPv6 support.

> If you are using FreeBSD,

Ah, haven't used BSD for years.

> test 1002 (an IPv6 test) will fail

Neither I'm using IPv6. Does anybody use IPv6 here?

lg,
daniel

--

--
Permalink | Reply | 4 comments |
headers
Philip Hazel | 2 Dec 2005 10:11
Picon
Picon

Re: Preliminary testing of a new Exim test suite

On Thu, 1 Dec 2005, Daniel Tiefnig wrote:

> Great, couldn't find any problems with these, just "ipliteral/5301
> domain literals (IPv6)" is not omitted even if there is no IPv6 support.

Excellent! Seems that it's now John's turn to find all the issues. :-)

> Neither I'm using IPv6. Does anybody use IPv6 here?

Yes, lots of people do, including the exim.org host. There are comments 
on the exim-users list from time to time.

-- 
Philip Hazel            University of Cambridge Computing Service,
ph10 <at> cus.cam.ac.uk      Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book:    http://www.uit.co.uk/exim-book

--

--
Permalink | Reply | 3 comments |
headers
Daniel Tiefnig | 2 Dec 2005 12:16
Picon

Re: Preliminary testing of a new Exim test suite

Philip Hazel wrote:
> On Thu, 1 Dec 2005, Daniel Tiefnig wrote:
>> Neither I'm using IPv6. Does anybody use IPv6 here?
> 
> Yes, lots of people do, including the exim.org host. There are
> comments on the exim-users list from time to time.

Sure, actually, the complete question would have been:
"Does anybody use IPv6 here and could try the IPv6 tests?". :o)

lg,
daniel

--

--
Permalink | Reply | 2 comments |
headers
Philip Hazel | 2 Dec 2005 12:42
Picon
Picon

Re: Preliminary testing of a new Exim test suite

On Fri, 2 Dec 2005, Daniel Tiefnig wrote:

> Sure, actually, the complete question would have been:
> "Does anybody use IPv6 here and could try the IPv6 tests?". :o)

Oh, sorry, I completely misunderstood!

-- 
Philip Hazel            University of Cambridge Computing Service,
ph10 <at> cus.cam.ac.uk      Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book:    http://www.uit.co.uk/exim-book

--

--
Permalink | Reply | 0 comments |
headers
Andreas Metzler | 2 Dec 2005 19:18

Re: Preliminary testing of a new Exim test suite

On 2005-12-02 Daniel Tiefnig <exim <at> inode.at> wrote:
> Philip Hazel wrote:
> > On Thu, 1 Dec 2005, Daniel Tiefnig wrote:
> >> Neither I'm using IPv6. Does anybody use IPv6 here?

> > Yes, lots of people do, including the exim.org host. There are
> > comments on the exim-users list from time to time.

> Sure, actually, the complete question would have been:
> "Does anybody use IPv6 here and could try the IPv6 tests?". :o)

If you just need Ipv6 connectivity, this should do trick on Linux,
assuming ppp0 is the interface with public IP-address

inet4=`ip addr show ppp0 | grep inet | awk '{print $2}'`
ifconfig sit0 up
ipv6=$(printf "2002:%x%02x:%x%02x::\n" $(echo ${inet4} | sed 's/\./ /g'))
ip addr add ${ipv6}1/16 dev sit0
ip -6 route add 2000::/3 via ::192.88.99.1

                 cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde

--

--
Permalink | Reply | 0 comments |
headers
Stefan Kaltenbrunner | 3 Dec 2005 13:45

Re: Preliminary testing of a new Exim test suite

Philip Hazel wrote:
> On Thu, 1 Dec 2005, Daniel Tiefnig wrote:
> 
> 
>>According to this, it would be the safest thing to reduce requirements
>>to an absolute minimum. Like require just AES encoding on the server
>>and disable it in the client:
>>
>>  {AES}{!AES:3DES}}
>>
>>Should do the trick quite everywhere, shouldn't it?
> 
> 
> Yes, I think you are right there. I have made that change, and I have 
> just refreshed the tarball with the latest sources.
> 
> ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/Testing/exim-testsuite-0.00.tar.bz2

did some initial testing with that on an OpenBSD 3.8-current x86 box.
First problem here is that the test-framework does not even compile on
that plattform due to:

gcc -g -O2  -o bin/fakens src/fakens.c
src/fakens.c:100: error: `ns_t_a' undeclared here (not in a function)
src/fakens.c:100: error: initializer element is not constant
src/fakens.c:100: error: (near initialization for `type_list[0].value')
src/fakens.c:100: error: initializer element is not constant
src/fakens.c:100: error: (near initialization for `type_list[0]')
src/fakens.c:101: error: `ns_t_ns' undeclared here (not in a function)
src/fakens.c:101: error: initializer element is not constant
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Fisher | 5 Dec 2005 21:00
Picon
Favicon

Change delay ACL modifer precision to milliseconds

The new ratelimit ACL condition is much more interesting when delay
can be used with time values that are more precise than a second.  A
very small patch to switch the delay ACL over to using milliseconds is
attached.

This change permits the ratelimit ACL condition to be used in much the
same way as the smtp_ratelimit_* variables, which permit delays of
less than a second.

We're interested in throttling senders down to a particular message
rate, and to do so in a useful manner, we require more precise delay
times.

Our current rule is along the lines of:

  warn
    ratelimit  = 12 / 10s / strict
    delay      = ${eval: $sender_rate - $sender_rate_limit}s

While only precise to a single decimal place, this results in Exim
throttling senders down to a rate of approximately 1.2 messages per
second (after a short initial burst).

eval only deals with integers, and since $sender_rate is not an
integer, the actual eval for our delay is:

  ${eval:
${extract{1}{$sender_rate}}-$sender_rate_limit}.${extract{2}{.}{$sender_rate}}s

This works fine, but it's rather ugly.  Various places in Exim seem to
(Continue reading)

Permalink | Reply | 0 comments |

Gmane