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
signature.asc
Description: Digital signature
