Is there a place for RRS - a recipient rewriting scheme.

Hi,
 SRS was created to try to overcome a perceived problem with SPF.
 That problem being that SPF cannot reliably assess mail that has
 passed through a forwarder.

 SRS addresses this problem by requiring the forwarder to rewrite the
 sender address.

 Some people are unhappy with this solution.

 One way to describe the basis for this unhappyiness is that requiring
 a forwarder to do something is simply not possible.  I can control my
 own mail server.  I cannot control anyone else's.

 For this reason, I think there needs to be a solution to the
 forwarder problem that each party can independently enact to help be
 sure that mail gets through.

 The forwarder can use SRS on mail that passes through and thereby
 make the mail more likely to be recieved.
 The original sensed can (possibly) use universal SRS to authenticate
 themselves as sender which might help their mail get  through (if
 recipients that implement SPF are willing to check universal SRS as
 well).

 But what can the recipient do?  I.e. what can I do the make sure that
 mail forwarded to users at my site get through, but that still allows
 me to reject lots of mail based on SPF checks.

 One thing that I have mentioned is to have local users register any
 aliases that might be sending them mail, and to allow any mail to
 them from authorised senders for that domain.
 But this solution has real problems as keeping this database uptodate
 and working would undoubtedly be an unpleasant overhead.

 Another solution that recently occurred to me is to use recipient
 rewriting.   It would work like this:

   When someone wants to set up a forwarder somewhere that forwards to
   their account on my mailserver, they ask for a signed address (using
   some local setuid program or a webpage that authenticates them or
   similar). 
   This address looks something like:
	RRS+HHHH+forwarderdomain+forwarderlocalpart+locallocalpart@domain
   where the HHHH is a crypto HASH of some secret with the rest of the
   address. 

   If I receive an address like that, I check that the HHHH is
   correct, and if it is, I use forwarderlocalpart@forwarderdomain as
   the responsible sender for an SPF check.  The result of that check
   is used as input to my local policy for rejecting or accepting
   email.

   If the mail is accepted, it is sent on to locallocalpart@domain of
   course.

 This approach still requires my customers to be aware of their
 forwarders and to take local action with respect to them, but it
 means that I don't have to maintain a database. 

Having a range of mechanisms that I can use depending on whether I am
acting as a sender, and recipient, or a forwarder means that I can
maximise the chance of my customers mail getting through, both
incoming and outgoing, without depending on particular behaviour of
other sites.  I think this is a win.

NeilBrown