I wrote:
But here's what makes supplemental addresses really interesting. When
you combine the use of supplemental addresses with pretty much any other
anti-spam model, it tends to preserve the strength of the model while
greatly reducing or even eliminating the negative side effects that
pretty much every model contains.
Dave Crocker wrote:
Expecting users to create, remember and use any significant number of
different
email addresses imposes a significant burden on them. While you or I might
find
that burden both feasible and worthwhile, will it be either of these for an
"average" user?
So my question about supplemental addresses is how they can possibly be
viable
in the Internet scale and variability of a billion users?
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.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg