On Tuesday 01 March 2005 5:54 pm, Nick Harring wrote:
> > On Mar 1, 2005, at 1:34 PM, Rick Macdougall wrote:
> > > Is that a good idea ? Say a spam slips through that forges the SA
> > > headers ?
> > >
> > > (Yes, I'm playing devil's advocate here, since SA already checks for
> > > just that type of thing and ignores them/strips them out, but what
> > > happens when some new admin doesn't install SA correctly and the
> > > does NOT get scanned by SA but the spammers have made it look like
> > > has.)
> > >
> > > I'll keep quiet now :)
> > If a message forges SA headers to appear as ham when it's really spam,
> > then that isn't any different than not having the headers at all (as
> > far as vdelivermail storing it in a spam folder).
> > If you're running SA, it will strip out any old spam headers before
> > outputing its own headers, so it isn't an issue.
> > If you're not running SA, then a ham message with forged headers
> > indicating that it was spam could end up in the spam folder, but why
> > would someone want to do that?
> The only remaining concern I have is that now vpopmail and spamassassin
> upgrades become linked. If, heavens forbid, vpopmail becomes less
> maintained at some point, and SA makes a shift in the headers then all
> the users are adrift with an outdated SA version until somebody hacks up
> the code. Or of course they can turn off the nifty keen feature and
> reimplement using procmail or whatever. However if developers are
> willing to shoulder this potential workload, who am I to complain?
It's not too big a deal. I went through the spamassassin 2.63 to 3.X version
upgrade where they changed the header format. One we figured out the new
format it was just a few lines of code that changed.