[SA-exim] removing existing SA headers

[Chad Leigh -- Shire.Net LLC]

I know this was discussed before on the exim list (by me in fact many many moons ago), but I wanted to get clarification on what is supposed to happen.

A friends server that I help run is also running mailman.

A member of one of his mail lists posts and SA thinks it is a spam when it first is accepted by exim and then passed to mailman, which resends it. This resend is now originating from the server and so we do not rerun SA as we have a rule that all email that originates on the server do not run SA. However, the old SA headers are still being picked up by rules. I thought that sa-exim would remove the old headers

Here is an example set of headers (Ignore the ancient version of Spam Assassin -- it is being upgraded) (I blanked out the actual list name as it is not relevant and no need to feed spam machines more targets)

x-spam-flag: YES
x-spam-checker-version: SpamAssassin 3.1.7 (2006-10-05) on utah.object.com
x-spam-level: *******
x-spam-status: Yes, score=7.4 required=5.0 tests=BAYES_99,GREYLIST_ISWHITE, HTML_ATTR_UNIQUE,HTML_MESSAGE,NO_REAL_NAME autolearn=disabled version=3.1.7
x-spam-report: * 1.0 NO_REAL_NAME From: does not include a real name * 0.6 HTML_ATTR_UNIQUE BODY: HTML appears to have random attributes in * tags * 0.0 HTML_MESSAGE BODY: HTML included in message * 5.9 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * -0.1 GREYLIST_ISWHITE The incoming server has been whitelisted for this * recipient and sender
x-mailman-version: 2.1.9
precedence: list
list-id: Friends and Family from the Tri-Coastal Years <xxxx.object.com>
list-archive: <http://mailman.object.com/mailman/private/xxxx>
content-type: multipart/mixed; boundary="===============0021976616318316845=="
x-sa-exim-connect-ip: 209.41.94.251
x-sa-exim-scanned: No (on mail.object.com); SAEximRunCond expanded to false

The first set os x-spam stuff is from the original receipt by exim/sa-exim from the original poster

The final x-sa-exim ones are when it is re-received from mailman...


It has been several years since I messed with the mail system in any detail and I am not sure how this is supposed to be happening.

Thanks
Chad

[Marc MERLIN]

Post by Chad Leigh -- Shire.Net LLC
I know this was discussed before on the exim list (by me in fact many many moons ago), but I wanted to get clarification on what is supposed to happen.

So first, that wasn't your question but I suppose it's not surprise to
anyone here that SA-Exim is in maintenance mode at best.
I actually only recently noticed that the Debian SA-Exim maintainer fixed
some compilation problems between SA-Exim and newer versions of Exim (good)
without even reporting them back to me and giving me a chance to fix them
upstream (bad).
That said, SA-Exim just works for me still, most people have gone with
exiscan since it's built in into Exim, and while exiscan isn't as powerful
as SA-Exim in what it does spam and spammer wise, it's good enough for most,
so they don't bother looking for other options like SA-Exim (can't blame
them I suppose).

Anyway, all this to say that I had to go back and read my old code since I
just don't even quite remember it :)

Post by Chad Leigh -- Shire.Net LLC
A friends server that I help run is also running mailman.
A member of one of his mail lists posts and SA thinks it is a spam when it first is accepted by exim and then passed to mailman, which resends it. This resend is now originating from the server and so we do not rerun SA as we have a rule that all email that originates on the server do not run SA. However, the old SA headers are still being picked up by rules. I thought that sa-exim would remove the old headers

Yep, the code says so.

But my guess is that mailman resends your Email outside without filtering it
through SA-Exim since it's local Email and therefore not spam.
If you want to remove those SA-Exim headers, they'd have to be removed
by Exim's remote_smtp transport before you send your mailman messages back out.

remote_smtp:
debug_print = "T: remote_smtp for $local_part@$domain"
driver = smtp
# This deals with misocnfigurations like this one that redirect mail to us
# (i.e. 'mail' is unqualified and resolves back to us)
# worldclasssportfishing.net MX 30 mail
dns_qualify_single = false
# This fixes a problem if TLS is enabled where a misunderstanding on the RFC
# can cause comunication failure between two hosts
hosts_nopass_tls = *
hosts_avoid_tls = +hosts_avoid_tls
hosts_try_auth = +hosts_try_auth
# This is generally set on messages originating from local users and it tells
# SA-Exim not to scan the message or that the message was scanned.
# Let's remove these headers if the message is sent remotely
headers_remove = "X-SA-Do-Not-Run:X-SA-Exim-Scanned:X-SA-Exim-Rcpt-From:X-SA-Exim-Rcpt-To:X-SA-Exim-Ver
sion"


Marc

[Chad Leigh -- Shire.Net LLC]

Post by Marc MERLIN

Post by Chad Leigh -- Shire.Net LLC
I know this was discussed before on the exim list (by me in fact many many moons ago), but I wanted to get clarification on what is supposed to happen.

So first, that wasn't your question but I suppose it's not surprise to
anyone here that SA-Exim is in maintenance mode at best.

Sure.

Post by Marc MERLIN
I actually only recently noticed that the Debian SA-Exim maintainer fixed
some compilation problems between SA-Exim and newer versions of Exim (good)
without even reporting them back to me and giving me a chance to fix them
upstream (bad).

That is not very nice.

Post by Marc MERLIN
That said, SA-Exim just works for me still, most people have gone with
exiscan since it's built in into Exim, and while exiscan isn't as powerful
as SA-Exim in what it does spam and spammer wise, it's good enough for most,
so they don't bother looking for other options like SA-Exim (can't blame
them I suppose).

I have been using SA-exim since forever -- why "fix" something that isn't broke ;-)

I have also been using the SA-exim greylisting as well snice like forever

Post by Marc MERLIN
Anyway, all this to say that I had to go back and read my old code since I
just don't even quite remember it :)

You're welcome ;-)

Post by Marc MERLIN

Post by Chad Leigh -- Shire.Net LLC
A friends server that I help run is also running mailman.
A member of one of his mail lists posts and SA thinks it is a spam when it first is accepted by exim and then passed to mailman, which resends it. This resend is now originating from the server and so we do not rerun SA as we have a rule that all email that originates on the server do not run SA. However, the old SA headers are still being picked up by rules. I thought that sa-exim would remove the old headers

Yep, the code says so.
But my guess is that mailman resends your Email outside without filtering it
through SA-Exim since it's local Email and therefore not spam.
If you want to remove those SA-Exim headers, they'd have to be removed
by Exim's remote_smtp transport before you send your mailman messages back out.

I will look at the stuff below and try it out or something similar.

SA-exim does seem to get run again on the resend though, since the headers

Post by Marc MERLIN
x-sa-exim-connect-ip: 209.41.94.251
x-sa-exim-scanned: No (on mail.object.com); SAEximRunCond expanded to false

are there from the second time. It does not run the scanner, but sa-exim glue is run and it inserts the headers! Am I understanding it wrong?

Post by Marc MERLIN
driver = smtp
# This deals with misocnfigurations like this one that redirect mail to us
# (i.e. 'mail' is unqualified and resolves back to us)
# worldclasssportfishing.net MX 30 mail
dns_qualify_single = false
# This fixes a problem if TLS is enabled where a misunderstanding on the RFC
# can cause comunication failure between two hosts
hosts_nopass_tls = *
hosts_avoid_tls = +hosts_avoid_tls
hosts_try_auth = +hosts_try_auth
# This is generally set on messages originating from local users and it tells
# SA-Exim not to scan the message or that the message was scanned.
# Let's remove these headers if the message is sent remotely
headers_remove = "X-SA-Do-Not-Run:X-SA-Exim-Scanned:X-SA-Exim-Rcpt-From:X-SA-Exim-Rcpt-To:X-SA-Exim-Ver
sion"
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 & security ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/

[Magnus Holmgren]

Post by Marc MERLIN

Post by Chad Leigh -- Shire.Net LLC
I know this was discussed before on the exim list (by me in fact many
many moons ago), but I wanted to get clarification on what is supposed to
happen.

So first, that wasn't your question but I suppose it's not surprise to
anyone here that SA-Exim is in maintenance mode at best.
I actually only recently noticed that the Debian SA-Exim maintainer fixed
some compilation problems between SA-Exim and newer versions of Exim (good)
without even reporting them back to me and giving me a chance to fix them
upstream (bad).

Oh, sorry about that. I must have thought you were following the Debian
package from time to time.

[Marc MERLIN]

Post by Magnus Holmgren

Post by Marc MERLIN

Post by Chad Leigh -- Shire.Net LLC
I know this was discussed before on the exim list (by me in fact many
many moons ago), but I wanted to get clarification on what is supposed to
happen.

So first, that wasn't your question but I suppose it's not surprise to
anyone here that SA-Exim is in maintenance mode at best.
I actually only recently noticed that the Debian SA-Exim maintainer fixed
some compilation problems between SA-Exim and newer versions of Exim (good)
without even reporting them back to me and giving me a chance to fix them
upstream (bad).

Oh, sorry about that. I must have thought you were following the Debian
package from time to time.

It gets installed on my machine, and it worked so I saw no problem :)

I'm not mad BTW, just pointing out that it's a common debian fault wrt to
upstream which causes fragmentation in some cases.
In this case, it's pretty safe to say that only debian/ubuntu users use
SA-Exim at this point since I got 0 complaint about building issues in the
last 3 years, so there is really nothing to fix :)

All that said, thanks for your work, just a reminder not to forget upstream.
In this case it's mostly only debian, but upstreams can't be expected to
follow bugs in 5+ different linux distributions if the core bugs aren't
pushed back to them.

Cheers,
Marc