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
[email protected]
https://list.mailop.org/listinfo/mailop
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
