> 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 mail > > does NOT get scanned by SA but the spammers have made it look like it > > 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?
