Re: per user post-data rejects, Processing after the end of DATA

+1.

I made this note to hopefully correlate the idea that AV vs AS can 
provide different level of overhead at the DATA level.  IMV, AV can 
serve as a system-wide rejection with less per-recipient concerns - no 
one gets the virus, don't leave this to the user to decide is probably 
a better policy. AS is more subjective on a per-recipient basis thus, 
IMV, harder to design for at the DATA level - unless you have a 
system-wide view of it.
All that does have a direct optimization correlation at DATA.

Thanks

--
Sincerely

Hector Santos
http://www.santronics.com



Carl S. Gutekunst wrote:
> [Is this too far off topic?]
>
> Hector Santos wrote:
> > We are at a point where an ISP or rather a MSP (Mail Service Provider) 
> > not having AV software installed could be considered as a liability. I 
> > recall reading (a BNA Legal and Business newsletters) about a proposed 
> > Canadian bill that would make it a requirement otherwise fines and 
> > shutdowns can be imposed in return ISP liabilities will be reduced. I 
> > have not followed up to tell you if it was passed or not.
> > I think there is a difference in the V and S in AVS.  AV is something 
> > that can system wide. AS is more subjective.
> Anti-virus has a considerable set of cost, intrusiveness, risk, and 
> privacy tradeoffs that motivate service providers to give customers some 
> choices. Customers who have a small budget and reasonably savvy users 
> might want just a single filter, perhaps ClamAV. Customers who are very 
> risk adverse would be more likely to pay for using multiple engines. 
> Customers who are extremely risk adverse and less sensitive about 
> privacy (or more trusting of the provider) might want heuristic filters 
> that aggressively flag "suspicious" mail that then requires sandboxing 
> or human inspection for a final verdict.
> And any time you give the users choices, you run the risk of a 
> disposition conflict. Per-recipient status after the dot would fix that.
> <csg>