Re: [mailop] New Validity policy for paid FBL (ARF)

[Laura Atkins via mailop]

idea 
>>> of pushing the RFC, but if you're in the middle many of those MBPs will 
>>> likely defer to a new middle-man to handle the implementation, and we're 
>>> back at a single vendor.
>>> 
>>> Mike
>>> From: mailop mailto:mailop-boun...@mailop.org>> 
>>> on behalf of Steve Freegard via mailop >> <mailto:mailop@mailop.org>>
>>> Sent: Thursday, September 21, 2023 12:05 PM
>>> To: Support 3Hound mailto:supp...@3hound.com>>
>>> Cc: mailop@mailop.org <mailto:mailop@mailop.org> >> <mailto:mailop@mailop.org>>
>>> Subject: Re: [mailop] New Validity policy for paid FBL (ARF)
>>>  
>>> Just saw this thread; I published this earlier today and we're likely going 
>>> to discuss it at M3AAWG:  https://abusix.com/feedback-loops/
>>> 
>>> TLDR; Abusix is willing to take this on and provide it as a free service 
>>> from any mailbox provider that wishes to participate, but we'll do it based 
>>> on the Independent RFC Draft using CFBL-Address, so we don't just end up 
>>> swapping out Validity for us, we help adopt a standard that any mailbox 
>>> provider can use going forward if they wish.
>>> Putting us in the middle just means that we take on the burden of 
>>> processing, wrapping and delivering the reports and approving the 
>>> CFBL-Addresses that can receive them and producing some high-level 
>>> statistics that might be interesting at the same time.
>>> 
>>> Kind regards,
>>> Steve.
>>> 
>>> 
>>> On Mon, 11 Sept 2023 at 12:29, Support 3Hound via mailop >> <mailto:mailop@mailop.org>> wrote:
>>> Dear list,
>>> I would like to understand what the community think about the new Validity 
>>> universal feedback loop service that is switching to a paid service 
>>> starting 21 September 2023.
>>> 
>>> As Validity worked in the the last years to achieve the management of the 
>>> FBL service from all the "main" country-level and international mailbox 
>>> providers (as the "universal" word suggest), I think that this new policy 
>>> is unfair and a very bad news for the mail operators community.
>>> 
>>> During years the FBL became a kind of "safe feature" for users that prefer 
>>> to click "junk" or "spam" and be sure they will not receive anymore.
>>> 
>>> The "one click unsubscribe/ List-unsubscribe header" should be the right 
>>> way to do that... true! But this is not the focus, everyone know that FBL 
>>> are -de facto- used like that from users and that they are honored from 
>>> correct sender. 
>>> 
>>> FBL generates also a good data flow for the mailbox provider that may 
>>> filter the "next e-mail" from a sender that don't honor the FBL (or can't 
>>> act realtime the unsubcribe) generating a better service for the end user 
>>> and a way to identify good player and bad ones.
>>> 
>>> Switching to a paid service bring these metrics to fails; rich spammer may 
>>> easily honor them getting a better reputation than a little correct player.
>>> 
>>> It also means that it's needed to buy a paid service from a private company 
>>> to follows best practices, something that seems to be unfair.
>>> 
>>> But... as any collaborating service it's based on other peers/nodes/players 
>>> so my question is: how mail players will act in this scenario?
>>> 
>>> For example, if every mailbox is going to reactivate his own service to get 
>>> back the control of their FBL, it will not have just a short term impact...
>>> 
>>> ___
>>> mailop mailing list
>>> mailop@mailop.org <mailto:mailop@mailop.org>
>>> https://list.mailop.org/listinfo/mailop
>>> 
>>> 
>>> -- 
>>> Steve Freegard
>>> |
>>> Senior Product Owner
>>> T.
>>>  
>>> +44 7740 364348
>>> abusix.com 
>>> <https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDzZTf64_AIC7pyl-xmo2L5eYJtYu1PnTYrDUUBmQW-VxiqyfDuPS_3WZnIEFz1xocGdBhnxAEyhHhg3_G29KPX5gu0-0JxXoL3Lw4zV1rZI4zA5EgDWnGc90iUX1HRTDIs=>
>>>  
>>> Book a meeting 
>>> <https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDv

Re: [mailop] New Validity policy for paid FBL (ARF)

[Maarten Oelering via mailop]

I would like to believe that the solution offered by Abusix is a drop-in 
replacement. Adding the CFBL-Address header is not too difficult for most 
senders. 
But most sender systems rely on ARF reports, with the rfc822 attachment. Not 
XARF, with the json attachment. So there’s two standards to push.

Maarten

> On 22 Sep 2023, at 00:01, Steve Freegard via mailop  wrote:
> 
> Hi Mike,
> 
> Aside from stating categorically that we're not interested in monetizing the 
> reports like Validity are doing, the only other thing I can suggest is that 
> you look at the history of what we've done in the past.   We've provided the 
> Abuse ContactDB as a free service for well over 10 years (used by many places 
> including Fail2Ban etc.), we've contributed XARF to the community and are 
> providing Global Reporting, which is a free Abuse Reporting Service (of which 
> we'll be using 99% of the code already written to implement this Feedback 
> Loop functionality).
> 
> The whole point about backing the Draft RFC is also to open it up as much as 
> possible.   The current state means that you either pay Validity or you don't 
> get anything, period.  They have the current monopoly and zero competition 
> which is why they can do this in the first place.   
> 
> I'd also like to point out that there is absolutely no guarantee that any 
> mailbox providers will come across to us either; that will take persuasion 
> from the industry, but we make it as easy as possible with this service, 
> they're effectively swapping one email address with another.  Why would a 
> mailbox provider, right now, bother to put the development time into 
> implementing a draft RFC that (at the time of writing) only two entities are 
> using? (CleverReach and Onmivary with ActiveCampaign to follow soon), they 
> would also have the on-going management and approval of new CFBL-Addresses to 
> deal with as well.
> 
> The point is; we can implement this pretty quickly with a few code changes on 
> our end to something we've already been working on for months and provide an 
> alternative to Validity and help get the draft RFC more widely implemented - 
> at which point with much wider adoption, it makes it far more easy (and 
> therefore likely) for mailbox providers to implement this themselves if they 
> wish to, or for other entities to offer a similar service should they choose.
> 
> That's surely better than the current status quo and sitting back and doing 
> nothing, right?
> 
> Kind regards,
> Steve.
> 
> 
> On Thu, 21 Sept 2023 at 20:43, Mike Hillyer  <mailto:m...@mikehillyer.com>> wrote:
>> I think the first question anyone will ask is "How do we know that Abusix 
>> won't eventually become Validity 2: the Abusix Remix"? I do like the idea of 
>> pushing the RFC, but if you're in the middle many of those MBPs will likely 
>> defer to a new middle-man to handle the implementation, and we're back at a 
>> single vendor.
>> 
>> Mike
>> From: mailop mailto:mailop-boun...@mailop.org>> 
>> on behalf of Steve Freegard via mailop > <mailto:mailop@mailop.org>>
>> Sent: Thursday, September 21, 2023 12:05 PM
>> To: Support 3Hound mailto:supp...@3hound.com>>
>> Cc: mailop@mailop.org <mailto:mailop@mailop.org> > <mailto:mailop@mailop.org>>
>> Subject: Re: [mailop] New Validity policy for paid FBL (ARF)
>>  
>> Just saw this thread; I published this earlier today and we're likely going 
>> to discuss it at M3AAWG:  https://abusix.com/feedback-loops/
>> 
>> TLDR; Abusix is willing to take this on and provide it as a free service 
>> from any mailbox provider that wishes to participate, but we'll do it based 
>> on the Independent RFC Draft using CFBL-Address, so we don't just end up 
>> swapping out Validity for us, we help adopt a standard that any mailbox 
>> provider can use going forward if they wish.
>> Putting us in the middle just means that we take on the burden of 
>> processing, wrapping and delivering the reports and approving the 
>> CFBL-Addresses that can receive them and producing some high-level 
>> statistics that might be interesting at the same time.
>> 
>> Kind regards,
>> Steve.
>> 
>> 
>> On Mon, 11 Sept 2023 at 12:29, Support 3Hound via mailop > <mailto:mailop@mailop.org>> wrote:
>> Dear list,
>> I would like to understand what the community think about the new Validity 
>> universal feedback loop service that is switching to a paid service starting 
>> 21 September 2023.
>> 
>> As Validity worked in the the last years to achieve the management of the 
>> FBL service from all the "

Re: [mailop] New Validity policy for paid FBL (ARF)

[Steve Freegard via mailop]

Hi Mike,

Aside from stating categorically that we're not interested in monetizing
the reports like Validity are doing, the only other thing I can suggest is
that you look at the history of what we've done in the past.   We've
provided the Abuse ContactDB as a free service for well over 10 years (used
by many places including Fail2Ban etc.), we've contributed XARF to the
community and are providing Global Reporting, which is a free Abuse
Reporting Service (of which we'll be using 99% of the code already written
to implement this Feedback Loop functionality).

The whole point about backing the Draft RFC is also to open it up as much
as possible.   The current state means that you either pay Validity or you
don't get anything, period.  They have the current monopoly and zero
competition which is why they can do this in the first place.

I'd also like to point out that there is absolutely no guarantee that any
mailbox providers will come across to us either; that will take persuasion
from the industry, but we make it as easy as possible with this
service, they're effectively swapping one email address with another.  Why
would a mailbox provider, right now, bother to put the development time
into implementing a draft RFC that (at the time of writing) only two
entities are using? (CleverReach and Onmivary with ActiveCampaign to follow
soon), they would also have the on-going management and approval of new
CFBL-Addresses to deal with as well.

The point is; we can implement this pretty quickly with a few code changes
on our end to something we've already been working on for months and
provide an alternative to Validity and help get the draft RFC more widely
implemented - at which point with much wider adoption, it makes it far more
easy (and therefore likely) for mailbox providers to implement this
themselves if they wish to, or for other entities to offer a similar
service should they choose.

That's surely better than the current status quo and sitting back and doing
nothing, right?

Kind regards,
Steve.


On Thu, 21 Sept 2023 at 20:43, Mike Hillyer  wrote:

