Bug 4862 - [review] CONTACT_ADDRESS superseded by rules file downloaded through sa-update
Summary: [review] CONTACT_ADDRESS superseded by rules file downloaded through sa-update
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: sa-update (show other bugs)
Version: 3.1.1
Hardware: Other NetBSD
: P3 minor
Target Milestone: 3.1.4
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard: can be committed
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-11 23:04 UTC by Klaus Heinz
Modified: 2006-07-09 17:10 UTC (History)
0 users


Attachment Type Modified Status Actions Submitter/CLA Status
suggested patch patch None Theo Van Dinter [HasCLA]
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Klaus Heinz 2006-04-11 23:04:10 UTC 
Hi,
 
after installation of SA 3.1.1 share/spamassassin/10_misc.cf contains:
 
  report_contact postmaster@example.com
 
Today I tried sa-update for the first time and noticed that the updated
file 10_misc.cf contains

  report_contact @@CONTACT_ADDRESS@@

This leads to reports like this:           

  .. If you have any questions, see @@CONTACT_ADDRESS@@ for details...

I think this setting should probably move from 10_misc.cf to the local.cf
file so it would not be affected by updates.
 
ciao
     Klaus
Comment 1 Theo Van Dinter 2006-06-09 16:24:27 UTC 
I'm not really sure how we can deal with this yet.  The problem being that the @...@ macros are only 
handled during the install and the values aren't stored anywhere else.  So a kluge would be to parse out 
stuff from the installed rule files and then replace values accordingly, but that's horrible and we shouldn't 
do it. ;)

I'm thinking that the install process ought to create a new file in the default area, perhaps /usr/share/
spamassassin/macros or something, that have the mappings.  Or, we just create something like /etc/
mail/spamassassin/install.cf that sets the macro settings, and then things like sa-update doesn't have to 
worry about it.

I don't know, but we should probably do something.
Comment 2 Radoslaw Zielinski 2006-06-09 17:58:52 UTC 
(In reply to comment #1)
> I'm thinking that the install process ought to create a new file in the
> default area, perhaps /usr/share/spamassassin/macros or something, that
> have the mappings.

Administrator might want to edit this file, so placing it in /usr would
violate FHS.

> Or, we just create something like /etc/mail/spamassassin/install.cf
> that sets the macro settings, and then things like sa-update doesn't
> have to worry about it.

That sounds sane... if local.cf is not enough.
Comment 3 Theo Van Dinter 2006-06-27 05:43:19 UTC 
ok, after prodding around I think I came up with a pretty easy fix for this.

sa-update gets preprocessed during install with the variables defined via the
Makefile.  Therefore, if we add in macro processing capabilities into sa-update,
and trap the defined variables during install, it should all work fine.  I'll
see about working up a patch. :)
Comment 4 Theo Van Dinter 2006-06-27 06:23:05 UTC 
ok, here's the patch ready for 3.1.  committed to 3.2:

Sending        sa-update.raw
Transmitting file data .
Committed revision 417353.
Comment 5 Theo Van Dinter 2006-06-27 06:23:27 UTC 
Created attachment 3562 [details]
suggested patch
Comment 6 Justin Mason 2006-06-29 09:24:07 UTC 
+1 perfect workaround ;)
Comment 7 Daryl C. W. O'Shea 2006-07-09 21:54:46 UTC 
cool, +1
Comment 8 Theo Van Dinter 2006-07-10 00:10:30 UTC 
Sending        sa-update.raw
Transmitting file data .
Committed revision 420376.