Better exiscan integration with SpamAssassin

I've so far preferred SA-Exim to the exiscan spam condition because the latter 
is somewhat limited as to what you can do to with the messages you decide to 
let through (you only have $spam_score(_int), $spam_bar and $spam_report to 
play with).

There is an idea to add a new method to spamd that just returns the headers 
that SpamAssassin would have added (see 
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4469). I don't know 
what might become of that idea but if it becomes reality I think the new 
method would be the best one to use (because you could easily achieve the 
same result whether messages are passed through Exim calling SA or through 
spamassassin directly). Let's say that you in some future version could do 

warn   add_header = $spam_headers

There is one issue though, and that is that if SA-rewritten headers are to be 
included, then either you can't use rewrite_header in SA or you'd need a 
complicated construct in the system filter to remove all headers found in 
$spam_headers before the new headers could be added.

It could therefore conceivably be very handy to have a filter command that 
would *replace* headers in one action. It can probably be useful in other 
situations as well.

What do you think?

-- 
Magnus Holmgren

--

-- 

Exim 4.61 released

I have just put Exim release 4.61 on the primary ftp site:

  ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/exim4/exim-4.61.tar.gz
  ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/exim4/exim-4.61.tar.bz2

-------------------------------------------------------------------------------
This release contains a number of new features and fixes, some of which are 
documentation formatting fixes. The manual has been brought up-to-date with all
the changes since 4.60.

As usual, all changes are in the doc/ChangeLog file. See also the
README.UPDATING file for changes that might impact on some installations.
-------------------------------------------------------------------------------

The primary ftp server is in Cambridge, England. There is a list of mirrors in:

  ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/Mirrors

The distribution files are signed with Philip Hazel's GPG key, which is
available on the ftp site and on a number of keyservers. The signature files
are in the same directory as the tarbundles. The MD5 hash codes for the
distribution files are:

8f676ce83fd8bccc1e70da30cd42a987  exim-4.61.tar.gz
f6bbf99a6f63c0f5045a1779e7e810c4  exim-4.61.tar.bz2

The distribution contains an ASCII copy of the 4.61 manual and other documents.
Other formats of the documentation are also available:

Re: Better exiscan integration with SpamAssassin

Magnus Holmgren wrote:

> same result whether messages are passed through Exim calling SA or through 
> spamassassin directly). Let's say that you in some future version could do 
> 
> warn   add_header = $spam_headers

I don't trust SA enough to allow it to add a wad of headers in this way. 
  :)

> There is one issue though, and that is that if SA-rewritten headers are to be 
> included, then either you can't use rewrite_header in SA or you'd need a 
> complicated construct in the system filter to remove all headers found in 
> $spam_headers before the new headers could be added.

This was the reason for the more conservative path I chose back then.

Those who want message modification (including the irritating SA header 
spam) could still use SA-Exim or the standard pipe-I/O method.

Those who preferred not to trust SA mangling their email could use 
$spam_report, $spam_score etc.

/tom

--

-- 

Re: Better exiscan integration with SpamAssassin

onsdag 05 april 2006 11:55 skrev Tom Kistner:
> Magnus Holmgren wrote:
> > same result whether messages are passed through Exim calling SA or
> > through spamassassin directly). Let's say that you in some future version
> > could do
> >
> > warn   add_header = $spam_headers
>
> I don't trust SA enough to allow it to add a wad of headers in this way.
>   :)

Hmmm? You can configure SA, you know... And if that's not enough you can 
modify the source code. But on the other hand, you should usually trust 
nobody, not even yourself.

> > There is one issue though, and that is that if SA-rewritten headers are
> > to be included, then either you can't use rewrite_header in SA or you'd
> > need a complicated construct in the system filter to remove all headers
> > found in $spam_headers before the new headers could be added.
>
> This was the reason for the more conservative path I chose back then.
>
> Those who want message modification (including the irritating SA header
> spam) could still use SA-Exim or the standard pipe-I/O method.

Again, it can be reduced or turned off. 

> Those who preferred not to trust SA mangling their email could use
> $spam_report, $spam_score etc.

Re: Changing received_header_text default?

On Wednesday 01 March 2006 14:04, Michael Haardt wrote:
> I am unable to find which MTAs use spaces for folding, but I am sure to
> have seen it.

Qmail uses spaces:

Received: (qmail 17490 invoked from network); 1 Mar 2006 14:04:54 -0000
Received: from sesame.csx.cam.ac.uk (131.111.8.41)
  by spieden.seattleserver.com with SMTP; 1 Mar 2006 14:04:54 -0000
Received: from [::1] (port=4707 helo=sesame.csx.cam.ac.uk)
	by sesame.csx.cam.ac.uk with esmtp (Exim 4.44)
	id 1FERwc-0004us-8i; Wed, 01 Mar 2006 14:04:46 +0000

...but two spaces hardly seems any better than a single tab if excess 
whitespace is not removed when defolding.

> Concerning "look ugly"

I don't find either looks any better or worse than the other on it's own, but 
inconsistancy as shown above looks like crap.

Cheers,
-- 
Casey Allen Shobe | cshobe <at> seattleserver.com | 206-381-2800
SeattleServer.com, Inc. | http://www.seattleserver.com

--

-- 

Re: Changing received_header_text default?

On Friday 07 April 2006 04:11, Casey Allen Shobe wrote:
> On Wednesday 01 March 2006 14:04, Michael Haardt wrote:
> > I am unable to find which MTAs use spaces for folding, but I am sure to
> > have seen it.
>
> Qmail uses spaces:
>
> Received: (qmail 17490 invoked from network); 1 Mar 2006 14:04:54 -0000
> Received: from sesame.csx.cam.ac.uk (131.111.8.41)
>   by spieden.seattleserver.com with SMTP; 1 Mar 2006 14:04:54 -0000
> Received: from [::1] (port=4707 helo=sesame.csx.cam.ac.uk)
> 	by sesame.csx.cam.ac.uk with esmtp (Exim 4.44)
> 	id 1FERwc-0004us-8i; Wed, 01 Mar 2006 14:04:46 +0000

KMail seems to do the right thing for the To/CC headers, but not for the 
Content-Type...but poking around a bit, it seems like every other 
mime-compliant MUA uses two spaces in the Content-Type header as well...

User-Agent: KMail/1.9.1
Cc: netdev <at> vger.kernel.org,
 arndb <at> de.ibm.com,
 maxim <at> de.ibm.com
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"

Cheers,
--

-- 
Casey Allen Shobe | cshobe <at> seattleserver.com | 206-381-2800
SeattleServer.com, Inc. | http://www.seattleserver.com

spec.txt still says rfc1413_query_timeout = 30s in default config

Hello,
spec.txt "7. THE DEFAULT CONFIGURATION FILE" says
| The next two lines are concerned with ident callbacks, as defined by RFC 1413
| (hence their names):
| 
| rfc1413_hosts = *
| rfc1413_query_timeout = 30s

however the actual default configuration file features this:
| # connection, leading to delays on starting up SMTP sessions. (The
| # default was reduced from 30s to 5s for release 4.61.)
| 
| rfc1413_hosts = *
| rfc1413_query_timeout = 5s

cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde

--

-- 

Re: spec.txt still says rfc1413_query_timeout = 30s in default config

On Sun, 9 Apr 2006, Andreas Metzler wrote:

> Hello,
> spec.txt "7. THE DEFAULT CONFIGURATION FILE" says
> | The next two lines are concerned with ident callbacks, as defined by RFC 1413
> | (hence their names):
> | 
> | rfc1413_hosts = *
> | rfc1413_query_timeout = 30s
> 
> however the actual default configuration file features this:
> | # connection, leading to delays on starting up SMTP sessions. (The
> | # default was reduced from 30s to 5s for release 4.61.)
> | 
> | rfc1413_hosts = *
> | rfc1413_query_timeout = 5s

Noted, thanks.

-- 
Philip Hazel            University of Cambridge Computing Service
Get the Exim 4 book:    http://www.uit.co.uk/exim-book

--

-- 

Dropping all hosts with ignore_target_hosts results in "host lookup did not complete"

Please have a look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361919, 
which appears to be caused by the "DNS additional section" fix. Compiling 
4.60-4 without 37_upstream_patch_342619.dpatch ("approved by Philip") indeed 
solved this problem.

(In short, when ignore_target_hosts causes all looked-up hosts to be 
discarded, the router does not decline but routing is deferred.)

-- 
Magnus Holmgren

--

-- 

Re: Re: [exim-dev] Dropping all hosts with ignore_target_hosts results in "host lookup did not complete"

On Tue, 11 Apr 2006 12:48:38 +0200, Magnus Holmgren
<holmgren <at> lysator.liu.se> wrote:
>The missing line is present in upstream 4.61 sources. Whether this means  
>Philip is innocent or not is not up to me to decide.  But it's apparently 
>already fixed.

We have fixed that in exim4 4.50-8sarge2 for the next stable point
release. The offending code is thus only still present in 4.60-4 in
testing, which will be fixed tonight by pushing 4.61-1's urgency by
the release manager.

Greetings
Marc

-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

--

-- 
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/