feat(backend): vendor detection groundwork & data-request integration

[Grandi0z]

Related task

[Grandi0z]

Hi @kroky,

I would like to get your feedback before moving forward with this work.

At the moment, this MR:

• detects the sending vendor / platform of an email (based on header analysis),
• exposes this information in the UI,
• and provides external links to datarequests.org, allowing the user to:
  • request access to their personal data,
  • request deletion of their data,
  • object to marketing messages, etc.

This feature relies on data stored in
assets/data/datarequests_companies.json
to determine whether the detected vendor / platform is listed on datarequests.org.

There is an existing open-source project that maintains this dataset:
github.com/datenanfragen/data

So, it's possible to add a scrip to automatically or semi-automatically update datarequests_companies.json from this repository.

---

Guidance requested

1. Handling data access requests (GDPR / data rights)

In addition to the company list, the datenanfragen/data repository also provides request templates used to formulate GDPR / data rights requests.

Two approaches are possible:

• External flow (current approach)
  Redirect the user to datarequests.org, where they complete and send the request using their interface.

• Integrated flow
  Allow the user to stay within Cypht and use these templates to pre-generate an editable request letter, which the user can then send themselves.
  There is also an open-source project that already implements this logic:
  datenanfragen/letter-generator

👉 Which approach would be preferred here: a simpler external redirection, or a more integrated solution, or a hybrid one?

---

2. Abuse / spam reporting

Beyond data rights actions, users should also be able to report a message as abuse.

In my opinion, this should be handled in a separate MR, extending the existing spam reporting feature:
PR #1551

The goal would be to consolidate reporting into a single place, covering:

• Community / NGO reporting (APWG, SpamCop),
• Infrastructure abuse reporting (AbuseIPDB),
• Vendor / platform abuse reporting (Amazon SES, Salesforce, SendGrid, etc.).

This would likely require both MRs (vendor detection + spam reporting) to be merged before full integration.

---

3. Blocking behavior (Phase 5)

Blocking functionality already exists (block sender / block sender domain) and is implemented via Sieve.

I believe we could extend the existing blocking scope so that, in addition to blocking:

• a specific sender,
• or a sender domain,

the user could also block an entire vendor / platform (e.g. Salesforce or Amazon SES).

This extension could likely be included in this MR, as it builds directly on the existing blocking mechanism and may not require a separate MR.

---

Thank you in advance for your feedback and guidance before I continue further.

[kroky]

@Grandi0z I see the related task but is there an action plan? I saw messages that you met with Marc and discuss about possible roadmap and plan of actions. Is it written somewhere? I personally understand the immediate need as being able to identify if the email comes from a big corporation and then ability to send requests to stop emailing, request personal data, etc. via GDPR or other lawful requirements. The use of an external well-maintained database is a nice idea. Vendor detection also needs to be robust and I think you are in the right direction. Just please share any more documentation you have, so I know the action way we should go.

[Grandi0z]

Just please share any more documentation you have, so I know the action way we should go.

Thank you for your feedback, Kroky.
At this point, we haven’t yet had this discussion with @marclaporte, since he has not organized any Office hours so far.

To avoid blocking progress, I will instead invite Marc to leave a comment directly on the task. That way, we can have his written input and clarify the roadmap

[marclaporte]

Some feedback from the datarequest.org community