Auto-forwarding has significant risks, which I will elaborate below. To allow those risks to be managed effectively, SmarterMail needs these additional features:
- More flexible controls over who can forward.
Currently the system options are “anyone can forward their own mail” and “no one can forward mail”. These restrictions can be partly evaded by converting accounts to aliases, but that process is cumbersome. A more appropriate selection mechanism would be: “users can forward their own mail”, “user cannot but domain owners can forward for their users”, “only system admins can forward mail”, and “no forwarding”.
- Better auditing
A domain owner should be able to obtain a report showing all off-domain forwarding, with selection by category, but able to include user-level forwards, aliases, and mailing lists. Similarly, a system administrator should be able to obtain a report showing all off-system forwarding, with selection by category but able to include user-level forwards, aliases, and mailing lists.
Risks created by Forwarding
Forwarding is fraught with risks to both the domain owner and the system administrator. These include:
Data management
- Data loss: What if the forward is releasing information which is sensitive to the company or restricted by regulation?
- Clutter: Once a mailbox is forwarded, the mailbox will rarely be opened. If messages are retained after forwarding, space usage can grow without limit. If a space quota is being reached, the mailbox owner will be unaware of the problem.
- Lost messages: If messages are forwarded without retaining a copy, any messages that cannot be forwarded will be lost forever.
Validating the target account:
- Do we know that the forwarding target account exists?
- Do we know that the forwarding target account wants to receive these forwards?
- Is the target account consistent with domain owner policies?
Spam Filtering
Spam filtering is unique to each installation, creating a no-win situation for the forwarding server. If the forwarder allows messages that the destination system considers unacceptable, the reputation of the forwarding server will suffer, possibly causing the forwarding server to be blacklisted, affecting all users on all hosted domains. If the forwarder tightens its filtering rules to reduce this risk, some wanted messages may be blocked and the user will be unhappy. Since messages can be lost at either the forwarding or the destination server, finding the root cause of a missing message will be doubly difficult.
Effect of Content Changes on DMARC authentication
Many spam filters make content changes to incoming messages. Some tag every message to indicate that it comes from an external source. Others tag conditionally, to identify messages that are slightly suspicious but not suspicious enough to block completely. Any of these changes will invalidate DMARC signatures in the message. For messages coming from domains that publish DMARC policies, these changes will cause the forwarded message to fail DMARC validation, causing individual messages to be blocked and the reputation of the forwarding system to be hurt. Reversing the changes to repair the signature is probably not feasible.
Recommendations
Minimize Use
Given the problems that forwarding creates, it should be avoided whenever possible. Users may think they need all messages in a single mailbox, but that need can usually be met by putting all accounts in a single user interface on an email client like Outlook, and by putting all accounts on the user’s cell phone.
Managing Target Account Risks
I suggest that individual users should never be allowed to configure their own forwards. Instead, they should be required to submit a forwarding request to the domain administrator, using message requests sent from both the forwarding account and the recipient account This verifies that the target account exists and wants the forward. Then the administrator reviews the request against any applicable organization policies. After all checks are passed, the system administrator configures the forward and notifies the affected user.
Use Sender Rewriting Service (SRS)
SRS is a technique used to alter the SMTP “Mail From” address so that the forwarded messages passes SPF based on the forwarder identity, rather than failing SPF based on the original “Mail From” identity. This is likely to reduce the risk of a message being blocked as an unauthorized impersonation. SmarterMail provides a checkbox to enable SRS on forwards. This effectively declares the forwarding server to be responsible for the message, so any forwarding of malicious mail will have an increased impact on the forwarding server’s reputation.
Avoid Content Changes for Forwarded Accounts
If message changes can be avoided, or if they can be avoided for forwarding accounts, then DKIM signatures will be unaffected. This prevents problems that may be caused by DMARC failures.
Manage Reputation Risks
Whenever possible, the forwarding system administrator should establish a communication channel with the target system’s administrator. This gives the forwarding system administrator an opportunity to establish trust by explaining spam controls that he applies to all messages. It also gives the target system administrator information needed to adjust his filtering rules to minimize the risk of unwanted blocks of individual messages and unwanted impacts on the forwarding server reputation.