Mailing List Archive

Cascaded Rewriting
Hello,

I am planning to use libsrs2 for our mail system. It will replace our own
rewriting scheme.
My question is, what happens if cascaded encoding appears using srs.
In particular, is it possible to feed an address into srs_reverse, it is
properly decoded, but still encoded (by SRS means)? Double encoding. Is that
possible with SRS? Will the decoded sender address be definitely valid when
no error occured or do I have to check afterwards in case I might have to do
it again.

I don't know if I horribly misunderstood something here but in our old scheme
this was possible so I just want to know.

Greetings...

Stephan

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
RE: Cascaded Rewriting [ In reply to ]
> -----Original Message-----
> From: owner-srs-discuss@v2.listbox.com
> [mailto:owner-srs-discuss@v2.listbox.com] On Behalf Of Stephan Menzel
> Sent: dinsdag 12 april 2005 16:41
> To: srs-discuss@v2.listbox.com
> Subject: [srs-discuss] Cascaded Rewriting
>
> Hello,
>
> I am planning to use libsrs2 for our mail system. It will
> replace our own rewriting scheme.
> My question is, what happens if cascaded encoding appears using srs.
> In particular, is it possible to feed an address into srs_reverse,
> it is properly decoded, but still encoded (by SRS means)? Double
> encoding. Is that possible with SRS?

When you re-code an existing SRS0 address, you essentially promote it to
an SRS1 address. This address can be reversed by srs_reverse. Whether you
can reverse the ensuing SRS0 address depends, of course, on whether you
signed it yourself (or have the key).

> Will the decoded sender address be definitely valid when no error occured
> or do I have to check afterwards in case I might have to do
> it again.

The result of srs_reverse may be an SRS0 address itself. So, yes, if you
want to reverse that too, a second pass would be required. Since there is
no promoting SRS1 addresses to SRS2, etc, every reversal step should take
a two-pass maximum.

N.B. This all refers to the default "Guarded" scheme.

- Mark

System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Cascaded Rewriting [ In reply to ]
Am Dienstag, 12. April 2005 16:53 schrieb Mark:
> When you re-code an existing SRS0 address, you essentially promote it to
> an SRS1 address. This address can be reversed by srs_reverse. Whether you
> can reverse the ensuing SRS0 address depends, of course, on whether you
> signed it yourself (or have the key).

Well, I can safely assume that.

> The result of srs_reverse may be an SRS0 address itself. So, yes, if you
> want to reverse that too, a second pass would be required. Since there is
> no promoting SRS1 addresses to SRS2, etc, every reversal step should take
> a two-pass maximum.

OK. So it'll be best If I always do two passes to cover all those cases.
Thanks a lot!

Stephan

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Cascaded Rewriting [ In reply to ]
On Tue, 2005-04-12 at 17:06 +0200, Stephan Menzel wrote:
> Am Dienstag, 12. April 2005 16:53 schrieb Mark:
> > When you re-code an existing SRS0 address, you essentially promote it to
> > an SRS1 address. This address can be reversed by srs_reverse. Whether you
> > can reverse the ensuing SRS0 address depends, of course, on whether you
> > signed it yourself (or have the key).
>
> Well, I can safely assume that.
>
> > The result of srs_reverse may be an SRS0 address itself. So, yes, if you
> > want to reverse that too, a second pass would be required. Since there is
> > no promoting SRS1 addresses to SRS2, etc, every reversal step should take
> > a two-pass maximum.
>
> OK. So it'll be best If I always do two passes to cover all those cases.
> Thanks a lot!

You would do best to read the paper at
http://www.libsrs2.org/srs/srs.pdf, since this explains the how, the why
and the wherefore of multiple rewriting. You should not be doing
multiple passes unless you simply want to know the source address for
logging purposes. I suspect you might misunderstand something?

S.

--
Shevek <shevek@anarres.org>

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
RE: Cascaded Rewriting [ In reply to ]
> -----Original Message-----
> From: owner-srs-discuss@v2.listbox.com
> [mailto:owner-srs-discuss@v2.listbox.com] On Behalf Of Shevek
> Sent: woensdag 13 april 2005 1:02
> To: srs-discuss@v2.listbox.com
> Subject: Re: [srs-discuss] Cascaded Rewriting
>
>
> On Tue, 2005-04-12 at 17:06 +0200, Stephan Menzel wrote:

