spf-discuss
[Top] [All Lists]

RE: Recipient Rewriting Scheme

2005-08-17 15:21:11
From: Stuart D. Gathman [mailto:stuart(_at_)bmsi(_dot_)com]
Sent: Wednesday, August 17, 2005 3:21 PM


Found this going through my pymilter TODO list:

Implement RRS - a backdoor for non-SRS forwarders.

<...>

RRS=IHBf67rW=blockbuster(_dot_)com=user(_at_)example(_dot_)com

<...>

Now, when email arrives to that address, the SPF check is done against
blockbuster.com - even though the MAIL FROM says custhelp.com - and
the mail is delivered to user(_at_)example(_dot_)com(_dot_)  This is a much 
more controlled
workaround than accepting SPF FAIL for custhelp.com - which has a
perfectly good SPF record.

This is a really clever way to handle non-SRS forwarders at the recipient.
AFAICT, it will work as well as SRS.  It also has the same weakness as SRS,
which is that you authenticate the forwarder, not the source of the mail.
But if you really like SRS as a forwarding mechanism, this is a great way to
plug the holes.  It might take a bit of hand-holding, but it could be
largely automated.



I bring this up, because it is a solution to handling per-user
non-SRS forwarders that does not involve a separate database.  However,
once an RRS signature is issued, there is no way to un-authorize a non-SRS
forwarder without resorting to a block list.

Unless I'm misunderstanding your proposal, why not just close that specific
RSS address account?  I'm assuming that each one of these addresses is a
functioning incoming-only address that forwards to the user's mailbox.  Your
milter could even strip the RSS string off the address so the user never has
to see it.  When you create new RSS hashes, include an ordinal or random
number in the string that you hash.  This way, if you ever want to
reauthorize that same non-SRS forwarder for that same user, you will
generate a different hash for the same forwarder-user pair.

--

Seth Goodman


<Prev in Thread] Current Thread [Next in Thread>