I do agree with your thoughts. A good platform gives the users the control to do what they want with FBLs via automation (doesn’t force to unsub globally but yes some senders prefer do that).
I think the point though, is whether or not Validity having control over (or any single entity) is good for the recipient or not. And also, do inbox providers plan to make any changes in response. On Mon, Sep 11, 2023 at 3:54 PM Opti Pub <sysad...@optipub.com> wrote: > I should clarify I meant it’s irrelevant as far as the topic of the thread > is concerned (what peoples thoughts are on this new pay to play situation > with FBL). > > I’m curious what others thoughts are on that specific subject (the thread > topic). > > > On Mon, Sep 11, 2023 at 3:12 PM Scott Mutter via mailop <mailop@mailop.org> > wrote: > >> How an FBL is supposed to be used versus how an FBL is used is always a >> topic for discussion that can be applied to anything. >> >> How many of us expect email to be delivered instantly? But where is it >> defined that email has to be delivered the second the sender clicks that >> send button? But we all get up in arms when that email doesn't arrive in 2 >> minutes. >> >> My take on users abusing the "this is spam" button is, if they click the >> button then they don't want to receive mail from that sender ever again. >> If 10 years later they wonder why they're not receiving mail from that >> sender, then maybe they should have rethought clicking that "this is spam" >> button from that sender. >> >> If the recipient server wants to send messages from our server into their >> users spam folders and report those as spam via the FBL, then obviously >> that provider doesn't want to receive mail from our server. If the >> intended recipient of that message doesn't like it, then talk to the >> recipient server administrator that's sending the messages into your spam >> folder and sending it back along the FBL and ask them why they're doing >> that. Maybe it's time to consider a different provider? >> >> Is all of that the intended function of the FBL? Probably not. But >> there's got to be some end-user education. End users are going to have to >> realize that clicking the "this is spam" on a message from a recipient that >> you clearly at one time wanted to receive messages from, doing that is >> going to have consequences. >> >> On Mon, Sep 11, 2023 at 11:58 AM Support 3Hound via mailop < >> mailop@mailop.org> wrote: >> >>> I agree with you Neil, >>> let me specify it better even if it's a bit off topic. >>> The FBL SHOULD NOT be used like that but this is how users act based on >>> the feedback we collected from end users when we tried to understand why we >>> was receiving so much FBL on double-optin collected lists and transactional >>> e-mail. >>> There is also a worst case: users sometime select the whole list of >>> weekly e-mail received in years and click "junk" in order to achieve a >>> "delete all + unsubscribe", often they do it when their mailbox get full >>> it's a fast cleanup. >>> So, TRUE! It's not the way it should be used but it's what the end users >>> is experiencing and expecting. >>> >>> Coming back in topic: >>> Not paying to get ARF FBL (so not unsubscribing anymore FBL) will be >>> seen as a bad practice? >>> Maybe this is the final act for the FBL service that is just mis-used >>> and so no-more useful also for gathering reputation data... >>> >>> >>> >>> >>> >>> Il 11/09/2023 14:05, Neil Jenkins via mailop ha scritto: >>> >>> That's a … different perspective on this behaviour. Treating an FBL >>> report as "unsubscribe" (or rather *proscribe* at the ESP level) is >>> terrible for user experience and not at all what the feedback loop should >>> be used for IMO. Users click Report Spam by mistake one time (this happens >>> *a >>> lot)* and suddenly they don't get emails they want. Even worse, as the >>> proscription is often at the ESP-level, the original sender ban be unaware >>> of the block and thinks they are still sending correctly. These are a >>> nightmare for our customer support team to deal with — the sender's support >>> are saying they are sending the message, our support are telling the >>> customer there's no logs of it ever reaching our servers. The customer is >>> stuck in the middle >>> >>> >>> _______________________________________________ >>> mailop mailing list >>> mailop@mailop.org >>> https://list.mailop.org/listinfo/mailop >>> >> _______________________________________________ >> mailop mailing list >> mailop@mailop.org >> https://list.mailop.org/listinfo/mailop >> >
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
