https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6268
Summary: SA die()s if can't create the userstate dir
Product: Spamassassin
Version: 3.3.0
Platform: Other
OS/Version: All
Status: NEW
Severity: blocker
Priority: P1
Component: spamassassin
AssignedTo: [email protected]
ReportedBy: [email protected]
Programs using the API such as MIMEDefang testing with the 3.3.0rc1.
The 3.3.0 rc1 (at least) has a die if the userstate dir can't be created.
MD is currently using a workaround as shown below:
> we specifically set a user_dir.
> SA 3.3.0-rc1 dies if it can't create the user state directory
> (See Mail::SpamAssassin->get_and_create_userstate_dir())
>
> As a workaround until we fix MIMEDefang, you need to create your
> own $SASpamTester in your filter, supplying an appropriate userstate_dir:
>
> # Put this somewhere in your filter....
>
> use vars qw($SASpamTester);
>
> $SASpamTester = Mail::SpamAssassin::new({
> local_tests_only => 1, # or 0 depending on what you want
> dont_copy_prefs => 1,
> userprefs_filename => '/etc/mail/sa-mimedefang.cf', # or whatever
> user_dir => '/some/path});
>
> The directory '/some/path' will be used as the "home" directory for
> SpamAssassin's purposes; it must be readable/writable/searchable by
> the "defang" user. A good choice might be /var/spool/MIMEDefang.
I'm unsure if the change to a die for the lack of a user_dir was intentional.
So anyone know if/why/etc?
--
Configure bugmail:
https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
