RE: [Asrg] Supplemental addresses (was: Indirection as a useful tool)

I totally agree with you that clogging the user's name space with email addresses and introducing changes in behavior is not going to work for widespread acceptance. I share with you in the belief that for a supplement address system to be even modestly successful, it must be transparent to most users and maintenance free, which we have strived to achieve in the extreme over a long stretch of R&D (almost 5 years now).

While working with live production installations, the market has taught us many things about what will, and will not, be acceptable in the use of supplemental addresses. One thing that has always been at the forefront of our design decisions was to increasingly make the the creation and management of supplemental addresses as transparent as possible. The good news is that most of our users say that they forget that they are using the system.   The bad news (at least for me) was that it took a long time to work out all the operational considerations to achieve transparency.

The system is deployed one enterprise at a time. All mail into and out of the enterprise is configured to pass through the system as a gateway. On the way out, the system determines, based on a fairly large number of criteria, which supplemental address(es) (if any) are to be used or whether a new one is to be created. All references to the original, "internal" address are replaced in the header, body and certain attachments with the "correct" supplemental address before delivery to the recipient.

On replies and messages sent back, the process is reversed. The system performs an address-specific perimeter defense check on the incoming message to ensure that the address is of a known user (which stops the pounding of messages to unknown addresses), then determines whether the recipient address requires a security assessment, and finally performs that assessment if required.

Disposition of messages deemed unacceptable can be handled in a wide variety of techniques (again, the market has taught us that everyone has a different preference). At the users option, they can be rejected, routed to a personal spam folder, routed to a delegated/group spam folder, or quarantined on our servers.

If security is either not needed or successfully cleared, any reference to supplemental addresses are translated to the original address before delivery to the host infrastructure/MTA.

So we scale one enterprise at a time. Each enterprise takes the full benefit for choosing to deploy our system without any change in the behavior of the vast majority of external correspondents that communicate with our users.   We add to our user base by the score, hundred(s) or thousands per enterprise.

One more thing that we have learned is that different people have different needs and preferences, and at all times our system can be configured to use many, some or no supplemental addresses based on user or enterprise properties. Some users may not like the idea of having more than 1 address, so they rely on content filtering or white listing alone (with or without C/R, which is optional, too). When no supplemental addresses are employed, our system has performance characteristics like many other "traditional" products, so at our worst we're like most other solutions.

However, looking just at the technology alone, when the user (or their admin) configures their account to use some, or many, supplemental addresses, in combination with content filtering or white listing, the overall performance of the combination improves for the user/host. >From a purely metric point-of-view (i.e. when measuring spam blocked, false positives, processing speed), customer data shows that the more supplemental addresses employed, the greater the performance and degree of control and forensic insight.   But, it's a reality that you cannot get everyone in even a small business to want or need the same power and level of control, so we allow different combinations to be chosen for people with varying spam problems and levels of technical acumen.

So I'm emphasizing a few things here. First, that it is possible to make the use of supplemental addresses very transparent to the user. Second, that not everyone will want to use supplemental addresses (at least initially), and that customers will want some inboxes to have only a single address (sales@, support@, abuse@), so implementation a of supplemental address model must offer a range of configurable address magnification behaviors, from 1 to some to many. Finally, combining other security approaches with supplemental addresses provides for a higher performance solution than the other security approach alone, the benefit for which can be consumed one enterprise at a time.