On 18-06-08 09:14 AM, Stefano Bagnara wrote:
On Fri, 8 Jun 2018 at 17:53, Michael Peddemors <mich...@linuxmagic.com> wrote:
[...]
And while using that as feedback might seem the logical conclusion, in
the real world we still see more feedback reports from legitimate email
the customer should have wanted, vs emails tagged as spam that are spam.
Well, this is very surprising to me. Anyone else record similar scenario?
For the record, we are only collecting optics on Microsoft Feedbacks at
this time, so it might be other systems have less customers marking
messages that are not spam, but legitimate messages from friends..
confirmed double opt-in mailing lists etc..
I know much more users that use the "mark as spam" on their inboxes
than users that dig in their junk folder to mark something as "non
spam".
I'd love to get some stats about "mark as spam" vs "mark as non spam"
from Google or Microsoft, just to get some real data about this!
And I know a lot of systems where there's no spam folder in "inbound"
but there's a "mark as spam" so that you can only make reports for
spam but you can't really make reports for non spam.
In fact I still have to understand how spam reports and false positive
reports are collected in the whole plesk world (I guess you know what
I'm talking about): I've had multiple recipients using plesk that were
willing to report false positives for the MIPSPACE-POOR list (or other
lists used there by default) but I've not been able to explain them
how to report the false positive and had to explain them how to remove
the MIPSPACE-POOR lookup. I really tried hard to find a better way
than explaining them how to disable that list, but failed.
Well, like any system, I think that you are probably looking at this too
simply, it could be that the system administrator has chosen to reject
instead of flag.. It depends on the system implementation. This isn't
related to any specific RBL, but how it is used.
Some use it to 'block', some use it to tag, and it doesn't matter which
RBL it is, SpamHaus, SpamRats, UCE-Protect, Invalument, Barracuda.. (or
a subset of their offerings) or a more specific purpose list..
(eg, there are system admin's that simply block China IP space for
instance, or IP(s) from specific hosting providers)
It will always be up to the administrator, and in the cases of some more
robust platforms, the domain owner, or the end user to decide for
themselves which reputation systems or IP lists that they want to
'block' vs 'tag'.
It is hard to get optics into the individual's operational objects, eg
one email admin has more strict belief's than another, because it works
'best' for 'his' operation and/or customers.
Often, the operator may get fed up, and put a list into blocking mode,
because he gets nobody complaining. Or a person who has a reputation
list that generated only few false positives, they will let the sender
deal with the RBL operator, or if they get enough false positives, they
will move it to tagging only, so the end user can say 'This is not
Junk', and allow future email from that sender. And if they still get
too many, they may just use it as an indicator with other factors.
But it does depend on the technology being used by that operator. Some
will only be able to do it at one level or another, but it still creates
less problems than if they didn't have it in place.
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