> I think the first question anyone will ask is "How do we know that Abusix
> won't eventually become Validity 2: the Abusix Remix"? I do like the idea
> of pushing the RFC, but if you're in the middle many of those MBPs will
> likely defer to a new middle-man to handle the implementation, and we're
> back at a single vendor.
>
> Mike
> --
> *From:* mailop  on behalf of Steve Freegard
> via mailop 
> *Sent:* Thursday, September 21, 2023 12:05 PM
> *To:* Support 3Hound 
> *Cc:* mailop@mailop.org 
> *Subject:* Re: [mailop] New Validity policy for paid FBL (ARF)
>
> Just saw this thread; I published this earlier today and we're likely
> going to discuss it at M3AAWG:  https://abusix.com/feedback-loops/
>
> TLDR; Abusix is willing to take this on and provide it as a free service
> from any mailbox provider that wishes to participate, but we'll do it based
> on the Independent RFC Draft using CFBL-Address, so we don't just end up
> swapping out Validity for us, we help adopt a standard that any mailbox
> provider can use going forward if they wish.
> Putting us in the middle just means that we take on the burden of
> processing, wrapping and delivering the reports and approving the
> CFBL-Addresses that can receive them and producing some high-level
> statistics that might be interesting at the same time.
>
> Kind regards,
> Steve.
>
>
> On Mon, 11 Sept 2023 at 12:29, Support 3Hound via mailop <
> mailop@mailop.org> wrote:
>
> Dear list,
> I would like to understand what the community think about the new Validity
> universal feedback loop service that is switching to a paid service
> starting 21 September 2023.
>
> As Validity worked in the the last years to achieve the management of the
> FBL service from all the "main" country-level and international mailbox
> providers (as the "universal" word suggest), I think that this new policy
> is unfair and a very bad news for the mail operators community.
>
> During years the FBL became a kind of "safe feature" for users that prefer
> to click "junk" or "spam" and be sure they will not receive anymore.
>
> The "one click unsubscribe/ List-unsubscribe header" should be the right
> way to do that... true! But this is not the focus, everyone know that FBL
> are -de facto- used like that from users and that they are honored from
> correct sender.
>
> FBL generates also a good data flow for the mailbox provider that may
> filter the "next e-mail" from a sender that don't honor the FBL (or can't
> act realtime the unsubcribe) generating a better service for the end user
> and a way to identify good player and bad ones.
>
> Switchin

Re: [mailop] New Validity policy for paid FBL (ARF)

[Mike Hillyer via mailop]

I think the first question anyone will ask is "How do we know that Abusix won't 
eventually become Validity 2: the Abusix Remix"? I do like the idea of pushing 
the RFC, but if you're in the middle many of those MBPs will likely defer to a 
new middle-man to handle the implementation, and we're back at a single vendor.

Mike

From: mailop  on behalf of Steve Freegard via mailop 

Sent: Thursday, September 21, 2023 12:05 PM
To: Support 3Hound 
Cc: mailop@mailop.org 
Subject: Re: [mailop] New Validity policy for paid FBL (ARF)

Just saw this thread; I published this earlier today and we're likely going to 
discuss it at M3AAWG:  https://abusix.com/feedback-loops/

TLDR; Abusix is willing to take this on and provide it as a free service from 
any mailbox provider that wishes to participate, but we'll do it based on the 
Independent RFC Draft using CFBL-Address, so we don't just end up swapping out 
Validity for us, we help adopt a standard that any mailbox provider can use 
going forward if they wish.
Putting us in the middle just means that we take on the burden of processing, 
wrapping and delivering the reports and approving the CFBL-Addresses that can 
receive them and producing some high-level statistics that might be interesting 
at the same time.

Kind regards,
Steve.


On Mon, 11 Sept 2023 at 12:29, Support 3Hound via mailop 
mailto:mailop@mailop.org>> wrote:
Dear list,
I would like to understand what the community think about the new Validity 
universal feedback loop service that is switching to a paid service starting 21 
September 2023.

As Validity worked in the the last years to achieve the management of the FBL 
service from all the "main" country-level and international mailbox providers 
(as the "universal" word suggest), I think that this new policy is unfair and a 
very bad news for the mail operators community.

During years the FBL became a kind of "safe feature" for users that prefer to 
click "junk" or "spam" and be sure they will not receive anymore.

The "one click unsubscribe/ List-unsubscribe header" should be the right way to 
do that... true! But this is not the focus, everyone know that FBL are -de 
facto- used like that from users and that they are honored from correct sender.

FBL generates also a good data flow for the mailbox provider that may filter 
the "next e-mail" from a sender that don't honor the FBL (or can't act realtime 
the unsubcribe) generating a better service for the end user and a way to 
identify good player and bad ones.

Switching to a paid service bring these metrics to fails; rich spammer may 
easily honor them getting a better reputation than a little correct player.

It also means that it's needed to buy a paid service from a private company to 
follows best practices, something that seems to be unfair.

But... as any collaborating service it's based on other peers/nodes/players so 
my question is: how mail players will act in this scenario?

For example, if every mailbox is going to reactivate his own service to get 
back the control of their FBL, it will not have just a short term impact...

