[SA-exim] SAaddSAEheaderBeforeSA ignored

Daniel Dadap daniel at dadap.net
Thu May 19 06:16:30 PDT 2011


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: <http://lists.merlins.org/archives/sa-exim/attachments/20110519/59f8e86d/attachment-0001.pgp>


More information about the SA-Exim mailing list