Mailing List Archive

On Sun, 2004-02-22 at 12:22 -0500, Meng Weng Wong wrote:
> I am trying to move this thread to srs-discuss.

Sorry, I didn't realise such a list existed. Perhaps it should be
documented at http://spf.pobox.com/srs.html ?

Btw, please don't drop me from the recipients when replying to me.

> On Sun, Feb 22, 2004 at 05:09:48PM +0000, David Woodhouse wrote:
> | For example, my implementation (http://www.infradead.org/rpr.html)
> | rewrites to some localpart @rpr.infradead.org, and there's no need for
> | anyone else to perform _further_ rewrites on that sender address because
> | I don't publish SPF records for the rpr.infradead.org domain¹.
>
> That's a clever solution, but I believe that one of the design
> goals of SRS was that it should work in a 100% SPF world. Obviously
> we'll never actually reach 100%, but I, for one, want to publish SPF for
> all my domains, and I want to do SRS. The added complexity reflects
> this requirement.

If you want, you _can_ publish SPF records for your RPR-domain. You
obviously have to accept postmaster@, and you may want to set up SPF
records which restrict the IP addresses from which postmaster@ can
_send_ mail.

But you can still allow the 'SRS0+...' addresses to be sent from any
host, and in fact you could do that even if you _can't_ use a completely
separate domain for it. These addresses can't be faked _anyway_; at
least not practically. Even if you do manage to harvest one it's only
valid for a few days.

It has to be noted that the added complexity of the multi-rewrite and in
particular the shortcut is a clear vulnerability. Admittedly, the
localparts which can be spammed by it are limited -- but it's still a
barrier to adoption of SRS, which in turn is a barrier to adoption of
SPF.

--
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

David Woodhouse <dwmw2@infradead.org> [2004-02-22/17:09]:
> 2. It's pointless rewriting the sender address if the original
> sending domain isn't publishing SPF records.

Wrong, as long as SPF is not the only type of origin filter in use. From
my reply to your message on exim-users:

--snip--
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.
--snap--

With your precondition ``only SPF-enabled domains need rewriting''
violated, the rest of your reasoning is also invalidated. Which is
unfortunate, I would like it the way you propose, but it just does not
work with non-SPF origin filters involved.

Cheers,
Dan

--
Daniel Roethlisberger <daniel@roe.ch>
GnuPG key ID 0x804A06B1 (DSA/ElGamal)

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

On Sun, 22 Feb 2004, David Woodhouse wrote:

> I'm looking at the Feb 12 version of your SRS paper. In §2.7 you pose
> the question 'What do we actually _need_ in order to forward a mail back
> to B yet make sure A never receives a spam?'
>
> What you don't seem to consider is the possibility of forwarding
> unwanted message directly to victim B.
>
> It should be noted that the shortcut scheme _does_ open you up for
> relaying, albeit in a limited fashion. If you receive a mail to...
> SRS1+victim.com+HHH+TT+anywhere.com+user-FBj3rGVNSae0fEd0lbWiZA@public.gmane.org
> ...then surely you'll send it on to...
> SRS0+HHH+TT+anywhere.com+user-4qAlImvV68PQT0dZR+AlfA@public.gmane.org
> ...without performing anything but the most basic syntactic checks or
> maybe checking the timestamp.

You're quite right and quite wrong. At this stage, we don't even check the
timestamp. However, if victim.com is an SRS compliant host, then it will
drop the mail because the hash is invalid, and if it isn't an SRS
compliant host, then that address probably won't exist anyway, so it's a
non-issue. Since the host victim.com will drop the mail either way, this
is simply a very ineffective denial of service, and will probably fail
miserably at that as well.

I think you should reread the sections in the documents which describe the
games played by the various spammers. For an enjoyable introduction to
gaming, I suggest "The Game's Afoot" by Alexander Mehlmann.

> I'm slightly confused as to why we bother with the multi-stage rewriting
> at all. Note first the following two observations:
>
> 1. It's pointless rewriting the sender address if your host was
> a permitted sender for that domain _anyway_.

But we lose nothing by applying SRS, so it makes no difference either way.
We might as well save the complexiy of checking SPF during SRS.

> hence 2. It's pointless rewriting the sender address if the original
> sending domain isn't publishing SPF records.

But we lose nothing, so it doesn't hurt. Why should we tie SRS to SPF? We
gain nothing from doing so. They are independent solutions.

> That being the case, surely it makes sense to use a domain for SRS which
> doesn't have SPF records, so that none of your SRS0+.... addresses will
> even _need_ a second rewrite, and no global convention is required for
> such rewrites.

It it is a general assumption in the case of SRS that any responsible
administrator will publish SPF records. The following assumption is that
any spammer will check for SPF records before attempting to abuse a
domain. There is no point leaving a sitting target just because it allows
us to use a different RPR scheme.

> For example, my implementation (http://www.infradead.org/rpr.html)
> rewrites to some localpart @rpr.infradead.org, and there's no need for
> anyone else to perform _further_ rewrites on that sender address because
> I don't publish SPF records for the rpr.infradead.org domain¹.

You are relying on the fact that there are no SPF records for your rpr
domain. In the indefinite future, it may become so that those domains
which do not publish SPF records are usually spamhausen or being exploited
by such, since any administrator who wishes to protect the image of his
domain will publish SPF records. Other than that assumption, your proposal
seems to differ from SRS only in that it does not explicitly support
multiple hops, and will cause the length of the local-part to increase
well beyond the 64 byte limit, probably at the first hop.

The comments at the bottom of that page need some clear and sincere
justification, rather than just a "proof by divine intervention" or "proof
by hint to the reader". In order to make it fly, you must explain:

* How to use the guarded SRS system as an open relay (not the basic flaw
in the preliminary shortcut system, which is explained in the paper).

* How your proposed RPR system is invulnerable to joe jobs.

* How your proposed RPR system deals with multiple hops.

I would be EXTREMELY interested in these explanations, since this is the
stage when we have to fix all of these problems.

Thanks.

S.

--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/

On Sun, 22 Feb 2004, David Woodhouse wrote:

> Btw, please don't drop me from the recipients when replying to me.
>
> > On Sun, Feb 22, 2004 at 05:09:48PM +0000, David Woodhouse wrote:
> > | For example, my implementation (http://www.infradead.org/rpr.html)
> > | rewrites to some localpart @rpr.infradead.org, and there's no need for
> > | anyone else to perform _further_ rewrites on that sender address because
> > | I don't publish SPF records for the rpr.infradead.org domain¹.
> >
> > That's a clever solution, but I believe that one of the design
> > goals of SRS was that it should work in a 100% SPF world. Obviously
> > we'll never actually reach 100%, but I, for one, want to publish SPF for
> > all my domains, and I want to do SRS. The added complexity reflects
> > this requirement.
>
> If you want, you _can_ publish SPF records for your RPR-domain. You
> obviously have to accept postmaster@, and you may want to set up SPF
> records which restrict the IP addresses from which postmaster@ can
> _send_ mail.

But any other address is still permitted to send from any host (as will
happen in the case of secondary forwarded hops) so we're negating the
protection of SPF here, as long as the spammer doesn't pretend to be
postmaster@.

> But you can still allow the 'SRS0+...' addresses to be sent from any
> host, and in fact you could do that even if you _can't_ use a completely
> separate domain for it. These addresses can't be faked _anyway_; at
> least not practically. Even if you do manage to harvest one it's only
> valid for a few days.

This is deliberate, and negates the early points of your first mail.

> It has to be noted that the added complexity of the multi-rewrite and in
> particular the shortcut is a clear vulnerability. Admittedly, the

Please explain what this vulnerability is and how it is to be exploited.
Complexity does not directly create vulnerability. You must explain this
argument properly, preferably with an example.

> localparts which can be spammed by it are limited -- but it's still a
> barrier to adoption of SRS, which in turn is a barrier to adoption of
> SPF.

Again, please explain the problem "barrier" in more detail. The scheme is
remarkably simple, and for those who cannot manage even that, standard
implementations in Perl and C are given with integration instructions for
several MTAs.

S.

--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.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

spf@anarres.org <spf@anarres.org> [2004-02-22/18:00]:
> > localparts which can be spammed by it are limited -- but it's still
> > a barrier to adoption of SRS, which in turn is a barrier to adoption
> > of SPF.
>
> Again, please explain the problem "barrier" in more detail. The scheme
> is remarkably simple, and for those who cannot manage even that,
> standard implementations in Perl and C are given with integration
> instructions for several MTAs.

He's right on this point. Multi-hop SRS might be simple to you, but you
wrote it. It is not clear however to the majority of people at first
contact with the scheme. And judging from some of the comments on these
mailing lists, there are not a great many people who have actually fully
understood all the possible cases of SRS rewriting in full detail yet
(no offense meant to anybody).

I am not saying SRS or your documentation is bad. I am just saying that
the complexity is there, and if we want SRS to become a standard, it
should be as simple as possible, and where complexity is required, this
complexity should be as easily understandable as humanly possible. Yes,
this can be quite a challenge when writing documentation and website...

Cheers,
Dan


--
Daniel Roethlisberger <daniel@roe.ch>
GnuPG key ID 0x804A06B1 (DSA/ElGamal)

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

On Sun, 2004-02-22 at 18:55 +0100, Daniel Roethlisberger wrote:
> David Woodhouse <dwmw2@infradead.org> [2004-02-22/17:09]:
> > 2. It's pointless rewriting the sender address if the original
> > sending domain isn't publishing SPF records.
>
> Wrong, as long as SPF is not the only type of origin filter in use. From
> my reply to your message on exim-users:

On exim-users you did me the courtesy of Cc'ing me, and in fact you
explicitly _thanked_ me for the courtesy of Cc'ing you in the first
place. :)

> With your precondition ``only SPF-enabled domains need rewriting''
> violated, the rest of your reasoning is also invalidated.

While I accept that argument in the general case, for now I think I'll
leave my scheme in place as-is. Bear in mind that I'm only implementing
SRS because of widespread SPF adoption by people who don't fully
comprehend the forwarding problem. People implementing their _own_
ad-hoc schemes I care about much less; they are evidently thinking for
themselves, and can turn away whatever mail they want.

> Which is unfortunate, I would like it the way you propose, but it just
> does not work with non-SPF origin filters involved.

However, it's still possible to make the ultimate conclusion true, by
simply stating it as a requirement: "Addresses generated by SRS
addresses shall not need further rewriting, because origin filters
should not restrict the addresses from which such mail can be received."

--
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

On Sun, 22 Feb 2004, Daniel Roethlisberger wrote:

> He's right on this point. Multi-hop SRS might be simple to you, but you
> wrote it. It is not clear however to the majority of people at first
> contact with the scheme. And judging from some of the comments on these
> mailing lists, there are not a great many people who have actually fully
> understood all the possible cases of SRS rewriting in full detail yet
> (no offense meant to anybody).
>
> I am not saying SRS or your documentation is bad. I am just saying that

You won't say it (although you have the right), but I will.

The current documentation is (now) bad. It was written for version 0.16,
at which point it was a relative breakthrough, but is no longer up to
snuff. I have had many comments both by email and by telephone from people
who have read it, and it is long overdue a rewrite. The explanations of
the games played by the various spammers would benefit SIGNIFICANTLY from
diagrams, which I will construct and add to the paper.

> the complexity is there, and if we want SRS to become a standard, it
> should be as simple as possible, and where complexity is required, this
> complexity should be as easily understandable as humanly possible. Yes,
> this can be quite a challenge when writing documentation and website...

It is a challenge. I hope to draft a new document from my notes in the
next couple of days. I will appreciate any more comments for the new
version by private mail offlist.

S.

--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.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

David Woodhouse <dwmw2@infradead.org> [2004-02-22/18:17]:
> On Sun, 2004-02-22 at 18:55 +0100, Daniel Roethlisberger wrote:
> > [...] From my reply to your message on exim-users:
>
> On exim-users you did me the courtesy of Cc'ing me, and in fact you
> explicitly _thanked_ me for the courtesy of Cc'ing you in the first
> place. :)

Yes, and I meant it; for I cannot possibly monitor all mailing lists for
things which might interest me :)

