RE: CBV

> From: Stuart D. Gathman
> Sent: Friday, May 07, 2004 9:27 PM
>
>
> On Fri, 7 May 2004, Seth Goodman wrote:
>
> > > The CBV would work with the recipient sending the recipient
> > > as MAIL FROM
> > > and the sender as RCPT TO.
> >
> > This particular one hasn't been brought up before, and it's very clever.
> > The only difficulty is that recipient addresses change when
> > they go through
> > forwarding hops and the sender has no way of knowing what those new
> > addresses are.  I can't think of a way around this particular
> > limitation,
> > but if you can, it would be a much better way to avoid replay attacks.
>
> This is no different than forwarders that don't do SRS with SPF.  The
> solution is to just whitelist the forwarder.  If the forwarder does do
> SRS, then there is no problem.  The forwarder would do the CBV (or not)
> in the case of a bounce.

I think David is correct in pointing out that CBV's need to have a null
sender to prevent looping of CBV's.  Putting your own address in RCPT TO:
also makes it look like you're trying to use them as a relay.  Maybe you can
see a way around this, but it sounds like a problem.

As you first suggested, the sender can still put the original RCPT TO: in
the MAIL FROM:.  For a single recipient, this is no worse than including the
body hash in terms of string length.  Let's ignore, for the moment, the
problem of multiple recipients at the same domain.  Since forwarding is set
up by the recipient, they can whitelist any forwarding addresses they set up
and proceed with the CBV.  If the original RCPT TO: address that the sender
put in MAIL FROM: is not one of the recipient's forwarding accounts, they
can reject it as a forgery.  This works very nicely for single recipients.
The only cost is putting the full recipient address in MAIL FROM:, which
reduces the size left for the actual local part of the sender.  Since it
does not require a body check, it has a definite advantage as an anti-replay
measure.

That leaves us with multiple recipients at the same domain to deal with.
One approach would be to shorten the recipient name by replacing it with a
short hash, thereby allowing more of them to fit.  Each recipient address
would need a single hash string.  I don't think this would work out for the
following reasons.  To attack such a hashed address, let's say someone has a
database with every currently valid email address on the planet.  They then
calculate the hash for every address and index it by hash value.  When they
harvest an SES address, they look up the known addresses that match that
hash value.  As long as the number of such addresses is small, say ten hash
collisions per hash value, it would not be worth the effort because there
are not that many places to harvest an SES-signed address.  My guess is that
the hash length would have be pretty long to accomplish this, but we'd need
to guess the number of possible email addresses active at any one time to
determine this.

The database method is intriguing, however.  Since the recipient can't
decode the database key, the MX receiving the CBV would have to implement
the EXPN command, or something equivalent.  I know that most people choose
to shut off VRFY to discourage dictionary attacks, and I don't know how
people feel about turning on EXPN.  If allowing EXPN is acceptable, this is
a viable way to foil replay attacks before DATA, though it requires a
database at the sending end.

If we have a database at the sending end, we could also encode the local
part of the sender address in that same database key, just like the database
option in SRS.  This would result in local parts that are guaranteed to fit
in the 64-byte limit, but it obscures the local part of the sender address,
which is not desirable.  We can get around that by storing the sender
address along with the recipient list in the database so that EXPN would
give the sender address at the end of the list.

--

Seth Goodman