Re: SAaddSAEheaderBeforeSA ignored

--===============1746202523==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-DEZ3MfCihhJfO6eONfm3"


--=-DEZ3MfCihhJfO6eONfm3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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.
>=20
> It is intentional. I think you have misunderstood the purpose of this opt=
ion:
>=20
> 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-Fro=
m 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 s=
core
> # the message with SA.
>=20
> The option is not meant to remove the headers completly, it's just a matt=
er 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 =3D 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

--=-DEZ3MfCihhJfO6eONfm3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABECAAYFAk3VGCgACgkQObn9Ub+O3tPzpgCeIV66IS6fEBtpRrPAAW+cn1XF
90sAoLiooNVD0r/zJS8EU5hJsdNIpqek
=Hv+8
-----END PGP SIGNATURE-----

--=-DEZ3MfCihhJfO6eONfm3--



--===============1746202523==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
SA-Exim mailing list
[email protected]
http://lists.merlins.org/lists/listinfo/sa-exim

--===============1746202523==--