Anyway...

> > With your precondition ``only SPF-enabled domains need rewriting''
> > violated, the rest of your reasoning is also invalidated.
>
> While I accept that argument in the general case, for now I think I'll
> leave my scheme in place as-is. Bear in mind that I'm only
> implementing SRS because of widespread SPF adoption by people who
> don't fully comprehend the forwarding problem. People implementing
> their _own_ ad-hoc schemes I care about much less; they are evidently
> thinking for themselves, and can turn away whatever mail they want.

Might work for you; it does not for me. On my semiprivate mailserver
(the one I use for my RPR experiments :) ), I have mostly forwardings,
the majority of which go to GMX with their adhoc origin filter. This
means that I have no way on earth to just ignore that, or my users will
eat me alive.

> However, it's still possible to make the ultimate conclusion true, by
> simply stating it as a requirement: "Addresses generated by SRS
> addresses shall not need further rewriting, because origin filters
> should not restrict the addresses from which such mail can be
> received."

Which would effectively allow spammers to circumvent their origin
filters by sending spam with arbitrarily forged SRS return paths.

Cheers,
Dan

--
Daniel Roethlisberger <daniel@roe.ch>
GnuPG key ID 0x804A06B1 (DSA/ElGamal)

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

On Sun, 2004-02-22 at 19:43 +0100, Daniel Roethlisberger wrote:
> Yes, and I meant it; for I cannot possibly monitor all mailing lists for
> things which might interest me :)

Yet you still didn't reply to me...

> Might work for you; it does not for me. On my semiprivate mailserver
> (the one I use for my RPR experiments :) ), I have mostly forwardings,
> the majority of which go to GMX with their adhoc origin filter. This
> means that I have no way on earth to just ignore that, or my users will
> eat me alive.

Fair enough. For the purpose of this discussion, assume I'm simply
suggesting that you refrain from rewriting addresses which _already_
start with 'SRS0+' then.

> Which would effectively allow spammers to circumvent their origin
> filters by sending spam with arbitrarily forged SRS return paths.

You can't arbitrarily forge them. If the HMAC isn't correct then sender
verification callouts will fail.

--
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

On Sun, 2004-02-22 at 17:56 +0000, Shevek wrote:
> You're quite right and quite wrong. At this stage, we don't even check the
> timestamp. However, if victim.com is an SRS compliant host, then it will
> drop the mail because the hash is invalid, and if it isn't an SRS
> compliant host, then that address probably won't exist anyway, so it's a
> non-issue.

It could go to a catch-all account -- they're quite common. Demon and
Freeserve in the UK both give out whole domains to users rather than
single accounts. Or it could end up on the victim's queue or my queue as
an undeliverable bounce, and require postmaster attention.

> Since the host victim.com will drop the mail either way, this
> is simply a very ineffective denial of service, and will probably fail
> miserably at that as well.

I agree it'll fail miserably as a denial of service attack against 'B'.
Could work well as part of a DoS against _me_ though, when my ISP pulls
the plug due to complaints from all the postmasters to whose domains
I've been forwarding faked bounces.

> I think you should reread the sections in the documents which describe the
> games played by the various spammers. For an enjoyable introduction to
> gaming, I suggest "The Game's Afoot" by Alexander Mehlmann.

I'm more interested in the failure mode where my network provider pulls
the plug on one of my machines, to be honest.

> > I'm slightly confused as to why we bother with the multi-stage rewriting
> > at all. Note first the following two observations:
> >
> > 1. It's pointless rewriting the sender address if your host was
> > a permitted sender for that domain _anyway_.
>
> But we lose nothing by applying SRS, so it makes no difference either way.
> We might as well save the complexiy of checking SPF during SRS.

> > hence 2. It's pointless rewriting the sender address if the original
> > sending domain isn't publishing SPF records.
>
> But we lose nothing, so it doesn't hurt. Why should we tie SRS to SPF? We
> gain nothing from doing so. They are independent solutions.

While they can be technically separated and are in that way independent,
in reality they are very much interdependent. SPF cannot work without
SRS being widely adopted, and SRS exists mainly to solve the problems
introduced by SPF.

> > That being the case, surely it makes sense to use a domain for SRS which
> > doesn't have SPF records, so that none of your SRS0+.... addresses will
> > even _need_ a second rewrite, and no global convention is required for
> > such rewrites.
>
> It it is a general assumption in the case of SRS that any responsible
> administrator will publish SPF records. The following assumption is that
> any spammer will check for SPF records before attempting to abuse a
> domain. There is no point leaving a sitting target just because it allows
> us to use a different RPR scheme.

You can publish SPF records; you just have to use the 'exists' mechanism
to allow 'SRS+*' to come from anywhere. Those addresses are extremely
non-trivial to fake _anyway_ -- sender verification callouts will catch
almost all attempts, except perhaps for addresses harvested in the last
few days.

> > For example, my implementation (http://www.infradead.org/rpr.html)
> > rewrites to some localpart @rpr.infradead.org, and there's no need for
> > anyone else to perform _further_ rewrites on that sender address because
> > I don't publish SPF records for the rpr.infradead.org domain¹.
>
> You are relying on the fact that there are no SPF records for your rpr
> domain. In the indefinite future, it may become so that those domains
> which do not publish SPF records are usually spamhausen or being exploited
> by such, since any administrator who wishes to protect the image of his
> domain will publish SPF records. Other than that assumption, your proposal
> seems to differ from SRS only in that it does not explicitly support
> multiple hops, and will cause the length of the local-part to increase
> well beyond the 64 byte limit, probably at the first hop.

The local-part in my implementation was not what you were referred to.
You are correct in your observations, and I should limit the length of
some fields. In fact, I'll probably move some fields to the domain part
of the address rather than the local-part. That is an orthogonal issue
though.

> The comments at the bottom of that page need some clear and sincere
> justification, rather than just a "proof by divine intervention" or "proof
> by hint to the reader". In order to make it fly, you must explain:

That page is just documentation, and needs no support. But since I'm
using my implementation as an example of why I think SRS can work
without multiple rewrites, I'll answer your questions in this context.

> * How to use the guarded SRS system as an open relay (not the basic flaw
> in the preliminary shortcut system, which is explained in the paper).

1. Send mail to SRS1+victim.com+HHH+TT+anywhere.com+user@forwarder.com
2. Observe forwarder.com send mail to
SRS0+HHH+TT+anywhere.com+user@victim.com.
3. Observe postmaster@victim.com complain to forwarder.com's ISP.
4. Observe forwarder.com summarily removed from network.

> * How your proposed RPR system is invulnerable to joe jobs.

Que? You mean the possibility of forging the SRS0+... addresses, given
that the domain we use for them has '+all' SPF records? Sender
verification callouts will always fail for arbitrarily invented
addresses at that domain.

> * How your proposed RPR system deals with multiple hops.

The second hop doesn't need to do anything. The original SRS-address
works as-is when the second hop forwards the mail, because there are no
restrictions on the IP addresses which can send from those addresses.

--
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

On Sun, 22 Feb 2004, David Woodhouse wrote:

> On Sun, 2004-02-22 at 17:56 +0000, Shevek wrote:
> > You're quite right and quite wrong. At this stage, we don't even check the
> > timestamp. However, if victim.com is an SRS compliant host, then it will
> > drop the mail because the hash is invalid, and if it isn't an SRS
> > compliant host, then that address probably won't exist anyway, so it's a
> > non-issue.
>
> > Since the host victim.com will drop the mail either way, this
> > is simply a very ineffective denial of service, and will probably fail
> > miserably at that as well.
>
> I agree it'll fail miserably as a denial of service attack against 'B'.
> Could work well as part of a DoS against _me_ though, when my ISP pulls
> the plug due to complaints from all the postmasters to whose domains
> I've been forwarding faked bounces.

As far as we know, such faked bounces can't exist. You haven't yet
justified the possible existence of such faked bounces with any form of
example. You must do so before I can understand your argument.

> > The comments at the bottom of that page need some clear and sincere
> > justification, rather than just a "proof by divine intervention" or "proof
> > by hint to the reader". In order to make it fly, you must explain:
>
> That page is just documentation, and needs no support. But since I'm
> using my implementation as an example of why I think SRS can work
> without multiple rewrites, I'll answer your questions in this context.
>
> > * How to use the guarded SRS system as an open relay (not the basic flaw
> > in the preliminary shortcut system, which is explained in the paper).
>
> 1. Send mail to SRS1+victim.com+HHH+TT+anywhere.com+user@forwarder.com
> 2. Observe forwarder.com send mail to
> SRS0+HHH+TT+anywhere.com+user@victim.com.
> 3. Observe postmaster@victim.com complain to forwarder.com's ISP.

No. Observe victim.com silently drop the mail in the bit bucket because of
an invalid hash. Postmaster never sees it, and doesn't care.

Unless you have also identified a weakness in the HMAC/SHA1-based
cryptographic mechanism proposed, this argument does not stand.

> 4. Observe forwarder.com summarily removed from network.
>
> > * How your proposed RPR system is invulnerable to joe jobs.
>
> Que? You mean the possibility of forging the SRS0+... addresses, given
> that the domain we use for them has '+all' SPF records? Sender
> verification callouts will always fail for arbitrarily invented
> addresses at that domain.

You have referred to "sender verification callouts" several times. This
mechanism needs explanation.

> > * How your proposed RPR system deals with multiple hops.
>
> The second hop doesn't need to do anything. The original SRS-address

You are now relying on the fact that all secondary hops implement
precisely your proposed RPR mechanism. SRS does not require that secondary
hops implement SRS. They may implement any SPF-compliant rewriting
mechanism they please. This is deliberate.

> works as-is when the second hop forwards the mail, because there are no
> restrictions on the IP addresses which can send from those addresses.

Thank you for your explanations. I hope this helps.

S.

--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.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

David Woodhouse <dwmw2@infradead.org> [2004-02-22/18:56]:
> On Sun, 2004-02-22 at 19:43 +0100, Daniel Roethlisberger wrote:
> > Yes, and I meant it; for I cannot possibly monitor all mailing lists for
> > things which might interest me :)
>
> Yet you still didn't reply to me...

Yes, I do not normally copy the person who wrote the message on lists
where I can safely assume the sender is subscribed to. I copied you on
my exim-users resonse solely because I used my MUA's group reply instead
of list reply, as I wanted to make sure that Martin Treusch von Buttlar
gets a copy too. I could have pruned your name from the list.

> For the purpose of this discussion, assume I'm simply suggesting that
> you refrain from rewriting addresses which _already_ start with
> 'SRS0+' then.

Will not work, as providers doing their own origin verification might
not accept mail from my server carrying an envelope return path of say
SRS0+(...)@rpr.aol.com

> > Which would effectively allow spammers to circumvent their origin
> > filters by sending spam with arbitrarily forged SRS return paths.
>
> You can't arbitrarily forge them. If the HMAC isn't correct then
> sender verification callouts will fail.

True, but we cannot assume everybody uses callback verifications, much
less can we mandate callback verification in a scheme such as SRS. Large
sites cannot afford the overhead of doing active SMTP callbacks on every
incoming message.

Cheers,
Dan


--
Daniel Roethlisberger <daniel@roe.ch>
GnuPG key ID 0x804A06B1 (DSA/ElGamal)

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

On Sun, 2004-02-22 at 18:00 +0000, spf@anarres.org wrote:
> On Sun, 22 Feb 2004, David Woodhouse wrote:
> > Btw, please don't drop me from the recipients when replying to me.

Pretty please?

> > If you want, you _can_ publish SPF records for your RPR-domain. You
> > obviously have to accept postmaster@, and you may want to set up SPF
> > records which restrict the IP addresses from which postmaster@ can
> > _send_ mail.
>
> But any other address is still permitted to send from any host (as will
> happen in the case of secondary forwarded hops) so we're negating the
> protection of SPF here, as long as the spammer doesn't pretend to be
> postmaster@.

You don't need to SPF-protect these addresses. They're virtually
impossible to fake _anyway_ so nobody would accept them.

> > But you can still allow the 'SRS0+...' addresses to be sent from any
> > host, and in fact you could do that even if you _can't_ use a completely
> > separate domain for it. These addresses can't be faked _anyway_; at
> > least not practically. Even if you do manage to harvest one it's only
> > valid for a few days.
>
> This is deliberate, and negates the early points of your first mail.

Forgive me; it's not clear which points are negated by this.

> Please explain what this vulnerability is and how it is to be exploited.
> Complexity does not directly create vulnerability. You must explain this
> argument properly, preferably with an example.

I think I've done so in a separate mail.

> Again, please explain the problem "barrier" in more detail. The scheme is
> remarkably simple, and for those who cannot manage even that, standard
> implementations in Perl and C are given with integration instructions for
> several MTAs.

I mean it came very close to preventing me from implementing any form of
SRS, when I saw that the 'officially' advocated form of SRS had a clear
loophole which could cause me problems.

That's what I mean by 'barrier to adoption'.

--
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

Daniel Roethlisberger <daniel@roe.ch> [2004-02-22/20:10]:
> > > Which would effectively allow spammers to circumvent their origin
> > > filters by sending spam with arbitrarily forged SRS return paths.
> >
> > You can't arbitrarily forge them. If the HMAC isn't correct then
> > sender verification callouts will fail.
>
> True, but we cannot assume everybody uses callback verifications, much
> less can we mandate callback verification in a scheme such as SRS.
> Large sites cannot afford the overhead of doing active SMTP callbacks
> on every incoming message.

Another detail to note is that callback verification on rewritten
addresses normally does not work, so you cannot assume that sender
callback will fail for illegal rewritten addresses. Just because your
RPR implementation refuses to accept illegal bounce messages at SMTP
time, not everyone's does.

It is my opinion that illegal bounces (checksum mismatch, etc) should
either be forwarded to postmaster, saved to some local failed bounces
mailbox, or be silently discarded. There should be no way for attackers
to verify a rewritten address; if your MTA refuses to accept mail for an
illegal rewritten address, attackers have a way to brute force valid
cookies.

Cheers,
Dan


--
Daniel Roethlisberger <daniel@roe.ch>
GnuPG key ID 0x804A06B1 (DSA/ElGamal)

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

On Sun, 2004-02-22 at 19:10 +0000, spf@anarres.org wrote:
> As far as we know, such faked bounces can't exist. You haven't yet
> justified the possible existence of such faked bounces with any form of
> example. You must do so before I can understand your argument.

I've done so.

> > 1. Send mail to SRS1+victim.com+HHH+TT+anywhere.com+user@forwarder.com
> > 2. Observe forwarder.com send mail to
> > SRS0+HHH+TT+anywhere.com+user@victim.com.
> > 3. Observe postmaster@victim.com complain to forwarder.com's ISP.
>
> No. Observe victim.com silently drop the mail in the bit bucket because of
> an invalid hash. Postmaster never sees it, and doesn't care.

But victim.com knows nothing of SRS. Perhaps victim.com is actually
victim.demon.co.uk, a Windows user running Demon's own mail software
which just receives everything into a single catchall account.

> > 4. Observe forwarder.com summarily removed from network.

> You have referred to "sender verification callouts" several times. This
> mechanism needs explanation.

I sincerely hope you're asking that for the benefit of the peanut
gallery and not for your own information.

By 'sender verification callouts', of course I refer to the mechanism
whereby you make an SMTP connection to an advertised MX host of the
sender address, and verify that it would accept bounces to that address
should such become necessary. This is the mechanism which in my
experience cuts out the majority of joe-jobs with fake local-parts,
without any special configuration on the part of the joe-jobbee.

See http://www.exim.org/exim-html-4.30/doc/html/spec_38.html#IX2303 for
more details, including details of caching and callout avoidance for
hosts which accept _everything_.

> > > * How your proposed RPR system deals with multiple hops.
> >
> > The second hop doesn't need to do anything. The original SRS-address
>
> You are now relying on the fact that all secondary hops implement
> precisely your proposed RPR mechanism.

Why do you believe this to be the case? I rely on nothing from secondary
hops. They can implement SRS or not, as they see fit. I require that
they make no assumptions about me. That is reasonable.

> SRS does not require that secondary hops implement SRS. They may implement
> any SPF-compliant rewriting mechanism they please. This is deliberate.

That statement is incompatible with the existence of the 'shortcut'
mechanism. Without your convention the shortcuts cannot work, surely?

--
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

On Sun, 2004-02-22 at 20:10 +0100, Daniel Roethlisberger wrote:
> > For the purpose of this discussion, assume I'm simply suggesting that
> > you refrain from rewriting addresses which _already_ start with
> > 'SRS0+' then.
>
> Will not work, as providers doing their own origin verification might
> not accept mail from my server carrying an envelope return path of say
> SRS0+(...)@rpr.aol.com

To clarify -- your server would use your domain for its rewritten
addresses; the situation above would happen only if AOL implements SRS
using that as its domain for the bounces.

So for that to bounce, GMX (or whoever) would have to have observed this
SRS behaviour on the part of AOL, then explicitly listed _that_ domain
in their database, deciding against all the evidence that it's permitted
to send mail only from some arbitrary range of addresses not including
yours.

That would just be broken. You cannot prevent the administrators of
ad-hoc schemes from putting insane entries in their database, but if you
clearly document that SRS shall use addresses which do _not_ need
subsequent rewriting then at least you can reasonably expect this not to
happen.

> > You can't arbitrarily forge them. If the HMAC isn't correct then
> > sender verification callouts will fail.
>
> True, but we cannot assume everybody uses callback verifications, much
> less can we mandate callback verification in a scheme such as SRS. Large
> sites cannot afford the overhead of doing active SMTP callbacks on every
> incoming message.

Come now. You are willing to assume that the _whole_ world is going to
implement SRS to help those who want to publish SPF records or use SPF
work around its fundamental limitations -- but you're not willing to
accept that some problems are solved by a mechanism _other_ than SPF?
You're not willing to assume that those sites who care enough about spam
to implement the arbitrarily complex SPF lookup stuff aren't also going
to do sender verification callouts?

