RE: The open relay problem.

On Friday April 2, [email protected] wrote:
> 
> Neil and David each proposed a solution, and the two are nearly identical.
> Neil proposed a special signed reverse address format that included a hash
> to be used from forwarding accounts.  This is an extremely clever way to
> avoid any administration, once the mechanism is set up to generate the
> addresses.  David proposed a specific, secret address at the SES host at
> which SES checking will not occur.  They are functionally very similar.
> Both act as whitelisted addresses for which SES checking will not be done,
> but there is a slight difference.

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.
i.e.
  my MTA receives a message from the MX for brown.name with
     MAIL FROM:<>
     RCPT TO:<[email protected]>
(or something like that).
 
 As it is FROM:<> but not to an SES address, we could Fail, but instead
 as it is an RRS address, SPF is tried for [email protected],
 extracted from the address.  This returns Pass which Trumps the Fail.

 Further, if my MTA receives a message from the MX for brown.name with
     MAIL FROM:<someone@somewhere>
     RCPT TO:<[email protected]>
 
 SPF against someone@somewhere returns Fail or at best Neutral.
 Because it is an RRS address, SPF is tried for [email protected]. This
 returns Pass which Trumps the Fail or Neutral.

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.

Blending this with David's proposal, I realise that a crypto-signature
isn't needed. As long as your mail system allows you to create
arbitrary local address (which mine does and I believe qmail does and
there are probably others), all you needs is:

 User creates a new local address which ends with (say)
   RRS+localpart+domain
 It will probably being with their username, but can contain anything
 else they like. e.g.
    neilb-secret+RRS+neil+brown.name
 They then register this as the address that localpart@domain will
 forward to.

 Their MTA should do normal SPF checking, but if it sees a RCPT TO
 address which ends "RRS+(.*)+(.*)", it does an SPF check on $1@$2 and
 if that gives a "better" result, use that instead.

This, I think, is a neat way to overcome the "forwarding problem"
without requiring other people to use SRS.  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.

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

NeilBrown