Email Bounce Attack Prevention via Local DSN Database Tracking
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
E-mail bounce attacks disrupt computer users and enterprises by sending unsolicited spam or phishing messages, making it difficult to track the original attacker and causing unnecessary email storage, with existing solutions like BATV being intrusive, requiring rigorous deployment, and susceptible to false positives and capture/replay attacks.
Innovation Solution
A bounce prevention system that records information about outgoing email messages in a local database, allowing comparison with incoming delivery status notifications to identify legitimate messages and thwart fake ones, using a DSN counter to detect capture/replay attacks without modifying sender addresses, thus avoiding the limitations of BATV.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If BATV (Bounce Address Tag Validation) is used to prevent bounce attacks, then bounce attack prevention capability is improved, but deployment complexity increases and false positives occur
Solution Approach 1:
The system performs preliminary actions by recording outgoing email message information in a local database before bounce attacks can occur. When a DSN message is received, the system compares it against the pre-recorded information to quickly determine legitimacy, avoiding the need for complex real-time verification and reducing false positives.
Solution Approach 2:
The system creates a local copy of outgoing email message information in a database, including message identifiers, timestamps, and recipient information. This copy is then used for rapid comparison with incoming DSN messages, eliminating the need for complex real-time communication with the original sending server and simplifying deployment.
2Measurement precision
If BATV is deployed to detect fake DSN messages, then detection accuracy is improved, but processing time increases due to rigorous verification
Solution Approach 1:
The system performs preliminary actions by recording outgoing email message information in a local database before bounce attacks can occur. When a DSN message is received, the system compares it against the pre-recorded information to quickly determine legitimacy, avoiding the need for complex real-time verification and reducing false positives.
Solution Approach 2:
The system skips time-consuming verification steps by using pre-recorded email information for direct comparison with incoming DSN messages. This allows the system to rapidly process and evaluate DSN messages without undergoing rigorous real-time verification, thus reducing processing time while maintaining detection accuracy.
3Object-affected harmful factors
If incoming DSN messages are screened to prevent spam, then spam delivery is reduced, but legitimate message delivery may be blocked
Solution Approach 1:
The system creates a local copy of outgoing email message information in a database, including message identifiers, timestamps, and recipient addresses. This copy is then used for rapid comparison with incoming DSN messages, enabling accurate identification of legitimate messages while filtering out spam, thus preventing both spam delivery and false blocking of legitimate messages.
Solution Approach 2:
The system uses feedback from the local database comparison to determine whether to deliver or block incoming DSN messages. By comparing message identifiers, timestamps, and recipient information against pre-recorded data, the system receives feedback that accurately identifies legitimate messages, ensuring they are delivered while blocking spam.
4Reliability
If sender addresses are modified to prevent bounce attacks, then attack prevention is improved, but system compatibility decreases
Solution Approach 1:
The system extracts the essential verification information (message identifier, timestamp, recipient address) from outgoing emails and stores it locally. This extraction allows the system to verify incoming DSN messages without modifying sender addresses, maintaining compatibility with existing email systems while still providing effective attack prevention.
Solution Approach 2:
The local database acts as an intermediary between outgoing emails and incoming DSN messages. Instead of modifying sender addresses, the system uses this intermediary storage to record and compare message information, enabling verification while maintaining full compatibility with standard email protocols and systems.
Data Source
AI summary
Information such as message identifier, sender, recipient, timestamp, etc., are recorded in a record in a local database as an e-mail message is sent out. A DSN counter is set equal to the total number of recipients, thus allowing returned messages to be compared against this counter to thwart a capture/replay attack. When a DSN message is received at the computer system it includes the originally sent e-mail message. The DSN message may be legitimate or it may be a faked DSN message. The system searches the local database for a record having information that matches with the returned e-mail message. If a match exists, the DSN message is legitimate and it is delivered to the original sender. If no match exists, then the DSN message has been faked and appropriate action is taken. When a match occurs, a match count value is incremented for that record and compared against the originally stored DSN count value. If the number of received DSN messages is greater than the original number of recipients, then a capture/replay attack has occurred and appropriate action is taken.