Bugzilla Bug 58282

Exim/exiscan now support libspf2 library.  I'd like to see a new SPF keyword to
compile in support for this.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Actual Results:  
Attached is a modified ebuild for exim 4.41.  I've added a kludge to support
SPF.   It does not check for exiscan support which is required for SPF support.

Also, libspf2 has to be compiled first.  I got the ebuild for here:
http://www.libspf2.org/download.html. and created a directory for it in
mail-mta. Then I added a dependancy in the ebuild.

Exim expects the include directory to be named spf_alt so I had to make a
symlink from /usr/include/spf2 to /usr/include/spf_alt.

Created an attachment (id=36115) [edit]
Exim 4.41 w/spf

There are ebuilds in portage for libspf2/libsrs2. However, look for them in
'mail-filter'. Am already working on adding SPF support to the exim ebuild.

Have a good one,

Jay

*** Bug 61336 has been marked as a duplicate of this bug. ***

Jay, any status on this? I would like to add SPF to my exim mail servers.

Sven,

I am now testing with exim-4.43. So hopefully this should be an add real soon.

Jay

Created an attachment (id=42301) [edit]
Ebuild to support SPF/SRS

Copied from exim-4.43.ebuild, but extended to support SPF/SRS.

Created an attachment (id=42302) [edit]
Required by exim-4.43-r1.ebuild

This is files/exim-4.43-srs2.patch, required by attached exim-4.43-r1.ebuild.

Once again, here's a version of the latest ebuild that supports SPF and SRS.
:-)

It's attached as exim-4.43-r1.ebuild, and depends on the attached
files/exim-4.43-srs2.patch.

Sheldon,

Where did you get files/exim-4.43-srs2.patch from?  Much of the patch seems to be dealing with changed whitespace, and it makes it hard for me to see what's going on. I want to test this patch, but would like a cleaner patch before I do so, if that is possible.

not that I really mind, as long as spf and srs get into the ebuild, but why
don't you use the ebuild proposed in
<http://bugs.gentoo.org/show_bug.cgi?id=61336>
?

There the patch for exiscan comes from a freebsd guy (as mentioned in one
comment).

I too am keen to see this implemented.

I've tested this, and it seems to work fine. 

I'd still like a cleaner patch, as it changes a lot of stuff with only whitespace changes. Can you re-diff with -bB please?

I'm almost done with a new exim-4.50-r2.ebuild that adds spf and srs support,
using libspf2 and libsrs_alt, as per the new integrated exiscan-acl.  I believe
this will satisfy the request for a cleaner patch. :-)

I'll submit my libsrs_alt-1.0_rc1.ebuild as another bug, and refer to it when I
submit the new exim ebuild.

-- Sheldon

Created an attachment (id=55220) [edit]
exim-4.50-r2.ebuild

Supports SPF and SRS using libspf2 and libsrs_alt. Requires
files/exim-4.50-srs_update.patch (to be attached).

Created an attachment (id=55221) [edit]
files/exim-4.50-srs_update.patch

Required by exim-4.50-r2.ebuild.  Taken from the libsrs_alt distribution itself
(also under GPL).

I've added exim-4.50-r2.ebuild and files/exim-4.50-srs_update.patch.

This introduces two new use flags, spf and srs, the latter of which requires libsrs_alt.  I've submitted an ebuild for libsrs_alt on bug #87821.

The patch (files/exim-4.50-srs_update.patch) is taken from the libsrs_alt distribution itself, and the author is pushing to have it incorporated into the exim distribution.  So it's pretty official. :-)

Hopefully you'll agree that this is much cleaner.

I've now been using this in production on various servers with different
configurations for a couple of days without incident.

Ciao,
Sheldon.

Am I wasting my time submitting updates?  I get the feeling the Exim ebuild  
maintainer is a bit of a blackhole.  
  
If you'd like me to submit another update, could you please let me know what  
was wrong with the last one that led to no action being taken on it?  
 
I don't mind contributing the fruits of my effort to the project, but nobody 
likes to waste time. 

Well, i've been called many things in my time, but not a blackhole :) (can't
speak  for Jay though.)
Please accept my apologies for this bug taking so long to resolve, I've been
wrapping up one period of employment and starting another and was on the road
for most of May. I'll be adding it into the tree later on today/this week after
some initial testing.

exim-4.50-r2 (in portage) fails to compile if use flag spf is set:

---
>>> config.h built

