On 3/21/2012 10:41 AM, Michael Scheidell wrote:
On 3/21/12 9:57 AM, Kevin A. McGrail wrote:
Very elegant IMO. I'd love to look at moving some of the framework
to support this into SA. Any objections? Won't be anything quick
but it's a really great idea.
We thought about this once.
add (ie: modify body of email) with 'report spam', 'blacklist sender'
links.
If the links are internal (private ip's), or internally resolvable
names, or names or ip's that resolve only locally or via vpn, then
that might be ok.
But, what do you do about an email that was forwarded to someone else?
And, that someone else has one of those silly anti-malware plugins
that surfs to every url in any inbound email?
(or some forwarder recipient decides to click on of the links)
From my perspective, the key point is solely the framework to store the
Bayesian tokens from the email before delivery of the email so later, a
"this is spam" "this is ham" mechanism can take advantage of that
information without having the entire email.
The issues you are pointing to have to deal more with the implementation
of the this is spam/this is ham mechanism.
Regards,
KAM
