--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;±¤Ö¤Íµø?¡