-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Robert Menschel writes:
> TVD> Versions are tracked per channel and SpamAssassin version. To check
> TVD> for updates, do a DNS TXT query ala
> TVD> "z.y.x.updates.spamassassin.org",
> TVD> where z.y.x refers to the version of SpamAssassin being used, aka:
> TVD> x.y.z for 3.0.2, etc. For simplicitly, wildcards can be used on the
> TVD> DNS server to match a whole set of releases. An example:
>
> TVD> *.0.3.updates.spamassassin.org TXT "154203"
> TVD> *.1.3.updates.spamassassin.org TXT "158203"
>
> And I assume that *.*.3 would also be viable to accept rules for all
> 3.x.x versions, or more to the point, *.*.2 could be used within SARE
> to flag rules that apply to all 2.xx versions that predate 3.0.0.
Hold on -- something's just occurred to me from the SPF development;
this won't be possible, because BIND doesn't support bar.*.foo wildcards
(ie. wildcards in a non-lowest-level record.)
We may have to have a way to explicitly mark wildcards. in other
words, do lookups like
1.0.3.updates.spamassassin.org
star.0.3.updates.spamassassin.org
star.3.updates.spamassassin.org
star.updates.spamassassin.org (possibly N/A)
- --j.
> TVD> The directory that is to be mirrored out appropriately looks like:
> TVD> dir/
> TVD> MIRRORED.BY
> TVD> version.ext
> TVD> version.ext.sha1
> TVD> ...
> TVD> versionn.ext
> TVD> versionn.ext.sha1
>
> TVD> with "version.ext.gpg .. versionnn.ext.gpg" available optionally.
> TVD> I don't think GPG needs to be required, but for the paranoid
> TVD> amongst us, it needs to be available as an option.
>
> Where do these updates come from? When would the GPG signature be
> applied, and by whom/what? Within SARE we have multiple working
> files, and I can see our scripts combining all files that match a
> given critiera into a single channel file. The original files are
> sometimes signed to validate them, but I don't see any value to having
> an automated script sign the compilation. I suppose it might be a YMMV
> situation.
yep. at the least, this serves to avoid someone subverting a mirror and
putting up their own files without at least stealing the signing key too.
It's definitely a good idea.
> TVD> At the end, the script outputs a number of channel.cf files,
> TVD> which by default will just be read by SpamAssassin at startup
> TVD> (leaving restarting spamd up to the admin outside the script,
> TVD> based on exit code...) If a different directory is used, admin
> TVD> can simply include the channel.cf file in their local.cf.
>
> Good.
>
> TVD> There are a few things I haven't fully fleshed out yet:
>
> TVD> 1) How to archive the update files together? I envisioned a
> TVD> similar naming convention to our normal rules directory (ie: a
> TVD> bunch of files named ##_type.cf), but the script should just
> TVD> expect to download a single file which will then be expanded. I
> TVD> don't want to rely on system calls to run an expansion, nor do I
> TVD> want to expect tar or zip to be installed, etc.
>
> I would think that the compilation script could simply cat the
> component files together. eg [I often use shell as my meta language]:
> version=$yyyymmddhhss # simple version calc
> # loop through compilation definition files.
> # For each definition, grab output file name from line 1.
> # Remainder of lines name files fed into compilation.
> for compilefile in $compiledir/*.compile ; do
> outfile=$( sed 1q $(<compilefile) )
> newer=no # assume this compilation not updated
> # For each file in the compilation, check to see if it is newer
> # than the last compilation built.
> for infile in $( sed -n 2,\$p $compilefile ) ; do
> if [[ $infile -nt $outfile ]]
> then newer=yes
> fi
> done
> # If any input file is newer than the last compilation built,
> # the build a new compilation.
> if [[ $newer = yes ]]
> then echo $version > $outfile
> cat $( sed -n 2,\$p $compilefile ) >>$outfile
> fi
> done
>
> TVD> 3) Using "channel.cf" means that it may or may not come after
> TVD> local.cf. We should probably use some form of prefix to get it to
> TVD> load beforehand, but what? People should be able to override the
> TVD> channel config if they want to. I don't know if I want
> TVD> "AA_updates_spamassassin_org.cf"
> TVD> as a file.
>
> I would agree that we want all channel files to come before local.cf
> alphabetically, and also want them to have reasonably short names.
>
> What about a name like CH.$channel.$abbr.cf where $channel is the
> channel file name (eg: updates, scores, hispamnoham, etc), and $abbr
> is an abbreviation for the source of that channel (perhaps fed through
> a second field on line 1, or through the second line of the channel
> file). That would give us files like:
> CH.updates.SA.cf
> CH.scores.SA.cf
> CH.hispamnoham.SARE.cf
>
> This leaves open the question of how do we prioritize the occasional
> override?
>
> Let's say SARE includes an "english" channel, containing our rules
> that work well in the English language, USA, UK, Australia, etc., but
> does not work nearly as well for sites that receive emails in other
> languages. Let's then say that SARU (our Russian counterparts) create
> a channel which simply rescores our "english" channel to reflect
> mass-check results in their part of the world. How can we guarantee
> that their channel file scores override our scores?
prioritisation would be something that we should be able to handle
at the client end, in my opinion -- in the file where the channels
are defined.
What about just letting the rule file names be defined there?
> To help those who need to put these into a user_prefs file, it'd be
> good to include an option(s) which specifies that a) output will be to
> $HOME/.spamassassin/user_prefs, b) all channel files should be
> concatenated together, along with a core user_prefs file, and c)
> whether that core precedes or follows the accumulated channel files.
I think for this case, an option to output to stdout would
help.
> TVD> - if GPG is enabled, validate version.foo.gpg (depends on the "how to
> do
> TVD> gpg" issue)
> TVD> - if failed, fail channel, goto next channel
> TVD> - file fails if signature fails, or if signature is ok but not
> signed by
> TVD> list of "trusted" keys
>
> This might be a good place to also --lint the received channel file,
> and fail any channel file that fails --lint.
yep, good plan.
- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Exmh CVS
iD8DBQFCCkn8MJF5cimLx9ARAtiBAKCN74KFcmJbNagAjN6RNmOcqhXI8QCfSYQo
LLDzAw8cpR4maw7BlxkS+eg=
=Gj+u
-----END PGP SIGNATURE-----