___
mailop mailing list
mailop@mailop.org<mailto:mailop@mailop.org>
https://list.mailop.org/listinfo/mailop


--

Steve Freegard

|

Senior Product Owner

T.



+44 7740 364348

abusix.com<https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDzZTf64_AIC7pyl-xmo2L5eYJtYu1PnTYrDUUBmQW-VxiqyfDuPS_3WZnIEFz1xocGdBhnxAEyhHhg3_G29KPX5gu0-0JxXoL3Lw4zV1rZI4zA5EgDWnGc90iUX1HRTDIs=>

Book a 
meeting<https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDzdypi6WPqhVkFKkuLiMX0pY_5fawxs7P25-lwfZUyr7w==>

[My Logo]



[https://storage.letsignit.com/icons/designer/socials/Facebook--circle--black.png]<https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDyIo6EwBskR6pg3M12nuwEx_9G03qmurLHy8H_IjsK3cg==>

[https://storage.letsignit.com/icons/designer/socials/Twitter--circle--black.png]<https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDweOZAf2SFcCyyLHlLyd4j2GB_p_YWWJ_3WJxEqTQND2A==>

[https://storage.letsignit.com/icons/designer/socials/Linkedin--circle--black.png]<https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDz5UNyOTEm_EvRFXdshn5-xBpkDGWEZYln2qrkxaFuQc-FVdHa5XQ8gkUA8UK9te-A=>

[https://storage.letsig

Re: [mailop] New Validity policy for paid FBL (ARF)

[Tracey Crawford via mailop]

Hi Steve,

That is awesome news!
Tracey Crawford

Message: 1
> Date: Thu, 21 Sep 2023 17:05:23 +0100
> From: Steve Freegard 
> To: Support 3Hound 
> Cc: mailop@mailop.org
> Subject: Re: [mailop] New Validity policy for paid FBL (ARF)
> Message-ID:
>  fperqryufwzrd7jdmz...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Just saw this thread; I published this earlier today and we're likely going
> to discuss it at M3AAWG:  https://abusix.com/feedback-loops/
>
> TLDR; Abusix is willing to take this on and provide it as a free service
> from any mailbox provider that wishes to participate, but we'll do it based
> on the Independent RFC Draft using CFBL-Address, so we don't just end up
> swapping out Validity for us, we help adopt a standard that any mailbox
> provider can use going forward if they wish.
> Putting us in the middle just means that we take on the burden of
> processing, wrapping and delivering the reports and approving the
> CFBL-Addresses that can receive them and producing some high-level
> statistics that might be interesting at the same time.
>
> Kind regards,
> Steve.
>
>
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

[Steve Freegard via mailop]

Just saw this thread; I published this earlier today and we're likely going
to discuss it at M3AAWG:  https://abusix.com/feedback-loops/

TLDR; Abusix is willing to take this on and provide it as a free service
from any mailbox provider that wishes to participate, but we'll do it based
on the Independent RFC Draft using CFBL-Address, so we don't just end up
swapping out Validity for us, we help adopt a standard that any mailbox
provider can use going forward if they wish.
Putting us in the middle just means that we take on the burden of
processing, wrapping and delivering the reports and approving the
CFBL-Addresses that can receive them and producing some high-level
statistics that might be interesting at the same time.

Kind regards,
Steve.


On Mon, 11 Sept 2023 at 12:29, Support 3Hound via mailop 
wrote:

> Dear list,
> I would like to understand what the community think about the new Validity
> universal feedback loop service that is switching to a paid service
> starting 21 September 2023.
>
> As Validity worked in the the last years to achieve the management of the
> FBL service from all the "main" country-level and international mailbox
> providers (as the "universal" word suggest), I think that this new policy
> is unfair and a very bad news for the mail operators community.
>
> During years the FBL became a kind of "safe feature" for users that prefer
> to click "junk" or "spam" and be sure they will not receive anymore.
>
> The "one click unsubscribe/ List-unsubscribe header" should be the right
> way to do that... true! But this is not the focus, everyone know that FBL
> are -de facto- used like that from users and that they are honored from
> correct sender.
>
> FBL generates also a good data flow for the mailbox provider that may
> filter the "next e-mail" from a sender that don't honor the FBL (or can't
> act realtime the unsubcribe) generating a better service for the end user
> and a way to identify good player and bad ones.
>
> Switching to a paid service bring these metrics to fails; rich spammer may
> easily honor them getting a better reputation than a little correct player.
>
> It also means that it's needed to buy a paid service from a private
> company to follows best practices, something that seems to be unfair.
>
> But... as any collaborating service it's based on other
> peers/nodes/players so my question is: how mail players will act in this
> scenario?
>
> For example, if every mailbox is going to reactivate his own service to
> get back the control of their FBL, it will not have just a short term
> impact...
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>


-- 

Steve Freegard

|

Senior Product Owner

T.



+44 7740 364348

abusix.com


Book a meeting


[image: My Logo]













CONFIDENTIALITY This email and any attachments are confidential and may
also be privileged or otherwise protected from disclosure. If you are not
the named recipient, please notify the sender immediately and do not
disclose the contents to another person, use it for any purpose, or store
or copy the information in any medium.



You’ll find further information about privacy here

.
___
mailop mailing list
mailop@mailop.org

Re: [mailop] New Validity policy for paid FBL (ARF)

[Scott Mutter via mailop]

Going from the list provided at:

https://www.isipp.com/blog/validity-fbl-charging-how-much-cost/

The only one that I really get any feedback from is Comcast, maybe
Synacor.  And those are few and far between.  What's going to be the
incentive to pay for these ARF reports?

Sure, other people may be in a different boat than I am, and they may get a
lot of reports from those various providers.  But you've got to think that
it's a very small subset of Validity users that get enough feedback
messages from those providers, enough to warrant spending money for the ARF
reports.

Perhaps Validity is just exhausting all methods of trying to make money
before folding up shop.  But I can't see this as being a major money maker
for them.

On Wed, Sep 13, 2023 at 11:40 AM Opti Pub via mailop 
wrote:

> I think that’s the point, mostly all of them used to allow direct setup
> but don’t anymore (when universal fbl became widespread). Seznam is one of
> 20+.
>
> Now that you have to pay for it maybe more vendors will start allowing
> direct setup again? That’s what I’m wondering about.
>
> I guess we will see.
>
> On Wed, Sep 13, 2023 at 11:18 AM Gellner, Oliver via mailop <
> mailop@mailop.org> wrote:
>
>> On 13.09.2023 at 16:06 Scott Mutter via mailop wrote:
>>
>> > I also think one thing that Validity may not be understanding with this
>> move, and may lead to shooting themselves in the foot, the list of email
>> service providers that Validity provides feedback for isn't exactly major
>> players.
>> > We get more feedback from Yahoo and Outlook's FBL system than we do
>> Validity and Validity covers what?  21 different providers?  There's no
>> incentive there for me to pay for access to Validity's ARF feeds.  When
>> Validity stops sending ARF reports, I will simply no longer receive
>> Validity ARF reports - it won't be a major loss.
>>
>> On top of that some of the providers like Seznam also offer feedback
>> loops directly, so you don't need Validity for forwarding the reports.
>>
>> --
>> BR Oliver
>> 
>>
>> dmTECH GmbH
>> Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
>> Telefon 0721 5592-2500 Telefax 0721 5592-2777
>> dmt...@dm.de * www.dmTECH.de
>> GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
>> Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
>> 
>> Datenschutzrechtliche Informationen
>> Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser
>> ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in
>> Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder
>> sich bei uns bewerben, verarbeiten wir personenbezogene Daten.
>> Informationen unter anderem zu den konkreten Datenverarbeitungen,
>> Löschfristen, Ihren Rechten sowie die Kontaktdaten unserer
>> Datenschutzbeauftragten finden Sie hier<
>> https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832
>> >.
>> ___
>> 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

Re: [mailop] New Validity policy for paid FBL (ARF)

[Opti Pub via mailop]

I think that’s the point, mostly all of them used to allow direct setup but
don’t anymore (when universal fbl became widespread). Seznam is one of 20+.

Now that you have to pay for it maybe more vendors will start allowing
direct setup again? That’s what I’m wondering about.

I guess we will see.

On Wed, Sep 13, 2023 at 11:18 AM Gellner, Oliver via mailop <
mailop@mailop.org> wrote:

> On 13.09.2023 at 16:06 Scott Mutter via mailop wrote:
>
> > I also think one thing that Validity may not be understanding with this
> move, and may lead to shooting themselves in the foot, the list of email
> service providers that Validity provides feedback for isn't exactly major
> players.
> > We get more feedback from Yahoo and Outlook's FBL system than we do
> Validity and Validity covers what?  21 different providers?  There's no
> incentive there for me to pay for access to Validity's ARF feeds.  When
> Validity stops sending ARF reports, I will simply no longer receive
> Validity ARF reports - it won't be a major loss.
>
> On top of that some of the providers like Seznam also offer feedback loops
> directly, so you don't need Validity for forwarding the reports.
>
> --
> BR Oliver
> 
>
> dmTECH GmbH
> Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
> Telefon 0721 5592-2500 Telefax 0721 5592-2777
> dmt...@dm.de * www.dmTECH.de
> GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
> Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
> 
> Datenschutzrechtliche Informationen
> Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser
> ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in
> Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder
> sich bei uns bewerben, verarbeiten wir personenbezogene Daten.
> Informationen unter anderem zu den konkreten Datenverarbeitungen,
> Löschfristen, Ihren Rechten sowie die Kontaktdaten unserer
> Datenschutzbeauftragten finden Sie hier<
> https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832
> >.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

[Gellner, Oliver via mailop]

On 13.09.2023 at 16:06 Scott Mutter via mailop wrote:

> I also think one thing that Validity may not be understanding with this move, 
> and may lead to shooting themselves in the foot, the list of email service 
> providers that Validity provides feedback for isn't exactly major players.
> We get more feedback from Yahoo and Outlook's FBL system than we do Validity 
> and Validity covers what?  21 different providers?  There's no incentive 
> there for me to pay for access to Validity's ARF feeds.  When Validity stops 
> sending ARF reports, I will simply no longer receive Validity ARF reports - 
> it won't be a major loss.

On top of that some of the providers like Seznam also offer feedback loops 
directly, so you don't need Validity for forwarding the reports.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

[Scott Mutter via mailop]

I also think one thing that Validity may not be understanding with this
move, and may lead to shooting themselves in the foot, the list of email
service providers that Validity provides feedback for isn't exactly major
players.

We get more feedback from Yahoo and Outlook's FBL system than we do
Validity and Validity covers what?  21 different providers?  There's no
incentive there for me to pay for access to Validity's ARF feeds.  When
Validity stops sending ARF reports, I will simply no longer receive
Validity ARF reports - it won't be a major loss.

On Mon, Sep 11, 2023 at 6:24 AM Support 3Hound via mailop 
wrote:

> Dear list,
> I would like to understand what the community think about the new Validity
> universal feedback loop service that is switching to a paid service
> starting 21 September 2023.
>
> As Validity worked in the the last years to achieve the management of the
> FBL service from all the "main" country-level and international mailbox
> providers (as the "universal" word suggest), I think that this new policy
> is unfair and a very bad news for the mail operators community.
>
> During years the FBL became a kind of "safe feature" for users that prefer
> to click "junk" or "spam" and be sure they will not receive anymore.
>
> The "one click unsubscribe/ List-unsubscribe header" should be the right
> way to do that... true! But this is not the focus, everyone know that FBL
> are -de facto- used like that from users and that they are honored from
> correct sender.
>
> FBL generates also a good data flow for the mailbox provider that may
> filter the "next e-mail" from a sender that don't honor the FBL (or can't
> act realtime the unsubcribe) generating a better service for the end user
> and a way to identify good player and bad ones.
>
> Switching to a paid service bring these metrics to fails; rich spammer may
> easily honor them getting a better reputation than a little correct player.
>
> It also means that it's needed to buy a paid service from a private
> company to follows best practices, something that seems to be unfair.
>
> But... as any collaborating service it's based on other
> peers/nodes/players so my question is: how mail players will act in this
> scenario?
>
> For example, if every mailbox is going to reactivate his own service to
> get back the control of their FBL, it will not have just a short term
> impact...
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

[Jaroslaw Rafa via mailop]

Dnia 13.09.2023 o godz. 12:35:15 Gellner, Oliver via mailop pisze:
> Other than that, I'm with you and Bill Cole: If your infrastructure is not
> being used to send spam, newsletters or other marketing messages, feedback
> loops provide no benefit. 100% of all reports are going to be false
> positives of people who either accidentally hit the wrong button or are
> generally confused about the difference between the report spam button and
> the delete button. But this doesn't matter, email providers know this as
> well and if one out of thousands of emails is accidentally reported as
> spam it doesn't change anyones reputation.

Asking out of curiosity: what happens in case of small senders? If one of
not thousands, but - say - five emails sent in total is mistakenly reported
as spam?
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

[Gellner, Oliver via mailop]

On 12.09.2023 at 22:30 Mark Fletcher via mailop wrote:

> Thank you for writing this up, it's been confusing. We only receive 
> individual reports and not the aggregated data (or if we do it's not sent to 
> us). We received a slightly different email from Validity. It includes the 
> 'login method update' but it makes no mention of upgrading our account; 
> instead this was included:

>> Product Enhancement: You will now have access to aggregated data insights 
>> within the application, enabling you to gain a broader understanding of 
>> overall trends, patterns, and customer sentiments.
>> You will receive an additional reminder one week before the launch with 
>> additional information to ensure that you are well-prepared for the 
>> transition and have all the information you need to securely log in to your 
>> account.

> So maybe we won't be subject to the new fees? Like I said, it's been 
> confusing.

The mentioned aggregated data insights are part of the free service and 
accessible through Validitys website. If you want to continue to receive 
individual ARF reports by email, you will have to become a paying customer one 
way or the other. The email is just confusing as the change from a free to a 
paid service is described as an enhancement, but this is just marketing lingo.

Other than that, I'm with you and Bill Cole: If your infrastructure is not 
being used to send spam, newsletters or other marketing messages, feedback 
loops provide no benefit. 100% of all reports are going to be false positives 
of people who either accidentally hit the wrong button or are generally 
confused about the difference between the report spam button and the delete 
button. But this doesn't matter, email providers know this as well and if one 
out of thousands of emails is accidentally reported as spam it doesn't change 
anyones reputation.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

[Neil Jenkins via mailop]

On Tue, 12 Sep 2023, at 00:43, Jarland Donnell via mailop wrote:
> Fastmail was the only one on the feedback loop who reported every single 
> email to the feedback loop that they themselves filtered to user's spam 
> folders, and this feature was on by default.

Fastmail has never done this. The delivery pipeline that decides whether mail 
goes to the Spam folder is not even hooked up to the system that sends FBL 
reports. We did used to send a report whenever the user hit *Report spam*, or 
when they manually confirmed a message had been filtered correctly by 
permanently deleting it from the Spam folder (rather than clicking *Not spam*, 
or moving it to another folder, or even just leaving it to be auto-deleted; and 
I think we also only sent the report if they didn't have more than 10 selected, 
so it wouldn't apply if they were doing a big bulk delete). We now only send it 
when the user hits *Report spam* *and* the user's local reputation for that 
sender is sufficiently low (which basically means the user has reported them as 
spam before and *not* done something recently to indicate they want the mail 
like archive or reply to it).

> This then forced your users to then reach out to the end customers of the 
> transactional provider and beg them to find someone at their company who knew 
> how to remove them from the suppression list, which frankly tends to be very 
> few people at those companies (regardless of their size).

Exactly, this is the very problem I am describing.

On Tue, 12 Sep 2023, at 03:54, Scott Mutter via mailop wrote:
> 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. […] 
> 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.

Your server, your rules of course, but we've generally found it's better to 
adapt to our users’ actual behaviour rather than attempt to educate all of 
them. And of course even if we did manage to educate everyone, you're presuming 
no one ever clicks it by mistake. If you want to make a great user experience, 
you need to make it easy to undo changes and recover from mistakes 
. If a user clicks 
*Report spam* by mistake then *Undo*, we can revert the change to their local 
reputation scores. But if it triggers a block at a 3rd party we can't undo 
that, or even see that it exists to tell the user. That's a terrible experience.

Neil.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

[Bill Cole via mailop]

On 2023-09-11 at 07:24:55 UTC-0400 (Mon, 11 Sep 2023 13:24:55 +0200)
Support 3Hound via mailop 
is rumored to have said:


Dear list,
I would like to understand what the community think about the new 
Validity universal feedback loop service that is switching to a paid 
service starting 21 September 2023.


We (SMB mailbox outsourcer/MSP/bespoke hoster) Are only subscribed to 
FBLs because we need to know if spam starts coming from our network. As 
we are not in the business of helping anyone send spam, ever, of any 
sort, we have never received anything useful from any FBL. The events 
where our clients have tried to send spam ignorantly or have had 
machines compromised to send spam have not managed to generate any FBL 
reports.


So, no, there's not even the slightest chance that my primary employer 
will pay Validity for anything. They've never been valuable for us 
before, why expect them to start now?


As Validity worked in the the last years to achieve the management of 
the FBL service from all the "main" country-level and international 
mailbox providers (as the "universal" word suggest), I think that this 
new policy is unfair and a very bad news for the mail operators 
community.


It must suck for ESPs, especially ones with shoddy list hygiene. It 
would certainly hurt to have to pay for the privilege of shrinking 
lists.


During years the FBL became a kind of "safe feature" for users that 
prefer to click "junk" or "spam" and be sure they will not receive 
anymore.


As if that ever worked, from the recipient's POV.

As I understand it, Validity is a for-profit corporation whose purpose 
is to return value to its investors commensurate with  their invested 
capital. They don't owe anyone any FBL. If you want their service, they 
will extract value from you one way or another to get it.


I should probably add that I would be entirely willing to experience an 
Internet without B2C ESPs. It's nothing personal, it's just that I've 
never been convinced that their existence isn't an attractive nuisance.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

[Scott Mutter via mailop]

I thought Validity was making the free FBL more like Google's Postmaster
Tools FBL.  Which, I've never gotten one iota of anything relevant in
Google's FBL system.

If I had to venture a guess, I'd say that this is going to be the future of
FBLs.  I think providers want to be able to block certain mail servers
without having to show evidence of abuse and having an FBL system doesn't
really lend themselves to this.  This mailing list itself is flooded with
requests of "Anybody from XXX able to tell me why IP is blocked?" that is
basically a tell-tale sign that the provider is either blocking the mail
server because they want to or not providing enough tools for the sending
operator to investigate the issue on their own.

The idea of FBL is great.  The application of FBL is well below ideal.

If end-users would utilize FBLs as the intended function, to identify spam
- not just mailing list you no longer want to receive.  And if FBL
operators would send all of these complaints back to the sending server
administrator.  And if the sending server administrator would act upon them
properly, then FBLs are a great tool.

But too often we're seeing end users abuse the functionality of reporting
spam.  FBL operators aren't sending every complaint and instead are
requiring a certain threshold to be met and blocking the mail server before
reaching this threshold.  And server administrators are either ignoring the
complaints sent back to them, not signing up for them in the first place,
or are spammers themselves utilizing the reports with bad intentions.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

[Opti Pub via mailop]

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  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 
> 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

Re: [mailop] New Validity policy for paid FBL (ARF)

[Opti Pub via mailop]

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 
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

Re: [mailop] New Validity policy for paid FBL (ARF)

[Scott Mutter via mailop]

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

Re: [mailop] New Validity policy for paid FBL (ARF)

[Opti Pub via mailop]

I'll chime in.

For me the thing that doesn't sit well for me is that the inbox
providers have adopted the universal fbl and force you to use that (at
least from the available info on their postmaster sites) rather than
being able to set up directly with them like you used to be able to.

Whether FBLs are being used as originally intended or not is probably
irrelevant.

I can't tell that to my customers who want to see the FBL data (and
act on it however they want).

To be fair the inbox providers all adopted the universal fbl knowing
it was free and available to everybody at the time... So I guess the
question I have is, do inbox providers (ex Comcast) plan to update
their FBL/postmaster sites allowing direct FBL set-up again now that
the universal fbl is a paid service?

I think it's a fair statement that the responsibility of ensuring
senders have open-access to ARF reports should fall on the inbox
providers.

Or will a lack of action from inbox providers signal that FBLs are a
dying breed?

Obviously we'll be paying up -- but I do agree it doesn't feel right
only having one option!

I'm also curious what others think.







On Mon, Sep 11, 2023 at 1:01 PM Support 3Hound via mailop
 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

Re: [mailop] New Validity policy for paid FBL (ARF)

[Support 3Hound via mailop]

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

Re: [mailop] New Validity policy for paid FBL (ARF)

[Jarland Donnell via mailop]

It's not at all unusual for FBL to be used to block recipients. 
Transactional email providers quite often use feedback loop reports to 
add recipients to their customer's suppression list. The reason you 
specifically find it frustrating is because of this:


Most of the providers on the feedback loops report an email back to the 
feedback loop when the user clicks "Report spam" or something similar. 
While I'm not sure if/when you stopped, for the longest time Fastmail 
was the only one on the feedback loop who reported every single email to 
the feedback loop that they themselves filtered to user's spam folders, 
and this feature was on by default. So if your spam filter moved a 
transactional email into a user's spam folder without them having 
specifically configured or clicked anything, your user was then added to 
a suppression list at the transactional email provider, likely prompting 
an excess of support tickets on your end. This then forced your users to 
then reach out to the end customers of the transactional provider and 
beg them to find someone at their company who knew how to remove them 
from the suppression list, which frankly tends to be very few people at 
those companies (regardless of their size).


The reason I know this is because I worked for a hosting company that 
would frequently stop receiving abuse complaints from Cloudflare because 
their abuse complaints got filtered into the spam folder at Fastmail, 
which instantly set off a FBL complaint, and caused us to land on the 
suppression list at the transactional email provider that Cloudflare 
used for their abuse department at the time.


I've been ignoring feedback loop complaints from Fastmail for a long 
time because of this. Should I take this as word that I can finally stop 
doing that?


On 2023-09-11 07:05, Neil Jenkins via mailop wrote:


On Mon, 11 Sep 2023, at 21:24, Support 3Hound via mailop wrote:

During years the FBL became a kind of "safe feature" for users that 
prefer to click "junk" or "spam" and be sure they will not receive 
anymore.

[...]
FBL generates also a good data flow for the mailbox provider that may 
filter the "next e-mail" from a sender that don't honor the FBL (or 
can't act realtime the unsubcribe) generating a better service for the 
end user and a way to identify good player and bad ones.


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


This has already caused us to drastically reduce the times we send FBL 
reports at Fastmail -- not every Report Spam will do so, only if the 
user repeatedly does so for a specific sender -- and I am still 羅 this 
close to stopping sending anything.


Feedback loops should be used by ESPs to identify bad _senders_, by 
looking at aggregate reports. Never for unsubscribing specific 
recipients.


Neil.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

[Neil Jenkins via mailop]

On Mon, 11 Sep 2023, at 21:24, Support 3Hound via mailop wrote:
> During years the FBL became a kind of "safe feature" for users that prefer to 
> click "junk" or "spam" and be sure they will not receive anymore.
> […]
> FBL generates also a good data flow for the mailbox provider that may filter 
> the "next e-mail" from a sender that don't honor the FBL (or can't act 
> realtime the unsubcribe) generating a better service for the end user and a 
> way to identify good player and bad ones.

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

This has already caused us to drastically reduce the times we send FBL reports 
at Fastmail — not every Report Spam will do so, only if the user repeatedly 
does so for a specific sender — and I am still 羅 this close to stopping sending 
anything.

Feedback loops should be used by ESPs to identify bad *senders*, by looking at 
aggregate reports. Never for unsubscribing specific recipients.

Neil.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] New Validity policy for paid FBL (ARF)

[Support 3Hound via mailop]

Dear list,
I would like to understand what the community think about the new 
Validity universal feedback loop service that is switching to a paid 
service starting 21 September 2023.


As Validity worked in the the last years to achieve the management of 
the FBL service from all the "main" country-level and international 
mailbox providers (as the "universal" word suggest), I think that this 
new policy is unfair and a very bad news for the mail operators community.


During years the FBL became a kind of "safe feature" for users that 
prefer to click "junk" or "spam" and be sure they will not receive anymore.


The "one click unsubscribe/ List-unsubscribe header" should be the right 
way to do that... true! But this is not the focus, everyone know that 
FBL are -de facto- used like that from users and that they are honored 
from correct sender.


FBL generates also a good data flow for the mailbox provider that may 
filter the "next e-mail" from a sender that don't honor the FBL (or 
can't act realtime the unsubcribe) generating a better service for the 
end user and a way to identify good player and bad ones.


Switching to a paid service bring these metrics to fails; rich spammer 
may easily honor them getting a better reputation than a little correct 
player.


It also means that it's needed to buy a paid service from a private 
company to follows best practices, something that seems to be unfair.


But... as any collaborating service it's based on other 
peers/nodes/players so my question is: how mail players will act in this 
scenario?


For example, if every mailbox is going to reactivate his own service to 
get back the control of their FBL, it will not have just a short term 
impact...
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop