[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: possible mass bug filing: spamassassin 3

On Wed, Oct 06, 2004 at 10:37:04PM +0200, Steinar H. Gunderson wrote:
> On Wed, Oct 06, 2004 at 10:01:12PM +0200, Sven Mueller wrote:
> > ??? Since when does exim4 use SA by default? AFAIK, you have to
> > specifically configure it to use it. Right? If so, there should be no
> > reason to remove it or for it to conflict with SA3.
> Well, if I dist-upgrade my mail server so a new spamassassin comes in, my
> mail setup breaks. Now, that is clearly broken, and an RC bug on some
> package.

I'm not really sure why or how your mail server breaks when a new
spamassassin comes in. If you're talking about exiscan-acl included
with exim4-daemon-heavy, it works fine with SpamAssassin 3.

Otherwise, it must be a local modification, which I can't speak to
unless I see it.
> > If a program is a front-end for SA and only works if SA is installed,
> > then it should keep up with any changes SA is doing to its API.
> Wrong. SA should not change its API in an incompatible fashion without also
> bumping its soname (ie. the package name in this case), like any other library.

As far as I know, few programs depend on the Mail::SpamAssassin
modules. Most choose to use the scripts instead.

> > And SA3 API isn't _that_ much different from SA2.6 API for the most used
> > interfaces.

Actually, virtually any program using SpamAssassin through the modules
will need to be changed. Most simply use the scripts, or spamc/spamd
or the SPAMD protocol directly. (These are all fine.)

> In that case, it should provide a backwards-compatible interface.

This was contemplated, but deemed to be difficult and ugly.

Duncan Findlay

Attachment: signature.asc
Description: Digital signature

Reply to: