--
David Woodhouse <dwmw2@???> [2004-02-22/16:14]:
> The version which I've actually rolled out is at
> http://www.infradead.org/rpr.html and looks like this...
Thanks for copying me.
Your ``only rewrite for SPF-enabled domains'' has one flaw: SPF is not
the only origin verification scheme in use today. Many large ISPs have
their own form of origin verification in place. GMX.net, *the* major
Freemail provider in .{de,at,ch,li} had such a filter for quite some
time now, and I am told that other providers have such filters too.
These filters work without SPF records, so your rewriting will not help
recipients at providers with their own native non-SPF origin filters,
which is the main reason why I started to think about RPR schemes. SPF
entered the picture later.
I think the right thing to do is rewrite everything with nonlocal
receipient and nonlocal sender addresses, with the effect of only ever
sending things with local return paths.
In your earlier post, you asked two questions, and I think I might be
able to answer them to some degree.
> Out of interest, why the thing with the domains:
> ${if eq {$domain}{$original_domain}\
> {%$original_domain@$primary_hostname}\
> {@$original_domain}}
In the first version of my scheme, I've included the local receipient
(in case of forwarding), or the full receipient of the message (in case
of locally generated messages with nonlocal senders, such as generated
by local convenience forgery or authenticated relay). The reason for
this was that I originally wanted to know who had received a given
rewritten return path address, with tracking down abuse in mind.
Thus I needed to check whether the message was forwarded (ie. current
domain is different from original domain), and include the correct
things in the rewritten address in each case.
Later, I decided that this is a waste of space, as I can sufficiently
track down the message by time and sender, so I got rid of this field
entirely. This was a great help towards trying to stay below the 64/256
char minimum supported local part / return path length guaranteed by RFC
2821, even with multiple RPR hops (this is where Shevek's latest SRS
schemes really do have the advantage of bounded length return paths).
Removing this field also made all the escaping unnecessary:
> Also, you don't seem to be doing much quoting... how does it fare with
> addresses such as 'one-two=th$r\ee#fo\\ur##fi}v\e%six\@_seven@???'?
Depending on the scheme, you don't need to quote anything specially, as
the address is unambigously parseable in any case, even in the multi-hop
different RPR schemes (`babuschka') case.
HTH,
Dan
--
Daniel Roethlisberger <daniel@???>
GnuPG key ID 0x804A06B1 (DSA/ElGamal)
--
[ Content of type application/pgp-signature deleted ]
--
