This idea came up on the list, specifically w/ the suggestion of mailing the
report to the "report_contact" setting.  I'm against that idea, since
report_contact is a generic string which may or may not have an email address in
a  unknown context.  So the easy way to solve this would be for the proposed
optional --report parameter to take a list of email addrs, separated via commas
(so it can easily be put into the message's "To" field).

My other issue with this idea is related to having to have sa-update learn how
to send email.

Generally though, I like the idea and just need to think about the issue.  It
would definitely be useful in some environments to get something like:

Subject: sa-update report <timestamp>

Channel updates.spamassassin.org:
Previous version: 123456
Updated version : 123457
No failures, install successful.

Channel someotherplace.example.com:
Previous version: 4
Updated version : 12
Channel failed to update due to GPG signature failure.

can we assume that it's being run from cron?  if so, we can just print that to
STDOUT, and cron will take care of the mailing part.

(In reply to comment #2)
> can we assume that it's being run from cron?  if so, we can just print that to
> STDOUT, and cron will take care of the mailing part.

Perhaps:

--report => send to stdout
--report email1,email2,... => send to email

?

cron is likely on *nix, but not Windows, etc.

oh, I would assume that the STDOUT version would be more terse than the email
option, so that anyone manually running the script doesn't have to deal with a
huge amount of output.  maybe just one line per channel or something.

I generally put my cron type jobs inside wrappers and trap exit codes for other
purposes, like analyzing tables only if a dump succeeded, zipping logs if a
script did not fail, etc. So even on Unix STDOUT can't be counted on. I like the
idea of a --report option. I don't know what kind of issues that creates for
Windows installs though.

I do believe nothing more than my orignal proposal for report content would be
needed. If the response was eighty pages of verbose error text, I would still go
run "sa-update -D", wouldn't anyone else?

moving RFEs and low-priority stuff to 3.3.0 target

I don't think this will happen, especially now that sa-update is
getting a --verbose option with SA 3.3.0 - as per comment 2, cron can
take care of mail delivery of the produced report.

Otherwise, a shell script wrapper can send an appropriate message based
on the exit status of sa-update. Configuring admin mail address and
selecting/implementing a mechanism to be used for submitting a mail message
is well outside of scope of a simple utility like sa-update.

Closing. Please reopen if someone thinks otherwise.