From a purely theoretical point of view, the goal of using
supplemental addresses is to get people to use as many different
addresses as possible ...
I thought the goal was to kill spam and eliminate false-positives?
... although in reality this does not take place
Mmm, misses the point eh.
However, I am certain that many of the content filtering services have
vastly more sophisticated technology than what is required to support
supplemental addresses.
Indeed - and that's where it should be infact and why just sticking to a
simpler system would have been a net win. I should know, I've
implemented a server-side Bayesian filter, and while very effective, the
design and testing required was much more intensive then for when I
implemented other types of filters, including auto and manual
whitelists. I've come to appreciate much more the need for simple,
robust filters, whether they are targeted for client machines or SMEs.
Brian
-----Original Message-----
From: asrg-bounces(_at_)ietf(_dot_)org
[mailto:asrg-bounces(_at_)ietf(_dot_)org] On Behalf Of
Joe McIsaac
Sent: Tuesday, February 07, 2006 7:37 PM
To: Asrg (E-mail)
Subject: Re: [Asrg] Supplemental addresses (was: Indirection as a useful
tool)
I wrote:
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.
Brian wrote:
Isn't this (an over engineered) auto-whitelist?
Brian
Quite the contrary. I understand that this approach might appear
similar to white listing in that managing supplemental addresses
requires correlating the identity of outside correspondents to
supplemental addresses. However, white listing has the net effect of
encouraging dialogue to a single address, which is the opposite of the
goal of using supplemental addresses. From a purely theoretical point
of view, the goal of using supplemental addresses is to get people to
use as many different addresses as possible, although in reality this
does not take place. In practice, certain addresses are used by
multiple correspondents -- creating "communities" of correspondents that
are implicitly and explicitly accumulated. Some users employ only one
or a few supplemental addresses because that's how they want to use the
technology. Still others don't want to use them, but still need spam
relief, so all of these conditions must be satisfied.
As to the level of engineering, if you set out to build a system that
employed supplemental addresses, managed which addresses required a
security pass, and kept track of which correspondents used which
supplemental addresses, the level of engineering would find itself.
Add a few additional requirements that we observed in implementation:
1) Address management must be transparent to the end user
2) Outside contacts must be insulated from any aggravation during the
adoption by new users
3) Users must be able to employ the system with no little or no change
in behavior and no training
I agree that the engineering isn't trivial. However, I am certain that
many of the content filtering services have vastly more sophisticated
technology than what is required to support supplemental addresses. The
hard part is working out all the subtleties when you actually get a
diverse and large group of users while maintaining transparency for
users.
The model holds up over time, and serves as a complementary and additive
technique to any other email security approach. It is liberating, as
more and more legitimate mail is kept from having to run the rapids of
any security scrutiny that might mistakenly block or delay delivery.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
This mail was checked for viruses by GFI MailSecurity.
GFI also develops anti-spam software (GFI MailEssentials), a fax server (GFI
FAXmaker), and network security and management software (GFI LANguard) -
www.gfi.com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg