RE: The open relay problem.

> From: Neil Brown
> Sent: Monday, April 05, 2004 12:21 AM
>
>
> On Friday April 2, [email protected] wrote:
> >
> > Neil and David each proposed a solution, and the two are nearly
> >identical.

I do think Neil's proposal has lower administrative effort, though there are
a couple of points worth noting below.  Both Neil's and David's workarounds
essentially create a secret back door address for a non-SRS forwarding
account to send mail to an SES (or SPF) host.  In David's proposal, there is
one secret local forwarding address per customer he sets up manually, though
it could certainly be automated.  In Neil's proposal, the customer uses an
automated mechanism to generate a unique forwarding address for each
forwarding account.

<...>

>
> There is another difference.
> My proposal embedded the address of that the mail was originally to, and
> hence the address that the forward is (arguable) from in the
> new recipient address.
> The intention (I'm not sure if I made it clear) was that the receiving
> MTA would perform an SPF check on *that* address to see if the
> smtp-client was authorised.

An incoming SPF check on a secret address won't tell you much, though you
are certainly free to do it.  In both proposals, the RCPT TO: address is a
secret.  As long as the address remains secret, mail arriving for that
recipient can only come from the place that you personally set up.  The only
thing an SPF check would tell you is whether the secrecy of the address has
been compromised and the mail originated from somewhere other than the
forwarding host.  If that does happen, it will become obvious very quickly
to your user without any SPF checks.


> So the fact that we are embedding the intermediate address in the new
> recipient address means that the MTA can do SPF processing and get a
> useful result for *any* forwarded mail.

You can do an SPF check, but as I pointed out above, it gives you virtually
no additional information.


<...>

> This, I think, is a neat way to overcome the "forwarding problem"
> without requiring other people to use SRS.

Yes, it really is.  Anyone who wants to reject mail with SPF will need to
implement some kind of "back door" for non-SRS forwarders, which I believe
will be the majority of them.  This solution is just as useful for them as
for anyone who wants to do SES.


> Once I convince all my
> customers to modify any addresses that forward to them, I can start
> rejecting SPF=Fail messages safely, all without any reference to, or
> dependence on, other sites.

I agree.  Let me suggest a couple of successive refinements to your
proposal.  I previously suggested that SES works best if each user has their
own hash secret, rather than a common domain secret.  Since the RRS
addresses are static and have no timestamp that allows them to automatically
expire, they are vulnerable to being discovered and used in replay attacks.
If this does occur, the user would have to change their hash secret, then
create and configure new forwarding addresses for all of their forwarding
accounts.  If your setup is good enough that this can't happen, you may not
care to worry about it.

However, there is a simple way to limit the possible damage to a single
forwarding account.  That is to use a per forwarding domain salt value to
change the hash result in the RRS address.  This permits you to change an
individual forwarding address without affecting any other forwarding
addresses for a particular user.  The salt can be anything, so I propose to
use a sequential number at the time you generate the RRS address for a
particular forwarding account.

Once generated, you keep track of the salt value for each particular user
and particular account within each forwarding domain.  If one of the user's
secret forwarding addresses is discovered, all they need to do is get a new
salt value to generate a new forwarding address for that one forwarding
account.  All you do is assign the next unused salt value for the forwarding
domain for that user and calculate a new hash using the user's hash secret.
Since the salt value will force a unique hash value for each account at the
forwarding domain, you no longer need to include the local part of the
forwarding address.  Besides, only the forwarding domain is needed for an
SPF query, should you feel the need to do one.  The shortened format would
be:

RRS=HHHH=SS=forwarder_domain=local_part@domain

where SS = salt value consisting of two
           base-64 digits

This gives 4K possible salt values per forwarding domain per user.  It also
avoids exposing the full forwarding account address.  After receiving a
message with a RCPT TO: in this format, do an SPF check, then lookup the
salt value under the user's account and forwarding domain for validity, and
finally lookup the user's hash secret and verify the hash value.  This is a
lot of work, but fortunately we can reduce it.

Since the above RRS address is static, it can become a local alias on your
MTA to the user's account, as in David's proposal.  In this case, the salt
value is not needed since an address can be verified by checking for its
existence.  The "HHHH" value can be generated by successive hashing, so
there is no limit to the number of forwarding accounts.  With this
implementation, the format would be:

RRS=HHHH=forwarder_domain=local_part@domain

where HHHH = a database key under the local user that represents
             the local part of a forwarding account address; it
             is a static value that is generated once for a given
             forwarding account, or whenever a new RRS address
             is desired for that forwarding account; it consists
             of the first four base-64 digits of the SHA-1 hash
             of the most recently generated RRS address for this
             user prepended with the user's hash secret;

These addresses are aliases to the user's account on your MTA.  Upon
receiving a message with this RCPT TO: format, do an SPF check, then check
for the existence of the RCPT TO: address and accept or reject the message
based on that.

If you agree that SPF checks on these special addresses don't buy you much,
the address can be further simplified since you don't need the forwarding
domain.  In this case, we are left with:

RRS=HHHH=local_part@domain

where HHHH = a database key under the local user that represents
             the FQDN of a forwarding account; it is a static
             value that is generated once for a given forwarding
             account, or whenever a new RRS address is desired
             for that forwarding account; it consists of the
             first four base-64 digits of the SHA-1 hash of the
             most recently generated RRS address for this user
             prepended with the user's hash secret;

These addresses are aliases to the user's account on your MTA.  Upon
receiving a message with this RCPT TO: format, regardless of the MAIL FROM:
address, check for the existence of the RCPT TO: address and accept or
reject the message based on that.  Now we have a very lightweight back door
for forwarding accounts.



>
> (Note that I'm not against forwarded implementing SRS if they want
> to.  It might make their customers lives easier. But requiring all
> forwards, big and small, to implement SRS is a bit too much I think).

SRS doesn't break anything you've suggested, and I certainly agree that
expecting most forwarders to implement SRS is unrealistic at best.

--

Seth Goodman