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

From: [email-masked]
Date: Tue, 7 Feb 2006 08:10:16 -0800

---------------
>>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.
>Isn't this (an over engineered) auto-whitelist?

No, because you're not tabulating policy based on outside sender, you're
implementing your policy against the E-mail address you show to this part of
the world.

>oh boy.
>Mailbox NAT.
>So much for end-to-end.

Why do you claim an end-to-end problem?  You can reach any correspondent,
and they can reach you back, with the same level of automation as the
current E-mail system.

A different way to look at this is that you've overloaded the From: field
with not only your E-mail account name but also a credential.  This
credential is transitive (in the sense that if you order from Foo Corp., and
they give that E-mail address to UPS for tracking updates, UPS can reach you
via it too) and revocable (so if it gets abused, you shut it off, without
affecting any users of any other credentialed variants of your
address--including UPS, who might also be sending you updates concerning
your Bar Corp. order).

If it sounds like I have some experience living with this... :->

We're now in year 2 or 3 or so with an implementation of this technique.  I
still owe this list an updated document, but you can read the older version
at:
	http://www.vsta.org/spam/

The short version is that it continues to work very well for us.

It turns out that you don't need a custom E-mail gateway, you can implement
it all in your local E-mail client.  All you need from the mail server is
tha ability to register those credentialed variants of your address.  We did
that in bulk, pouring them into the aliases file.  Then on demand my mail
client can take the next free one from the list, checking off its use (and
tabulating for whom it was allocated).

Regards,
Andy Valencia

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Joe McIsaac <[email-masked]>
Date: Tue, 7 Feb 2006 13:37:03 -0500

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.

 
> 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.

---

From: "Brian Azzopardi" <[email-masked]>
Date: Wed, 8 Feb 2006 09:53:22 +0100

> 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: [email-masked] [mailto:[email-masked]] 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"

 
> 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.

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.

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

---

From: Joe McIsaac <[email-masked]>
Date: Thu, 9 Feb 2006 12:41:56 -0500

Walter wrote:
> Actually, that's what I use it for, and I think it's good idea... 
> ...The advantage of multiple addresses is that email that *MUST* get
> through can be given a free pass, while email from strangers can run the
> gauntlet of spam-blocking checks. More stringent filtering *AND* fewer
> false-positives... that's definitely "win-win".

> Walter Dnes <[email-masked]> In linux /sbin/init is Job #1

What I'm espousing is the engineering support that will bring the benefits of
your techniques to the majority of email users.

---

From: Joe McIsaac <[email-masked]>
Date: Thu, 9 Feb 2006 12:40:04 -0500

>Mmm, misses the point eh.

Not at all.  In practice, supplemental addresses do proliferate, but there
will be "communities" of correspondents that naturally become dependent on
using a shared address, i. e. those to whom I share a supplemental address
rightfully should keep using it going forward, as opposed to the system
"forcing" them to a different address.  In other words, it's beneficial to
employ as many addresses as possible, but no more than that.

Brian wrote:
>... I've come to appreciate much more the need for simple,

And my point is that were you to employ the additional dimension of
supplemental addresses, which can be implemented as a transparent-to-the-user
enhancement, the overall performance of your filter would improve.  The rate
of false positives, however small, would decrease.  The processing time per
message would also decrease with no change in the level of effectiveness, and
there are forensic benefits to exposing things that cannot be seen, but which
exist, such as the sharing of your address.