justreportit / thunderbird

Thunderbird plugin.
GNU General Public License v3.0
26 stars 3 forks source link

More detailed and filterable report messages #64

Open mirror176 opened 3 months ago

mirror176 commented 3 months ago

If possible, it would help if the message body could be structured to include more known details into it. Doing so could help users decide if they still want to send a message to the registrar as I doubt sending to some of them are useful. Explaining what was detected helps the user learn and helps the receiving end know what content is theirs to review and take action on. As I got started with the addon, I did wonder if it was a lookup based on 'sent from' vs other email headers. Having the message as an attachment without relevant/dynamic content makes it harder to find if it was the report for gmail.con, gmail.com or gmail.com that I should open when I need to provide additional content or submit it in another way; if the original message is now gone, that becomes even harder to sort out; including a unique ID within the message would also help here. If justreportit is set to move message to trash, and is clicked on a message in trash, it is deleted at that point; not sure if that was the intended action.

If a registrar registers a domain with various owner details hidden including no contact then I see value in reaching out to them over the issue as at that point it seems like they are in agreement to protect/shelter the owner and make themself the known contact. Markmonitor is a common recipient of my justreportit clicks) has begun sending email responses "Markmonitor has neither control nor responsibility over any of the content of such domains including any related email or website content. Further, Markmonitor neither manages nor operates the servers on which such content is hosted." and states that the registrar is the only one responsible. That does contradict https://www.markmonitor.com/domain-management-terms-and-conditions/ which say that it must comply with ICANN and their own legal terms; spam is in violation of their own terms and in violation of ICANN terms at least if it includes botnet/malware/pharming/phishing activities. Not sure where the line gets drawn between a bad domain vs a good domain that gets abused a little vs a good domain that gets abused a lot (and without reports, would they even ever know). In the case of a good or major actor instead of a domain bought/ran by a bad actor, I'd presume nothing will happen by reaching the registrar. If sending to markmonitor due to gmail.com and outlook.com spam is considered useful then let me know. Contacting the domain owner could be useful in the case of hacked/abused systems and is likely the intended route of markmonitor's "we aren't responsible and can't/won't take action" but seems like a bad plan for domains owned by bad actors. Is it ever worth considering a report option there or is something like spamcop viewed as doing the better job?

Some registrars offer lookup services; would it be worth reprobing their own service when possible for a domain they performed the registration of instead of stopping at the first lookup if trying to find domain owner contact details?

It could be handy to be able to filter based on detected conditions such as certain big tech domain names if reaction will not happen or the registrars if they become known as unresponsive/uncooperative.

If message content could be detected even in a basic sense, some reports could be changed to be looked at with different urgency; though a refund scammer and someone steering traffic to a random site through tracking links are just as annoying to me, different groups are more willing to take action and quicker as more crimes get involved. I'd guess this would require each user manually creating/maintaining their list of bad things like 'norton/mcafee/etc' that they want marked unless developing a bayesian like filtering that starts doing it automatically (like thunderbird's junk/not-junk but with multiple categorizations). Such detection could have manually created but automatically applied parts to the messages but such messages should always then be reviewed by the user before sending.