spf-discuss
[Top] [All Lists]

Re: Solving the Forwarding Problem by Implementing SRS in Postfix

2004-01-12 00:52:40
--Meng Weng Wong <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com> wrote:

Note: I would prefer spf-discuss to focus on the challenge of adoption.
If you can help implement sender rewriting in an MTA, please join the
spf-devel list.


I'm replying here because these are not really "how to implement" but more policy questions.

I have a semi-related question. Using SRS, is it possible to "fake" a bounce, to cause the forwarder to think it's a bounce from something it sent, when in reality the spammer is using the forwarding system to relay to anyone and everyone? Or is that what the cookie is all about?

In terms of cookies, you could either a. keep track of outgoing cookies used, or b. use a hash of the address-before-rewriting plus a "secret" so that you can check the validity of the cookie without storing all cookies given out so far. The hash approach is probably better for sites that have multiple forwarding servers and don't want to store cookies in a database.


Second, a comment on SRS and forwarding policy:

Victor(_dot_)Duchovni(_at_)morganstanley(_dot_)com wrote:
| Growth in the sender address along the forwarding path can get quite
| unreasonable, but once all the sites along the path use SRS cookies the
| address cannot be trimmed without saving state and introducing a central
| data store for cooperating MX hosts. If there was a *standard* SRS
| encoding acceptable to all, one could save just the previous hop's cookie,
| this is not likely to happen any time soon and imposes unreasonable
| constraints on the structure of the *local* part of the address whose
| semantics have always been *local*.


I'm not sure if the return path really needs to grow arbitrarily long. Really the *main* reason for rewriting the envelope sender is so that the forwarded message can be acceptable to SPF checkers independent of the sender's domain (since the sender doesn't know his mail is being forwarded, and there are many senders).

Here is what I am thinking. Take an example of a message forwarded twice. (copied from spf site)

Original message: from <joe(_at_)aol(_dot_)com> to <bob(_at_)pobox(_dot_)com>
Forwarded once:   from <bounce-joe#aol(_dot_)com-bob(_at_)pobox(_dot_)com> to 
<srs(_at_)mail(_dot_)com>
Forward again: from <bounce-joe#aol(_dot_)com-bob#pobox(_dot_)com-srs(_at_)mail(_dot_)com> to <oops(_at_)yahoo(_dot_)com>
Or it could be:   from <bounce-joe#aol(_dot_)com-srs(_at_)mail(_dot_)com> to 
<oops(_at_)yahoo(_dot_)com>

This is part of the original SRS proposal and I think the idea is a good one... any site that uses SRS should be able to recognize addresses that have already been through SRS once and simplify the path -- that is, any bounce can go directly back to the original sender, it doesn't need to completely reverse the chain of how it was forwarded.

This is closer to how bounces work now, so we're not really losing anything by doing this. Right now messages get forwarded multiple times without rewriting and bounces just go directly back to the original sender.

However, on the other hand, from a pragmatic view it's probably easier to implement SRS if you leave the entire original sender alone and not try to analyze whether it was also an SRS address. For this method you would replace the @ with #, and add -cookie(_at_)bounce(_dot_)forwarder(_dot_)com" on the end. Incoming messages from <> to bounce.forwarder.com would check cookie and reverse the process. Probably shortening the path would take extra work on the forwarding side.

So... how long can a return path be, and how many forwards do most people expect to have? Is it worth the effort of trimming the previous SRS info back?

-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