make[2]: Entering directory
`/var/tmp/portage/exim-4.50-r2/work/exim-4.50/build-exim-gentoo/pcre'
gcc -c -march=athlon-xp -O3 -pipe -fomit-frame-pointer  maketables.c
gcc -c -march=athlon-xp -O3 -pipe -fomit-frame-pointer  get.c
gcc -o dftables -march=athlon-xp -O3 -pipe -fomit-frame-pointer  dftables.c
./dftables chartables.c
gcc -c -march=athlon-xp -O3 -pipe -fomit-frame-pointer  pcre.c
gcc -c -march=athlon-xp -O3 -pipe -fomit-frame-pointer  study.c
rm -f libpcre.a
ar cq libpcre.a maketables.o get.o pcre.o study.o
ranlib libpcre.a
gcc -c -DNOPOSIX -march=athlon-xp -O3 -pipe -fomit-frame-pointer  -I. pcretest.c
gcc -march=athlon-xp -O3 -pipe -fomit-frame-pointer  -o ../pcretest pcretest.o
libpcre.a
make[2]: Leaving directory
`/var/tmp/portage/exim-4.50-r2/work/exim-4.50/build-exim-gentoo/pcre'
/bin/sh ../scripts/Configure-eximon
sed \
  -e "s?PROCESSED_FLAG?This file has been so processed.?"\
  -e "/^# /p" \
  -e "/^# /d" \
  -e "s?CONFIGURE_FILE_USE_NODE??" \
  -e "s?CONFIGURE_FILE?/etc/exim/exim.conf?" \
  -e "s?BIN_DIRECTORY?/usr/sbin?" \
  -e "s?BASENAME_COMMAND?look_for_it?" \
  -e "s?HOSTNAME_COMMAND?/bin/hostname?" \
  -e "s?X11_LD_LIBRARY?/usr/X11R6/lib?" \
  ../src/eximon.src >> eximon
>>> eximon script built

gcc -c -march=athlon-xp -O3 -pipe -fomit-frame-pointer  -DCOMPILE_UTILITY -o
util-spool_in.o spool_in.c
In file included from /usr/include/spf2/spf_server.h:22,
                 from /usr/include/spf2/spf.h:27,
                 from spf.h:13,
                 from exim.h:400,
                 from spool_in.c:14:
/usr/include/spf2/spf_dns.h:82: error: conflicting types for 'ns_type'
/usr/include/arpa/nameser.h:302: error: previous declaration of 'ns_type' was here
In file included from /usr/include/spf2/spf.h:27,
                 from spf.h:13,
                 from exim.h:400,
                 from spool_in.c:14:
/usr/include/spf2/spf_server.h:23:30: spf_dns_internal.h: No such file or directory
make[1]: *** [util-spool_in.o] Error 1
make[1]: Leaving directory
`/var/tmp/portage/exim-4.50-r2/work/exim-4.50/build-exim-gentoo'
make: *** [go] Error 2
---

(In reply to comment #20)
> exim-4.50-r2 (in portage) fails to compile if use flag spf is set:
Could you please post a new bug (so as not to fill this one) and include the output of emerge info.

Cheers

You can pick up my latest ebuild (exim-4.52.ebuild) on bug #99412. 
It relies on an updated libspf2 ebuild on bug #100569. 
It also relies on the libsrs_alt ebuild on bug #58282. 
 
Both the SRS and SPF support have been tested. 
 
This would allow you to close at least 4 bugs. 
 
Action on this bug would be great.  I've been faithfully submitting updated 
ebuilds and patches on this for a while, now.  As in, 9 months. :-) 
  

the exim-4.50-r2 has some of your changes in it iirc, (I will confirm tonight),
the reason this hasn't been carried forward to 4.52 is due to the bug report
about  spf. (you should also find your libsrs_alt ebuild now in the tree).

(this has been in for a few weeks.) I can only apologise for the delay in
getting srs and spf support into exim, both exim maintainers have been very busy
as late, (hence the skip from 4.50 to 4.51

Oops.  I didn't check to see whether the libsrs_alt ebuild had been committed.  

I'll remove it from my local tree and eagerly await libspf2-1.2.5-r1 and 
exim-4.52.  Thanks. :-) 

Sheldon, can i close this bug now?

(In reply to comment #25)
> Sheldon, can i close this bug now?

Yeah, thanks Colin.  When I do a domainkeys patch, I'll open a new bug for
that. :-)

closing Bug.