On Fri, 15 Jun 2018 16:10:15 +0000, Mihai Costea <mcos...@live.com> wrote:

>Michael, the two sample accounts you sent privately had no safesenders at all. 

Correct.  When our team discovered extensive unsolicited modifications to the
safe and blocked lists, they cleared them out -- we really need accurate data
if we are to sell a product that we believe provides value to our customers.  

We dislike the thought of having to automate this process.  I also wonder
"What happens to a sender's reputation when a user deletes them from their
safe-sender list?"

I have screen shots taken of one of the accounts before the cleanout, of both
the safe- and banned-sender lists.  I will forward them to Michael on Monday. 
Meanwhile, you have access to the safe-sender list from my personal account to
look into.  Because I use that account to evaluate specific client sends, the
LAST thing I would want to do is introduce an arbitrary bias to the result.

>We have some tech that rescues junk senders that are frequently read, and 
>junks inboxed senders that get no reads etc.  this will make panel users 
>differ from the larger population if for example the panel automation is 
>reading all mails in junk or it deletes without opening all the inbox.  
>(I expect other “receivers” have similar user behavior systems or heuristics 
>so worth sharing this info on this mailing list. )

I cannot respond except to state that the collector robot simply collects.  If
retrieving a message (without visiting any of the links) will trigger some
modification to the local safe-sender list, I would consider this a serious
bug at the very least.  

Then we have the fact that something has triggered the unsolicited addition of
senders to the banned-sender list.  This is a much more serious issue in its
implications, given that Hotmail/msn/outlook open rates for a number of our
customers are often less than half those reported by gmail, aol/y! and other
monitored providers.  

And we are talking about senders with green/good GPT stats at Google and
demonstrably verified opt-in lists who either comply with
https:www.drh.net/AUP or die.  

And I'm part of the "die" option.


>Years ago we had some simplistic implicit safesender and blocksender lists, 
>but those are dynamic now part of the filter I described. 

SOMETHING is making unsolicited persistent modifications to user-local lists
that are (at least in theory) under the sole control of the user.  

I will state, under oath in a court of law, that I never have made an entry to
my own account's safe list, nor in fact taken any action that I could expect
to affect a sender's reputation.  The robot can speak for itself.

>I don’t exclude the possibility of a bug but please send some sample headers 
>to investigate.  

To Michael on Monday.

>Plus we’ve dumbed down in the area of headers and we’re now showing all the 
>inner workings so you can check wl: and abwl: in message delivery if it hit 
>whitelist or address book. 

Can you point me to documentation on this?  I would love to develop a "WTF,O"
app for us and our customers to use in diagnosing oddities.

>On the other suggestion of skipping filtering for blocked sender mail.  That 
>makes sense for ancient rule sets, but modern systems use filtering metadata 
>to feed machine learning systems. It is wise to evaluate all mail to not 
>introduce bias in the training data.

In the end, if any rules of any era are applied, then for items sent to the
inbox ALL the rules must run, unless you short-circuit the process by,
perhaps, consulting some opinion source other than the rules.  If it is
possible to consult some BL facility before launching a rule scan, this too
provides savings in infrastructure.  

Having maintained the "ancient" rule sets with some minor participation in the
"modern" infrastructure before my departure from Microsoft, I am not entirely
unaware of the factors involved.

mdr
-- 
         "There are no laws here, only agreements."  
                -- Masahiko


_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Reply via email to