Eric A. Hall writes: > I sometimes get SVN notifications that contain lists of files and their > status. The filenames will often get picked up by the URI matching > algorithm, each of which end up being processed through numerous lookups > (URICOUNTRY, my LDAP filter, etc). Sometimes I get very large messages > with hundreds of file lists, which in turn causes spamassassin to go into > never-never land while it thinks about the hundreds of "URI" matches. > > For example, > > A fpo/reports/perl/nagios_notifications1.pl.bak > A foo/reports/perl/nagios_outages1.pl > A foo/reports/perl/GWIR.pm > > nagios_outages1.pl will be determined as a URI for .pl domain and GWIR.pm > will be determined as a URI for .pm domain, and so forth. The only way to > get these messages through is to disable spamassassin... > > I've updated to 3.2.4 just now and it still has the same problem > > I'm guessing the URI analyzer needs to be smarter.
The URI analyzer already is smarter ;) Changing the URICountry plugin is the way to fix this. The Mail/SpamAssassin/Plugin/URIDetail plugin is a good example of how plugins can get metadata about the URIs via the get_uri_detail_list() API. looking at the POD doc and source for that in Mail/SpamAssassin/PerMsgStatus, I see that "types" == "parsed" should mean that the URI was inferred, instead of found in a link or image. URICountry should ignore URIs of that type. --j.
