Bug#397779: libmail-spf-query-perl should have dependency on LMAP::CID2SPF module
Package: libmail-spf-query-perl Maintainer: Chip Salzenberg [EMAIL PROTECTED] Architecture: all Version: 1.997-3 The Perl module Mail::SPF::Query in libmail-spf-query-perl uses LMAP::CID2SPF but AFAIK this module is not available as a Debian package. When spamassassin is installed in combination with libmail-spf-query-perl then the following error will end up in /var/log/mail.warn Nov 7 22:28:00 jet spamd[514]: Can't locate LMAP/CID2SPF.pm in @INC (@INC contains: ../lib /usr/share/perl5 /etc/perl /usr/local/li b/perl/5.8.7 /usr/local/share/perl/5.8.7 /usr/lib/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl) at /usr/shar e/perl5/Mail/SPF/Query.pm line 1757, GEN154 line 51. suggestion: create a package for the LMAP::CID2SPF module and add this as a dependency to libmail-spf-query-perl Apparently, once upon a time there was a package called liblmap-cid2spf-perl Source for LMAP::CID2SPF can be downloaded from http://www.baschny.de/spf/LMAP-CID2SPF-0.9.tar.gz it depends on Parse:XML (packaged in libxml-parser-perl) Regards, Peter Fokkinga
Bug#397779: libmail-spf-query-perl should have dependency on LMAP::CID2SPF module
Peter Fokkinga wrote: Package: libmail-spf-query-perl Version: 1.997-3 The Perl module Mail::SPF::Query in libmail-spf-query-perl uses LMAP::CID2SPF but AFAIK this module is not available as a Debian package. When spamassassin is installed in combination with libmail-spf-query-perl then the following error will end up in /var/log/mail.warn Nov 7 22:28:00 jet spamd[514]: Can't locate LMAP/CID2SPF.pm in @INC (@INC contains: ../lib /usr/share/perl5 /etc/perl /usr/local/lib/perl/5.8.7 /usr/local/share/perl/5.8.7 /usr/lib/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl) at /usr/shar e/perl5/Mail/SPF/Query.pm line 1757, GEN154 line 51. Short answer: This is really a design bug in Mail::SPF::Query 1.998. Long answer: LMAP::CID2SPF was supposed to translate DNS records of Microsoft's long- dead Caller ID[1] (not to be confused with their newer proposal called Sender ID) to SPF records. However the Caller ID records out there can be counted on a single hand, so there is no point in supporting those records in Mail::SPF::Query. Since this is a bug in Mail::SPF::Query 1.997 (and earlier), which is in the current stable (AKA Sarge) distribution, an upload to proposed- updates removing the use og LMAP::CID2SPF would be the appropriate and minimally invasive solution. An upload of 1.999.1 to proposed-updates might be a viable alternative. However, as Etch is about to be released soon, there is probably little point in making a proposed-updates upload now... Thus I propose to tag this bug wontfix. Any objections? Julian, both upstream maintainer and a member of the Debian Perl Group. References: 1. http://en.wikipedia.org/wiki/MARID pgpBYPkhLHnpX.pgp Description: PGP signature
Bug#397779: libmail-spf-query-perl should have dependency on LMAP::CID2SPF module
Hi Julian, Quoting Julian Mehnle [EMAIL PROTECTED]: Since this is a bug in Mail::SPF::Query 1.997 (and earlier), which is in the current stable (AKA Sarge) distribution, an upload to proposed- updates removing the use og LMAP::CID2SPF would be the appropriate and minimally invasive solution. An upload of 1.999.1 to proposed-updates might be a viable alternative. However, as Etch is about to be released soon, there is probably little point in making a proposed-updates upload now... Thus I propose to tag this bug wontfix. Any objections? No objection really, but I would prefer the proposed-updates alternative: 1. not everyone will upgrade to Etch at its release (to some of us there's virtue in long(er) release cycles) 2. putting a fix in proposed-updates might be helpfull in propagating the fix to other distros (Ubuntu 6.06 most notably); not your concern of course, but still :) Anyway, if the proposed-updates is a labourous job then by all means tag it wontfix. Thanks for you elaborate explanation, Peter