aiming at 2.60

Hmmm... we already have "always_add_report" so I'd merge those two to 
  add_report_header {0 | 1 | 2} 
where 
  0 = never 
  1 = spam only 
  2 = always 
(and make the old ones still work to annoy the updating users as less as 
possible) 

Subject: Re:  Rename "use_terse_report" to be more meaningful?

On Mon, Aug 25, 2003 at 02:01:45AM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> Hmmm... we already have "always_add_report" so I'd merge those two to 
>   add_report_header {0 | 1 | 2} 
> where 
>   0 = never 
>   1 = spam only 
>   2 = always 
> (and make the old ones still work to annoy the updating users as less as 
> possible) 

Well, I like the idea of merging the two together, but there would
unfortunately need to be 4 different options:

0 = never (Default)
1 = ham only
2 = spam only
3 = always

and "use_terse_report" would be an alias for "always_add_report 2".
The code would also have to deal with having both always_add_report
and use_terse_report.  Something like:

if /always_add_report/: $always_add_report = $_;
if /use_terse_report/: {
	if ( $always_add_report ) {
		$always_add_report = 3 if ( $always_add_report == 1 );
	}
	else {
		$always_add_report = 2;
	}
}

Since both use_terse_report and always_add_report are both deprecated
in 2.60, it's not a big deal imho.

Thoughts?

I like that.  Keeping backwards compat IMO is key, as I don't think we should
"break" the report-tweaking config settings again, as we've been churning these
on pretty much every major release AFAICS.

  0 = never (Default) 
  1 = spam only   
  2 = ham only 
  3 = always 
is better I think; normally if you go and switch this option on, you want to 
do it on spam. So our "standard" true value 1 should equal "spam". 
 
The nice thing is that those are bitmasks. So the code could look like this: 
  $add_report_header = 0 
  foreach line do 
    if /add_report_header/: $add_report_header  = $_ 
    if /always_add_report/: $add_report_header  = 3 
    if /use_terse_report/:  $add_report_header |= 1 
  end for 
 

Created attachment 1269 [details]
first part of proposed fix

Okay, this patch restores backward compatibility with 2.5x for use_terse_report

and always_add_report.	It also adds a _LONGREPORT_ header symbol which someone

still needs to code up.

+.5: missing 1 thing, the suggested replacement for always_add_report should use
_LONGREPORT_.

Created attachment 1279 [details]
first part of proposed fix

Still missing LONGREPORT, but it will at least work until someone fixes it,
enough to +1 for now?

Created attachment 1280 [details]
complete fix

This patch fixes the current problems with 2.60-rc2:

1. various documentation improvements and corrections
2. always_add_headers is made backward-compatible with 2.5x by moving the
   defaults code into two functions (one is needed for "always_add_headers 1")
3. always_add_report is made backward-compatible with 2.5x
4. use_terse_report is made to do nothing (the current code behaves in a very
   unexpected fashion) and is deprecated
5. X-Spam-Report: is disabled if report_safe is enabled for
   backward-compatibility with 2.5x
6. make X-Spam-Report: headers less ugly

Nobody has even fixed the terse report format to look nice, so I see zero
point in supporting two formats for header reports (terse and verbose).
Header reports have also been less important since 2.50 added report_safe so
reports could be added to the body without destroying the original message.

However, since it's possible to provide backward-compatibility with almost
everything else, I think we should make a reasonable effort.

diffstat:

 lib/Mail/SpamAssassin/Conf.pm         |  100 ++++++++++++++++------------------
 lib/Mail/SpamAssassin/PerMsgStatus.pm |    6 +-
 rules/10_misc.cf                      |   12 ++--
 3 files changed, 59 insertions(+), 59 deletions(-)

ah, yes :-)

assigning bug

adding CC ;) 

+1 1280  
 
Some non-show-stopping issues: 
* I don't like what always_add_report does compared to its semantic but as its 
deprecated renaming it isnt worth it (and it behaves like 2.5x did). 
* If somebody wants both the Report header and report_safe but happens to 
specify the add_header before the report_safe, his header will be removed 
again. Could be worked around but I don't think its worth it -- we can fix it 
if somebody complains ;-) 

+1 1280.

Does anyone really want _LONGREPORT_?  Simon, you reading?

committed 1280

OK, we've decided not to support a long report in the headers for rc3 to reduce
the support required for 2 header report formats.  If anyone wants it in 2.60
release, please speak up ASAP!