> 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?

Reply via email to