If there are hosts which do SPF but _don't_ do sender verification, the
situation is not really any different from the current status quo.
They'll accept the bogus address, and may end up bouncing to an invalid
user -- but at least that invalid user really _is_ invalid and won't
cause collateral spam.

--
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

----- Original Message -----
From: <spf@anarres.org>
To: "David Woodhouse" <dwmw2@infradead.org>
Cc: "SRS discussions" <srs-discuss@v2.listbox.com>
Sent: Sunday, February 22, 2004 8:10 PM
Subject: [srs-discuss] Re: Sender Rewriting Scheme and open relays.

> > > * How to use the guarded SRS system as an open relay (not the basic
> > > flaw in the preliminary shortcut system, which is explained in the
> > > paper).
> >
> > 1. Send mail to SRS1+victim.com+HHH+TT+anywhere.com+user@forwarder.com
> > 2. Observe forwarder.com send mail to
> > SRS0+HHH+TT+anywhere.com+user@victim.com.
> > 3. Observe postmaster@victim.com complain to forwarder.com's ISP.
>
> No. Observe victim.com silently drop the mail in the bit bucket because of
> an invalid hash. Postmaster never sees it, and doesn't care.

True. As an invalid RCPT TO recipient, the SMTP transaction would simply
return "550 5.1.1", as it would for any other non-existent recipient. I
would have quite a busy day if all "Unknown user" errors went to postmaster.
:) And invalid recipient is simply invalid, regardless of SRS.

> > Que? You mean the possibility of forging the SRS0+... addresses, given
> > that the domain we use for them has '+all' SPF records? Sender
> > verification callouts will always fail for arbitrarily invented
> > addresses at that domain.

Well, yeah. :) David, did you expect anything else?

Cheers,

- 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

On Sun, 2004-02-22 at 20:29 +0100, Daniel Roethlisberger wrote:
> Another detail to note is that callback verification on rewritten
> addresses normally does not work, so you cannot assume that sender
> callback will fail for illegal rewritten addresses. Just because your
> RPR implementation refuses to accept illegal bounce messages at SMTP
> time, not everyone's does.

Anyone accepting mail to invalid addresses gets to decide what to do
with it. You _will_ end up with people trying to send valid mail to
these addresses; you can't just blackhole it, and you shouldn't bounce
it because that just causes collateral spam.

Anyone not rejecting mail to invalid addresses at SMTP time is part of
the problem, not part of the solution; they're unlikely to be
implementing SRS in the general case.

> It is my opinion that illegal bounces (checksum mismatch, etc) should
> either be forwarded to postmaster, saved to some local failed bounces
> mailbox, or be silently discarded. There should be no way for attackers
> to verify a rewritten address; if your MTA refuses to accept mail for an
> illegal rewritten address, attackers have a way to brute force valid
> cookies.

I strongly disagree -- it's harmless to let them try. There are _far_
better things they can do other than attempting to obtain, by brute
force, a forwarding address which will be valid for less time than it
took them to obtain it.

(Note to self: Don't accept timestamps which expire more than a week
into the future, and hence are obviously not valid)

We should stick the the principle that we should reject as much as
possible at SMTP time, and not ever accept mail which we later
blackhole. A catch-all account as you suggest is either a blackhole or a
drain on postmaster resources.

--
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

On Sun, 22 Feb 2004, David Woodhouse wrote:

> On Sun, 2004-02-22 at 18:00 +0000, spf@anarres.org wrote:
>
> > Please explain what this vulnerability is and how it is to be exploited.
> > Complexity does not directly create vulnerability. You must explain this
> > argument properly, preferably with an example.
>
> I think I've done so in a separate mail.

I have negated the vulnerability in a reply to that separate mail. This
referring to a cross-thread is confusing me. I hope that we can kill this
branch with the references below.

> > Again, please explain the problem "barrier" in more detail. The scheme is
> > remarkably simple, and for those who cannot manage even that, standard
> > implementations in Perl and C are given with integration instructions for
> > several MTAs.
>
> I mean it came very close to preventing me from implementing any form of
> SRS, when I saw that the 'officially' advocated form of SRS had a clear
> loophole which could cause me problems.
>
> That's what I mean by 'barrier to adoption'.

As far as we can see, this loophole is invalid. Your explanation (id
1077476456.11584.134.camel@imladris.demon.co.uk) is argued to be invalid
in my reply (id Pine.LNX.4.53.0402221905180.13192@astray.com).

S.

--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.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

On Sun, 2004-02-22 at 20:31 +0000, spf@anarres.org wrote:
> I have negated the vulnerability in a reply to that separate mail. This
> referring to a cross-thread is confusing me.

Such is wont to happen if you don't do me the courtesy of Ccing me.

--
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

----- Original Message -----
From: "Daniel Roethlisberger" <daniel@roe.ch>
To: <srs-discuss@v2.listbox.com>
Sent: Sunday, February 22, 2004 8:29 PM
Subject: Re: [srs-discuss] Re: [spf-discuss] Sender Rewriting Scheme and
open relays.

