On Wed, 28 Sep 2005, Greg Connor wrote:
One question, which I'm not sure if you've already answered (thanks for
your patience, if so :)... In this RRS example:
MAIL FROM: <return(_at_)custhelp(_dot_)com>
RCPT TO: <RRS=IHBf67rW=blockbuster(_dot_)com=user(_at_)example(_dot_)com>
I understand that the RCPT contains instructions to "use blockbuster.com
instead of MAIL FROM domain for checking SPF".
What I am worried about is that some sender might send to my forwarding
address, and the forwarder relays the message on to my cookie-rcpt address,
but then a bounce is generated for some other reason (disk full, content
checks, etc). In this case, what if the forwarder sends a bounce back to
the sender showing my "secret" forwarding address?
The bounce will have MAIL FROM <> - and the forwarder would have to go
to a lot of work to correlate that with the cookie-rcpt address and leak
it. RRS is intended for forwarders that are honest but clueless.
Does the hash part only
work if the text following it is =blockbuster.com=, or can the same hash be
used to request my SPF check to user "spammer.com"?
The hash only works for blockbuster.com
I would assume that the forwarding/spf-expected-to-pass domain such as
=blockbuster.com= would be part of the hash formula, so that the hash
string can only be used on replay by someone authorized by blockbuster.com.
In that case it's not really important that the address I give the
"forwarder" be kept a "secret". I am assuming that's how it's intended to
work but I wanted to check.
If someone learns my secret and can re-use the hash with his own =domain=
after, then keeping the hash a secret between forwarder and recipient
becomes important, and I would then have to be paranoid about whether the
forwarder ever generates a bounce containing my hashed rrs address.
Also, the hash simply serves the function of avoiding a database. Equivalent
security is obtained with a database mapping selected rcpts to SPF domains.
And in fact, when you've already given the forwarder a local alias (e.g.
dvd(_at_)example(_dot_)com for the blockbuster example) before discovering how
brain-dead
their mail system is, the database is the easier option. I recently
realized that readonly (infrequently updated) databases like the sendmail
access file are actually quite simple and reliable to maintain. And
for my purposes (where enduser updates of the database are not needed),
does the job. I've ended up using the sendmail access file itself - with
additional tags recognized by milter for SPF policy, both general and
domain specific.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com