> > It is only a partial solution. It covers only one method > > of authorizing roaming users for submitting mail to their > > organization's MSA. It would be much better to have > > a more general solution, trusting MSA to do its job > > (see parallel thread "internal/trusted again, MSA tested > > for SPF?")
> Agreed in the case of a totally separate MSA host. Right. If it is not separate I agree this remains to be a more difficult problem. > Although in that case, I'm not sure about what benefit there is > to scanning the mail at all. Here are some good reasons to spam-scan (and virus-scan) outgoing mail: - an internal host (or a roaming laptop) may become infected, turned into a spam-spewing zombie or a virus-propagating host. It is wise to catch them as soon as possible, better in-house, blocking pollution from spreading and retaining company face. It also facilitates locating such a host. - internal user may intentionaly start sending spam. Letting administrator become aware of it can lead to educating users about company policy. An in-house bounce can make a good-faith user rephrase his mail and avoid risking it to be junked on the recipient's side. - letting Bayes auto-learn on both outgoing and incoming mail leads to a better database, with more high-quality samples of ham. - and a shameless plug: amavisd-new-2.4.2 introduced pen-pals whitelisting scheme (based on a database of all recent mail messages), reducing spam score on replies to previous outgoing mail if sender/recipient address pair exactly matches previous recipient/sender pair. For this to work mail must pass through a content filter in both directions. Btw, it could just as well be made into a SA plugin, it was just easier for me to use existing infrastructure. If someone cares to write a SA plugin implementation of the same mechanism, I have no objections. More on that in 2.4.2 release notes: http://www.ijs.si/software/amavisd/release-notes.txt Mark