> It is my opinion that illegal bounces (checksum mismatch, etc) should
> either be forwarded to postmaster, saved to some local failed bounces
> mailbox, or be silently discarded. There should be no way for attackers
> to verify a rewritten address; if your MTA refuses to accept mail for an
> illegal rewritten address, attackers have a way to brute force valid
> cookies.

I'm sorry, but that logic does not compute with me.

Forget SRS for a moment, and reread what you just said. Should an MTA not be
allowed to distinguish between a valid and invalid recipient? And is my
bouncing invalid users giving spammers "a way to brute force valid cookies"?
No more so than them trying to brute force their way into finding other
valid users on the system: notoriously the most ineffective way to try and
send spam. :)

In fact, I strongly feel you always *SHOULD* reject invalid recipients. I
consider "catchall" accounts a misconfiguration.

Cheers,

- 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

On Sun, 2004-02-22 at 20:31 +0000, spf@anarres.org wrote:
> As far as we can see, this loophole is invalid. Your explanation (id
> 1077476456.11584.134.camel@imladris.demon.co.uk) is argued to be invalid
> in my reply (id Pine.LNX.4.53.0402221905180.13192@astray.com).

You seem to have missed 077479276.11584.205.camel@imladris.demon.co.uk

--
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

David Woodhouse <dwmw2@infradead.org> [2004-02-22/19:52]:
> On Sun, 2004-02-22 at 20:10 +0100, Daniel Roethlisberger wrote:
> > > For the purpose of this discussion, assume I'm simply suggesting that
> > > you refrain from rewriting addresses which _already_ start with
> > > 'SRS0+' then.
> >
> > Will not work, as providers doing their own origin verification might
> > not accept mail from my server carrying an envelope return path of say
> > SRS0+(...)@rpr.aol.com
>
> To clarify -- your server would use your domain for its rewritten
> addresses; the situation above would happen only if AOL implements SRS
> using that as its domain for the bounces.
>
> So for that to bounce, GMX (or whoever) would have to have observed this
> SRS behaviour on the part of AOL, then explicitly listed _that_ domain
> in their database, deciding against all the evidence that it's permitted
> to send mail only from some arbitrary range of addresses not including
> yours.
>
> That would just be broken.

Why is that just broken? They decide that they only want mail from AOL
from AOL mailservers, and that's the end of it. They don't know or care
about SRS nor SPF. This is the current situation, by the way.

Yes, this does break forwarding. Just as SPF does. But other than that,
it is a very effective means of killing spam with faked envelope return
paths. Which is why they do it.


> > > You can't arbitrarily forge them. If the HMAC isn't correct then
> > > sender verification callouts will fail.
> >
> > True, but we cannot assume everybody uses callback verifications,
> > much less can we mandate callback verification in a scheme such as
> > SRS. Large sites cannot afford the overhead of doing active SMTP
> > callbacks on every incoming message.
>
> Come now. You are willing to assume that the _whole_ world is going to
> implement SRS to help those who want to publish SPF records or use SPF
> work around its fundamental limitations -- but you're not willing to
> accept that some problems are solved by a mechanism _other_ than SPF?

SRS will get adopted because people want their messages to get through,
not only through SPF checks, but also through other origin verification,
and only ever sending things with a local return path seems generally
like a good idea, so people might accept it eventually.

> You're not willing to assume that those sites who care enough about
> spam to implement the arbitrarily complex SPF lookup stuff aren't also
> going to do sender verification callouts?

Firstly, callbacks seem to be significantly more expensive than SPF.
Secondly, callbacks always succeed (well, should!) on SRS addresses.
And thirdly, I am not willing to make SRS dependant on the requirement
that everybody who does SPF or some other form of origin verification
must also do callback verification on SRS addresses. In fact, I am not
willing to have SRS require SPF or vice versa, and I am not willing to
have either of them *require* expensive checks like callbacks. Such
requirements will make either of them far less likely to get adopted.

> If there are hosts which do SPF but _don't_ do sender verification,
> the situation is not really any different from the current status quo.

Exactly, and that's not what they are trying to achieve by adopting SPF,
is it? SPF would be almost worthless without callbacks. Not totally
worthless, but easily circumvented.

Cheers,
Dan


--
Daniel Roethlisberger <daniel@roe.ch>
GnuPG key ID 0x804A06B1 (DSA/ElGamal)

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

On Sun, 22 Feb 2004, David Woodhouse wrote:

> On Sun, 2004-02-22 at 20:31 +0000, spf@anarres.org wrote:
> > I have negated the vulnerability in a reply to that separate mail. This
> > referring to a cross-thread is confusing me.
>
> Such is wont to happen if you don't do me the courtesy of Ccing me.

Given your strong interest in SRS and RPR, and given the volume of posts
containing cross referenced arguments which you have offered this list, it
should be comparatively little effort for you to do us the courtesy of
joining the list. I recommend that you do so, since it has little traffic
over and above your questions and the responses thereto.

Furthermore, I recommend that you write a web page or paper clearly
documenting the issues you have to raise so that it may be viewed in a
central referencable location. This would make it much easier to respond
to your questions.

Henceforth, I think it will be fair for me to post only to the list. You
may see my responses by subscribing to the list or the digest, or by
reading the archive.

S.

--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.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