From torsten at archesoft.de Fri May 6 05:12:25 2011 From: torsten at archesoft.de (Torsten Mueller) Date: Fri, 06 May 2011 14:12:25 +0200 Subject: [SA-exim] Compile SA against current exim Message-ID: <4DC3E5A9.7070200@archesoft.de> Hello, i remember, that it wasn't possible for me to compile SA cleanly against a current exim version. I remember too, that Marc wrote "To be honest, I'm pretty sure the last released version may not work as is anymore." Is there a chance, that SA will be moved to 4.2.2, which compiles against 4.76 (RC1). I would be very happy about this. Thank you Torsten From marc at merlins.org Fri May 6 09:51:24 2011 From: marc at merlins.org (Marc MERLIN) Date: Fri, 6 May 2011 09:51:24 -0700 Subject: [SA-exim] Compile SA against current exim In-Reply-To: <4DC3E5A9.7070200@archesoft.de> References: <4DC3E5A9.7070200@archesoft.de> Message-ID: <20110506165124.GC4529@merlins.org> On Fri, May 06, 2011 at 02:12:25PM +0200, Torsten Mueller wrote: > Hello, > > i remember, that it wasn't possible for me to compile > SA cleanly against a current exim version. > I remember too, that Marc wrote "To be honest, I'm pretty sure the last > released version may not work as is anymore." > Is there a chance, that SA will be moved to 4.2.2, which compiles > against 4.76 (RC1). I would be very happy about this. While it's a lame answer for me to give, I'm pretty sure debian has patches that make it work with recent exims since it's what I end up using. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ From torsten at archesoft.de Mon May 9 14:28:35 2011 From: torsten at archesoft.de (Torsten Mueller) Date: Mon, 09 May 2011 23:28:35 +0200 Subject: [SA-exim] Compile SA against current exim In-Reply-To: <20110506165124.GC4529@merlins.org> References: <4DC3E5A9.7070200@archesoft.de> <20110506165124.GC4529@merlins.org> Message-ID: <4DC85C83.5010206@archesoft.de> Marc MERLIN schrieb: > While it's a lame answer for me to give, I'm pretty sure debian has patches > that make it work with recent exims since it's what I end up using. So i tried my luck and probably this mail can help, if someone has the same problem like me. Please comment, if something could be done better. I don't run debian, but i download the sources and patches for SA from http://ftp.de.debian.org/debian/pool/main/s/sa-exim/ Today this is sa-exim_4.2.1-13.diff.gz and sa-exim_4.2.1.orig.tar.gz Download the exim sources and prepare the Makefile in the Local directory. untar sa-exim_4.2.1.orig.tar.gz, gunzip sa-exim_4.2.1-13.diff.gz, change to sa-exim-4.2.1 and patch the SA sources by patch -p1 < ../sa-exim_4.2.1-13.diff Modify the Makefile to match the exim src and SA conf path. Change to the exim directory and apply the patch from sa-exim-4.2.1 here: patch -p1 < localscan_dlopen_exim_4.20_or_better.patch Now compile exim. In the build-* directory there is the config.h, make a symlink to the exim src directory. Change to the SA src directory and build SA. If you get such an error "/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: /tmp/cc607USB.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /tmp/cc607USB.o: could not read symbols: Bad value collect2: ld returned 1 exit status" ,modify the Makefile of SA like this: CFLAGS=-O2 -Wall -fPIC I hope, it's o.k. to share my way this way. Greetings Torsten From daniel at dadap.net Wed May 18 22:28:18 2011 From: daniel at dadap.net (Daniel Dadap) Date: Wed, 18 May 2011 22:28:18 -0700 Subject: [SA-exim] SAaddSAEheaderBeforeSA ignored Message-ID: <1305782898.29122.18.camel@misi.dadap.net> Hello, I was trying to disable SAaddSAEheaderBeforeSA in sa-exim.conf, but no matter what I did, I was still getting unwanted headers in all my messages. I took a quick look at the source, and noticed the following: if(SAaddSAEheaderBeforeSA) { AddSAEheaders((char *)rcptlist, SAmaxrcptlistlength); } ... and a little bit later... if(!SAaddSAEheaderBeforeSA) { AddSAEheaders((char *)rcptlist, SAmaxrcptlistlength); } This doesn't seem intentional. I removed the ! from the second check, and setting SAaddSAEheaderBeforeSA worked as intended. I didn't read the code closely enough to know whether it's actually necessary to check in both places, so the attached patch only removes the negation and doesn't make any attempt to do anything else. It's entirely possible that the ! is intentional, and that I've misunderstood the intended operation of the program, but I'm going to leave my sa-exim patched like this, because it finally works the way I want it to. :) Regards, Daniel Dadap -------------- next part -------------- A non-text attachment was scrubbed... Name: dont-invert-saaddsaeheaderbeforesa.patch Type: text/x-patch Size: 377 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From richard at lithvall.se Thu May 19 02:05:22 2011 From: richard at lithvall.se (Richard Lithvall) Date: Thu, 19 May 2011 11:05:22 +0200 Subject: [SA-exim] SAaddSAEheaderBeforeSA ignored In-Reply-To: <1305782898.29122.18.camel@misi.dadap.net> References: <1305782898.29122.18.camel@misi.dadap.net> Message-ID: <20110519090522.GA22100@boomer.se> On Wed, May 18, 2011 at 10:28:18PM -0700, Daniel Dadap wrote: > Hello, > > I was trying to disable SAaddSAEheaderBeforeSA in sa-exim.conf, but no > matter what I did, I was still getting unwanted headers in all my > messages. > > I took a quick look at the source, and noticed the following: > > if(SAaddSAEheaderBeforeSA) > { > AddSAEheaders((char *)rcptlist, SAmaxrcptlistlength); > } > > ... and a little bit later... > > if(!SAaddSAEheaderBeforeSA) > { > AddSAEheaders((char *)rcptlist, SAmaxrcptlistlength); > } > > This doesn't seem intentional. It is intentional. I think you have misunderstood the purpose of this option: >From the sa-exim.config: # Add X-SA-Exim-Rcpt-To and X-SA-Exim-Mail-From headers before SA scans # the message. # If this option is enabled, SARewiteBody is true, and safe_mode is # enabled in SA, you end up with the X-SA-Exim-Rcpt-To/X-SA-Exim-Mail-From in # the attatched message as well without the ability to remove them later in an # exim transport (think privacy). # In real life this is usually not a problem because the message is spam anyway, # and if you turn this off, you lose the option to use those headers to score # the message with SA. The option is not meant to remove the headers completly, it's just a matter of *when* they are added. But if your patch does what you want it's all fine for you I guess :) /Richard From daniel at dadap.net Thu May 19 06:16:30 2011 From: daniel at dadap.net (Daniel Dadap) Date: Thu, 19 May 2011 06:16:30 -0700 Subject: [SA-exim] SAaddSAEheaderBeforeSA ignored In-Reply-To: <20110519090522.GA22100@boomer.se> References: <1305782898.29122.18.camel@misi.dadap.net> <20110519090522.GA22100@boomer.se> Message-ID: <1305810990.29122.31.camel@misi.dadap.net> On Thu, 2011-05-19 at 11:05 +0200, Richard Lithvall wrote: > On Wed, May 18, 2011 at 10:28:18PM -0700, Daniel Dadap wrote: > > Hello, > > > > I was trying to disable SAaddSAEheaderBeforeSA in sa-exim.conf, but no > > matter what I did, I was still getting unwanted headers in all my > > messages. > > > > I took a quick look at the source, and noticed the following: > > > > if(SAaddSAEheaderBeforeSA) > > { > > AddSAEheaders((char *)rcptlist, SAmaxrcptlistlength); > > } > > > > ... and a little bit later... > > > > if(!SAaddSAEheaderBeforeSA) > > { > > AddSAEheaders((char *)rcptlist, SAmaxrcptlistlength); > > } > > > > This doesn't seem intentional. > > It is intentional. I think you have misunderstood the purpose of this option: > > From the sa-exim.config: > # Add X-SA-Exim-Rcpt-To and X-SA-Exim-Mail-From headers before SA scans > # the message. > # If this option is enabled, SARewiteBody is true, and safe_mode is > # enabled in SA, you end up with the X-SA-Exim-Rcpt-To/X-SA-Exim-Mail-From in > # the attatched message as well without the ability to remove them later in an > # exim transport (think privacy). > # In real life this is usually not a problem because the message is spam anyway, > # and if you turn this off, you lose the option to use those headers to score > # the message with SA. > > The option is not meant to remove the headers completly, it's just a matter of *when* they are added. I see. Hence the "BeforeSA" in the option name. Looking at the source more closely, the second check is under the "exit:" label which is jumped to after the SA scan is performed. I did see that comment block in the config file, but I didn't give enough importance to the "before SA scans the message", and didn't understand that disabling the option still adds the headers, just after the scan. FWIW I did try adding 'headers_remove = X-SA-Exim-Connect-IP' (the specific header I wanted to suppress) to the remote_smtp transport, and when that didn't work, I added it to all of the transports, and I still get this header. I'll look into this further to find out why the transports don't seem to be doing what I want. (Disabling SAaddSAEheaderBeforeSA was the first thing I tried, so all of my experiments with the transports were done with it disabled.) > But if your patch does what you want it's all fine for you I guess :) It does, but when the occasional sa-exim update comes along, I'd rather not have to continue hacking it just to suppress the headers. I'll look into why the transports aren't working as expected and do the right fix. Thanks for your help, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: