Optimization Proposal for Link Tracking System

[bigexxx]

The current link tracking system is inefficient when handling a large volume of emails. For each email sent, the system creates a new database entry for every link. For instance, an email with 5 links generates 5 database entries, each storing a link hash.

This approach poses scalability challenges, particularly when considering the requirement that all links in emails must remain functional indefinitely. Deleting database entries to manage storage is not feasible, as it would render the corresponding links inoperative.

To address this, I propose eliminating the need for database entries for each link. Instead, we could encode the full URL directly in the tracking link along with the message ID. For example:

https://track.domain.com/{base64encoded message_id + original_url}

When a user clicks this link, we can decode the URL and message ID, track the click, and redirect the user to the original URL. This method eliminates the need for a dedicated "links" table in the database, significantly simplifying the system and improving scalability.

This solution maintains the core functionality of tracking while reducing database dependency and enhancing system performance.

[willpower232]

This would also present a security issue as without a copy of the original link in the database, Postal would redirect the user to any URL so could be used to hide spam and phishing related activity.

[bigexxx]

can be easily extended with sign token
https://track.domain.com/{base64encoded message_id + original_url + sign}
sign = sha1(message_id + original_url + secret)
secret - configured per mail server for example