> > Am Dienstag, 12. April 2005 16:53 schrieb Mark:

> > > When you re-code an existing SRS0 address, you
> > > essentially promote it to an SRS1 address. This address can
> > > be reversed by srs_reverse. Whether you can reverse the
> > > ensuing SRS0 address depends, of course, on whether you
> > > signed it yourself (or have the key).
> >
> > Well, I can safely assume that.
> >
> > > The result of srs_reverse may be an SRS0 address itself.
> > > So, yes, if you want to reverse that too, a second pass would be
> > > required. Since there is no promoting SRS1 addresses to SRS2,
> > > etc, every reversal step should take a two-pass maximum.
> >
> > OK. So it'll be best If I always do two passes to cover all
> > those cases. Thanks a lot!
>
> You would do best to read the paper at
> http://www.libsrs2.org/srs/srs.pdf, since this explains the
> how, the why and the wherefore of multiple rewriting.

I suspect he is worried that, within his internal network, from mailer to
mailer, things might get signed twice, or more. The 'cleanest' solution
for those cases, actually, is simply not to re-sign addresses to begin
with for anything which is, say, in class w (as I do in my srs-socketmap
approach), so that you only produce one single SRS0 address. Otherwise,
like the OP, you will need to check for possible SRS1 addresses on
the return.

- Mark

System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
RE: Cascaded Rewriting [ In reply to ]
On Wed, 2005-04-13 at 07:20 +0000, Mark wrote:
> I suspect he is worried that, within his internal network, from mailer
> to mailer, things might get signed twice, or more.

This is what happens when you rewrite addresses _even_ when they don't
need rewriting. Instead, you could rewrite _only_ when the mail would
get an SPF 'fail' result, and then the next hop is known to reject for
that failure.

--
dwmw2


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Cascaded Rewriting [ In reply to ]
Am Mittwoch, 13. April 2005 10:14 schrieb David Woodhouse:
> This is what happens when you rewrite addresses _even_ when they don't
> need rewriting. Instead, you could rewrite _only_ when the mail would
> get an SPF 'fail' result, and then the next hop is known to reject for
> that failure.

Does that mean, one would have to do that check every time one would rewrite
an adress? Seems quite expensive to me. Certainly not an option for us here.

Greetings...

Stephan

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Cascaded Rewriting [ In reply to ]
Am Mittwoch, 13. April 2005 01:01 schrieb Shevek:
> You would do best to read the paper at
> http://www.libsrs2.org/srs/srs.pdf, since this explains the how, the why
> and the wherefore of multiple rewriting. You should not be doing
> multiple passes unless you simply want to know the source address for
> logging purposes. I suspect you might misunderstand something?

Well, that paper was the first thing I did before I went to do the job. But I
have to admit, I found it rather hard to understand. (No offence meant, of
course, but you might have gone deeper into the difference between SRS0 and
SRS1) But I think I'm getting into it now.
If I would indeed always do multiple passes, I wouldn't be able to deliver
those mails since the resulting address wouldn't be our's anymore (the users
forwarding address in our system) but the address at the host from where that
mail has been forwarded to us, right?
So one pass is it.

Greetings...

Stephan

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Cascaded Rewriting [ In reply to ]
On Wed, 2005-04-13 at 10:19 +0200, Stephan Menzel wrote:
> Am Mittwoch, 13. April 2005 10:14 schrieb David Woodhouse:
> > This is what happens when you rewrite addresses _even_ when they don't
> > need rewriting. Instead, you could rewrite _only_ when the mail would
> > get an SPF 'fail' result, and then the next hop is known to reject for
> > that failure.
>
> Does that mean, one would have to do that check every time one would rewrite
> an adress? Seems quite expensive to me. Certainly not an option for us here.

Well, you very rarely have to perform an SPF check. As Mark pointed out,
such a check should be equivalent to checking that the sender domain is
in class w, or accept_domains, or whatever your MTA's equivalent is. SPF
is approximately a way to advertise your MTA's intended accept_domains
via the DNS. (Not totally accurate, but near enough for government
work.)

Thus the check can be performed entirely locally and very fast.

S.

--
Shevek <shevek@anarres.org>

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com