Skip to content 
A leftover mail-system artifact was sitting in a public web directory on transfer.scip.ch potentially holding the contents of undelivered messages for anyone who knew where to look.
What is a dead.letter File?
A dead.letter file is automatically created by Unix/Linux mail utilities such as mail, mailx, or sendmail whenever an email cannot be delivered or sent successfully.
Instead of discarding the message, the mail client stores its contents locally in a file named:
dead.letter
This file may contain:
- Email headers
- Email body
- Internal system information
- Usernames
- Email addresses
- Application-generated messages
- Debugging information
- Potentially sensitive business data
Normally, this file should remain on the local system and should never be accessible via a web server.
Steps to Reproduce
The exposure required nothing beyond a browser or a single HTTP request.
- Perform directory enumeration
Use a directory enumeration tool (e.g., dirsearch, ffuf, or gobuster) against the target web server to identify publicly accessible files. During enumeration, the dead.letter file is discovered.
- Observe the file contents
Navigate directly to https://redacted.com/dead.letter in a web browser or issue a standard HTTP GET request (e.g., using curl). The server returns the file without requiring authentication or performing any access control checks.
- Review what’s inside
Examine the contents of the dead.letter file. The file may contain undelivered email messages, including email headers, recipient addresses, message bodies, and other potentially sensitive information that should not be publicly accessible.
Why This Matters
Many administrators are unaware that mail clients automatically generate dead.letter files after failed email operations.
If these files accidentally end up inside a web-accessible directory, they may reveal:
- Internal email communications
- Error messages
- User information
- Email addresses
- Stack traces
- Application workflow details
- Sensitive business information
Remediation
Organizations should implement the following measures:
- Remove the File: Delete any publicly accessible dead.letter files from the web server.
- Store Mail Artifacts Securely: Configure mail utilities to store undelivered messages outside publicly accessible directories.
- Restrict Web Access: Prevent access to unintended files using web server configuration.
Example (Apache):
<Files “dead.letter”>
Require all denied
</Files>
Example (Nginx):
location = /dead.letter {
deny all;
}
- Review Production Deployments: Ensure temporary, backup, and debugging files are excluded from production deployments.
- Monitor for Sensitive Files: Regularly scan web roots for files such as:
- dead.letter
- .bak
- .old
- .swp
- backup.zip
- config.old
- dump.sql
- test.php
Lessons Learnt
Information disclosure vulnerabilities are often underestimated because they don’t require sophisticated exploitation. However, seemingly harmless files like dead.letter can expose valuable information that aids attackers in reconnaissance and social engineering.
Routine security reviews should include checks for unintended files within the web root, especially those generated by system utilities or development tools.
Conclusion
The exposure of a dead.letter file is a classic example of how operational artifacts can become security liabilities when left publicly accessible. While the fix is usually straightforward removing the file and ensuring mail artifacts are stored securely the potential impact can be significant depending on the data it contains.
Organizations should regularly audit publicly accessible directories, enforce secure deployment practices, and ensure that temporary or system-generated files are never exposed to the internet.