Manage Mailing lists that don't use list-id correctly
-
Mailing lists / newsletters should use List-ID (RFC 2919) to make it possible for clients to filter for mails from the same list. I receive some really nice newsletters that sadly use a new list-id for every new mailing, breaking the entire concept. In M2, it made the mailing list filter useless for me. See attached M2 screenshot below.
M3 now can distinguish between "important" and "other". Good first step to handle the problem - move those to "important" that work, everything else is buried in "other"
Problem: if the newsletter content is good but they just don't get their list-id fixed, I can't use the Mailing Lists view to summarize them.
Suggestion: have a learning mailing list functionality (in a way like the spam filter): Assume I have several mails from the same newsletter but their list-id's show "List-ID: A" for mail a, "List-ID: B" for mail b, "List-ID: C" for mail c, ...
--> If I drag mail b on the mailing list for A, let the filter learn to look for other indicators that are similar and learn to "correct" the wrong list-idsOr come up with a better solution, because that suggestion is going to be a lot of work too, and you don't want to explain to anyone why that is necessary in the year 2021
+++++
-
Have you ever contacted the provider and asked them to conform with the RFC? I do not have deep knowledge in this field, but if this is the (de facto) standard for mailing lists, maybe it is them who should conform with it and not vivaldi which should implement work arounds.
-
@jumpsq no I haven't, in Opera m2 mailing lists filter contains many such problematic mailing lists. I totally agree they need to fix it but if Vivaldi wants to provide a mail client for folks that don't want to dig into email header settings and write bug reports, the mail client needs to cope with incorrect use of such settings in an elegant manner.
Could actually be the start of a general "smart filter" where I drag email a on email b and Vivaldi looks for all the things they have alike.
-
@jumpsq My fear is most provider forget to adhere these RFCs - if any - as this will decrease their mass-mailing potential. It seems logical to have a request for them and maybe letting to sort them from labels or filters.
But asking to the providers won't hurt. In the worst case, they'll just ignore the mail.
Or probably thesecrsend.com
could be coupled in a symbolic other sub-folder. But still, this need time. -
For me it appears that most do not follow the RFC and as is the functionality is unusable.
Have hundreds of mailing lists entries.
Every kickstarter mail is a different entry. The same for rockstar:
Some list-id appear to be re-used by more than one sender:
There is the option to treat the sender as a mailing-list and that gives better results but overall, and as is, the feature is unmanageable. As is I would prefer the ability to hide the mailing list entry on the panel.
-
Ok, so the new mailing list groups should fix this issue.
Just go to the mailing list make a new mailing list group that hasList-id Ends With crsend.com
@Durtro The xt.local should already be fixed since it's a default mailing list group already.
The Indiegala mailing list I don't know why you have many. You could either just make a mailing list group for Indiegala or try regenerate from right clicking on the mailing lists root from the panel
-
@gmg yes, xt.local and list-id.mcsv.net were two that fixed themselves and were responsible for most of the clutter.
Already solved indiegala from the instructions on the other thread. The multiple indiegala were always .newsletter[1-8].indiegala.com so a ends with ".indiegala.com"solved it.
Only had to remove 8 entries, each one with only one email and not following any rule.
-
@gmg Not sure I really understand the settings, but the magic you wrought definitely cleaned up the mailing list filter and made it much much more useable. thanks a bunch!
-
@WildEnte you can see @gmg reply on https://forum.vivaldi.net/topic/57653/what-are-these-folders-look-like-1064447_3256104-xt-local/13?_=1616708445793 for some details