Use X-Amavis-Alert header to influence Spam Assassin Scoring

C.J. Collier cjcollier at linuxfoundation.org
Tue Mar 15 03:28:13 CET 2016


I think that re-factoring amavis into smaller chunks so that spamassassin
can «use» those modules will reduce the duplicated code, if not the
duplicated effort.

What is the benefit of having all of the 71 packages in the same file?
This will make it difficult to write and exercise unit tests.  If it's the
concern of handling 71 different file handles, the build system could
concatenate all of the individual files to a single monolithic script for
distribution.

Can you tell I've been thinking about this the last 24 hours? :-)

Cheers,

C.J.


On Mon, Mar 14, 2016 at 12:02 PM, Josh Hamell <jhamell at sift.net> wrote:

> On 3/8/2016 3:00 AM, amavis-users-request at amavis.org wrote:
> > On 7 Mar 2016, at 12:13, Josh Hamell <jhamell at sift.net> wrote:
> >> >
> >> > Amavis headers are injected in immediately before delivery, and
> >> > therefore aren't available for SA to analyze.
> > This is my understanding, amavis headers aren't there until after SA
>
> Thank you - SA is batting about 92% detection rate for the resulting
> BANNED messages.  If it does become an issue, I will need to configure
> SA to look at attachments (duplicating the work of AMAVIS), but this may
> be enough for now.
>
> -Josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.amavis.org/pipermail/amavis-users/attachments/20160314/024e670d/attachment.html>


More information about the amavis-users mailing list