We have, and also sometimes click on “unsubscribe” on emails people mark as spam that get forwarded to us. This being said, maybe we missed a feedback loop? I have just checked and found [1]; we'll subscribe to the ones we missed that are listed there.
[1] https://help.returnpath.com/hc/en-us/articles/220221448-List-of-all-available-complaint-feedback-loops-FBLs- Maybe one thing we should do, would be to automatically send an email to people who click the spam button (as defined by reception on abuse@) to tell them to instead forward the mail to spam@? but then it would come at the risk of actually generating emails that people would see as spam, so it doesn't sound that great… Russell Clemings via mailop <mailop@mailop.org> writes: > Have you at least signed up for all the feedback loops you can find? That > seems to help with reputation and it also helps you track down and counsel > users who think the spam button is the same thing as the delete button. > > > > On Fri, Jun 19, 2020 at 9:16 AM Leo Gaspard via mailop <mailop@mailop.org> > wrote: > >> Michael Peddemors via mailop <mailop@mailop.org> writes: >> > Since every email client in the world can check multiple mailboxes, ISPs >> > and Telco's are starting to simply turn off 'remote forwarding', it is >> > an option for you of course. >> >> Unfortunately, this is not really a reasonable course of action for us: >> most people still just use their ISP's webmail, which rarely supports >> checking multiple mailboxes and even if it did would require a >> significant amount of configuration by the end-user… we already have >> issues keeping up-to-date email addresses for all the users, as they >> often forget to notify us changes, so getting them all to regularly >> fetch emails from IMAP servers we'd setup sounds pretty much impossible. >> >> > Which is why you should consider the spam protection as an integral part >> > of the email service, and not simply a 'pre-filtering' system, as this >> > way cases of "one man's spam is another man's reading material".. >> > >> > Let the customer make the final choice.. eg 'Click Allow/Block Sender'. >> >> This sounds like a neat idea! however, there is an issue with it: adding >> these links would break DKIM, and so we would have to rewrite the From >> header for all emails… which sounds like a pretty bad UX downside. If >> only there were a way to add a DKIM-unsigned mime block to the email, >> that the UI would display as being obviously not-from-the-sender… it >> could solve this issue maybe. >> >> >> Do you know of additional best practices we could do, to better help >> >> training our antispam as well as hopefully redirect at least some of the >> >> reputation loss to the actual sender of the email? >> > >> > Never forward known spam ;) >> >> Well… if only it were that easy :p >> >> _______________________________________________ >> mailop mailing list >> mailop@mailop.org >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> > > > -- > =============================================== > Russell Clemings > <russ...@clemings.com> > =============================================== > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
