Re: SPF and the need for SRS

On Sat, Feb 28, 2004 at 12:10:29PM -0500, Meng Weng Wong wrote:
> 
> SRS wants to preserve the original sender address in the rewritten
> return-path, because some forwarders place a value on ensuring that the
> original sender receive nondelivery notifications, and I would like to
> accommodate them.  SRS wants to do this securely, so that the reverse
> delivery path does not become an open relay.
...
> This does not meet the first goal of SRS, allowing the original sender
> to receive nondelivery notifications.




So what does this have to do with spam protection?

This is a feature for "some forwarders", to allow them to send back 
the delivery notifications. This does not help in protecting against 
spam. 

This is just to not break those forwarders (pobox?) business model by
RMX/LMAP-like schemes which don't allow arbitrary forwarding anymore
(because spammers would abuse it).

If you want to solve this problem, forget about those weird sender
address rewritings. Do a plain full rewriting of the sender address,
and that's it. In case of any delivery error message which should be
sent to the original sender, you need to keep MessageID/sender in a 
database for about a week. If a delivery report comes in you know
where to send it to.

But don't propose broken protocols just to keep your business running.





> | 
> |   If you don't want to rewrite the envelope, then all we need to do
> |   this much more easier is to just add a header line like
> | 
> | 
> |     RMX: somedomain.com
> | 
> | 
> 
> In these kinds of discussions, I have always found the phrase "all we
> need to do" to be a red flag.  There is no "we" --- there is, instead, a
> diverse set of constituencies, each of which may have strong feelings,
> positive or negative, about any given proposal that requires their
> involvement.  The mice also said "all we have to do is put a bell on the
> cat".


Aha. Instead of telling fables, wouldn't it be better to simply
explain what's wrong with my proposal?








> For example, requiring all forwarders to rewrite the envelope with SRS
> is a burden on the forwarder community (and on the web-generated email
> community), but a tremendous benefit to other LMAP adopters because it
> removes a significant obstacle to the LMAP model.
> 
> Requiring all forwarders to prepend "RMX: somedomain.com" is a burden of
> similar scope though reduced magnitude.


No, because it simply would not require "all forwarders". First of
all, I don't know of any significant number of "forwarders" who would 
have any problem. Second, those forward mechanisms I know would be
happy with either rewriting the sender address plainly or use the 
HELO approach.








> I define sender responsibility as the willingness to accept bounces and
> do the right thing with them.


That's arbitrary. Taking responsibility is a completely different
matter than accepting bounces and doing "the right thing". This is 
a red flag for me, because that's not defined at all. So I believe
this is wrong.

I suspect more and more that this all is just about keeping 
Pobox's business model alive and not to protect against spam. 






> I define author responsibility as making a verifiable assertion that the
> content and authorship of a message belongs to some sort of persistent
> identity.



Again, there's dissent. "I define" is again a red flag for me, because
it is a indicator for arbitrary definitions. 




> I expect to have a formal writeup of SRS soon.  I believe it will be
> useful to all the LMAP/return-path schemes, RMX, DMP, FSV, and SPF.
> 
> It will describe in formal terms the problem(s) we are trying to solve,
> the ways to solve them, the attacks that are possible on those first
> approaches, and the mature approaches that solve those attacks.




It doesn't take a formal description. A readable description in 
plain language is enough. What's the problem, what's the solution, 
and why. 


But I do suspect that this is just to keep the pobox forwarding alive
against anti-spam measures. And now you're desperately trying to find 
a  problem for the alleged "solution". Interesting.




Hadmut