From: spf(_at_)metro(_dot_)cx
Sent: Thursday, April 22, 2004 4:35 PM
<...>
I don't like the shuffling around with keys and passwords, third
parties, etc. I think someone else said something earlier on this list
about keys that bind to channel/person combinations, not just persons.
That's interesting and I'd like to know more about it. Ed mentioned
disposable secrets, which is a reasonable approach. How does one go about
binding keys to a channel, rather than a person?
I think that is already more sensible. But what I said above would be the
best way to go about it in my opinion (Reply-to if they want, but take
care of the bounces themselves).
Doh!!! That's totally reasonable and I should have thought of it myself :)
Of all the RFC2822 "originator fields", Reply-To: is the one that
historically has had the most flexibility. S/MIME doesn't even enforce it.
Setting the return-path to the untrusted third party site (hospital or
greeting card site) and setting Reply-To: to the address provided by the
user is an appropriate way to be a responsible third-party sender. To
completely the picture, they should ideally write the From: field with their
address sending on behalf of the claimed sender, just like a mailing list.
If they receive a bounce, they should just drop it, as the Reply-To: address
is untrusted, also just like a mailing list.
In fact, if they simply behaved exactly like mailing lists, they would both
be RFC2821 and SPF compliant. Perhaps we should push that solution for
greeting card sites instead of SRS. It is trivial to implement compared to
SRS and they wouldn't be making an assertion about the user's address that
they are in no position to make. This sounds like a win-win.
--
Seth Goodman