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

From: Joe McIsaac <[email-masked]>
Date: Mon, 6 Feb 2006 15:33:11 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Dave Crocker <[email-masked]>
Date: Tue, 07 Feb 2006 07:46:44 -0800

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

oh boy.

Mailbox NAT.

So much for end-to-end.

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 7 Feb 2006 07:59:22 -0800 (PST)

> So much for end-to-end.

This isn't something new at all as you probably know. And sendmail has
had email address rewriting and masquerading rulesets for years...

Many ISP gateways are kind-of like that as well as they redirect all
SMTP connections to their servers. They usually do not do any rewriting
and just force all connections to go through their server and not allow
anything where envelope from is not authorized within their domain.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Tue, 07 Feb 2006 12:14:59 -0800

Folks,

> anything where envelope from is not authorized within their domain.

SMTP RCPT-TO (right-hand side) domain name routing of connections through border 
(MX) gateways has nothing at all to do with modifications to RFC2822 message 
FROM header mailbox (left-hand side) strings, and especially nothing to do with 
making such modifications without the explicit knowledge of the originator.

d/

-- 

Dave Crocker

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 07 Feb 2006 17:01:35 -0500

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> had email address rewriting and masquerading rulesets for years...

Yes.  And we've been doing email address rewriting for over a decade
(internal versus external forms.  Internally, my email address isn't
[email-masked]).

But...  Before you do such a thing, consider what it does to S/Mime etc
(breaks it), and consider what you do with internal names that leak.
Multiplying your spam-cross-sectional-area Etc.

It's a hideous mess, and we're still paying for it.

Ick.

It's almost as bad as stealing someone else's IP space for your internal
(BIG!) network, and then trying to use a non-NATting firewall to the
Internet.  [Fortunately, we didn't fall for that trap.  An /8 is a big
thing to renumber.]
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows 2000)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQCVAwUBQ+j/sJ3FmCyJjHfhAQLadQP9H9HlbQsXM/hC/2jsIZhl6TVgUMno3i5i
g4dWWKPtexka9Qx/Fz1dXn1aY5qmDUYPJ9T0ruAnOPD/k51ncfoaVZFzHnBWekha
7t8kahWRUWF8oWOgQA+Jkuxn62xO/xz6aN3ebkRTkjLNJMXkmcuhKPkeZxObk53i
5cJEH14F3dc=
=lf8m
- -----END PGP SIGNATURE-----

---

From: Dave Crocker <[email-masked]>
Date: Tue, 07 Feb 2006 14:21:30 -0800

> It's a hideous mess, and we're still paying for it.

You know, it's been awhile since I've seen a really vigorous and innovative rant 
against NATs at an IETF meeting.  A few outbursts, now and then, but nothing 
really inspiring.

I suspect that an attempt to discuss applying the NAT construct to email would 
bring that religious vigor right back.

Yum!

d/

-- 

Dave Crocker