> [David Woodhouse]
> On Mon, 2004-02-23 at 19:49 -0600, Seth Goodman wrote:
> > According to current practice, yes. I'm proposing breaking that in
> > order to limit relaying abuse in an SRS system. The
> proposal is to send
> > the DSN through the same path the message came in on. No other path
> > would accept the DSN. I know that's hard to swallow. So
> is the present
> > state of affairs.
>
> It _is_ hard to swallow. Too hard -- if you go down this path
> you might
> as well just admit that your Brave New World is completely
> incompatible
> with the status quo, and join the ranks of all the other crackpots who
> want to convert completely to a new system.
The proposal I made may well be too far from present practice to be
acceptable, as I myself stated in the next few sentences of that post.
That doesn't change the fact that SMTP is broken. Looking for a
solution to a broken protocol doesn't make someone a crackpot. We're
just discussing ideas here.
>
> > This is one solution to a particular problem in SRS. I'm
> sure there are
> > other solutions and I'm really just stirring the pot with this. I
> > believe this would work, but it is very different from
> present practice,
> > probably too much so.
>
> Maybe, but then again SPF+SRS, even without whatever scheme may
> eventually 'fix' SRS, is _already_ breaking backward compatibility by
> requiring that SRS be implemented by all forwarding hosts on the
> Internet. It's _already_ so far away from current practice that it's
> probably doomed to failure, and is lumped into the crackpot
> 'throw away
> SMTP as we know it' pile in the eyes of many.
People will have to accept some change to fix the present problem. How
much they will accept, and how far to push things for how much gain are
probably best arrived at by group opinion, though I take your negative
vote very seriously.
>
> > Do you see other solutions within the SRS framework? Maybe some
> > use of callbacks?
>
> Solutions to the brokenness of SPF, and the need for multiple
> rewriting
> if SPF is used? No.
>
> Solutions to the problem which SPF attempts to solve? Maybe.
>
> I've now implemented SRS for _all_ outgoing mail from
> dwmw2@infradead.org. Once I update the laptop too, you should _never_
> see mail in the wild with a reverse-path of dwmw2@infradead.org.
>
> Once I'm sufficiently happy with my implementation, I'll
> start rejecting
> bounces to dwmw2@infradead.org, because they can _only_ now happen in
> response to job-jobs.
How about bounces to SRS0+HHH+TT+infrardead.org+dwm2@your_MX, harvested
from your outgoing mail, whose timestamp is within your expiration
window? Aside from this, I do agree you have given yourself a way to
reject today's bounce spam and joe-job spew.
As an unrelated general question, how compatible is any SRS scheme with
current mailing list software? Are they smart enough to not use the
return-path as a reply-to, for lists that let you reply to the poster in
addition to the list?
>
> Third parties who want to avoid receiving mail with faked senders will
> be able to verify this by doing sender verification callouts -- a
> mechanism which is _already_ widely used to reduce joe-jobs, and which
> requires no assistance from uninterested third parties or fundamental
> changes to the way SMTP operates.
Agreed.
>
> At this point it seems that I will have prevented the faking of my own
> addresses -- that's basically what one sets out to achieve by
> publishing
> SPF records, isn't it?
That right.
>
> Of course this prevents such mail being accepted _only_ by anyone who
> cares enough about such things to do some basic checking -- but that
> condition is _always_ going to be present in any scheme.
Correct. Publishing SPF records does no good if no one checks them,
either.
Your point is well-taken. Single-level SRS alone with sender callbacks
(from the far end only, I hope), should prevent joe-jobs and does not
introduce the open-relay problem of the current SRS1. If people tell me
that sender callbacks are not to expensive, I accept that.
If you do sender callbacks on SRS0-signed email that you receive, you
can verify the sender except for harvested outgoing address scenario
that I mentioned. It wouldn't be trivial to construct a system that is
immune to that sort of playback attack, but I think it's worth a shot.
Better to continue that discussion on the Sender-Auth list.
--
Seth Goodman
-------
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 Mon, 2004-02-23 at 19:49 -0600, Seth Goodman wrote:
> > According to current practice, yes. I'm proposing breaking that in
> > order to limit relaying abuse in an SRS system. The
> proposal is to send
> > the DSN through the same path the message came in on. No other path
> > would accept the DSN. I know that's hard to swallow. So
> is the present
> > state of affairs.
>
> It _is_ hard to swallow. Too hard -- if you go down this path
> you might
> as well just admit that your Brave New World is completely
> incompatible
> with the status quo, and join the ranks of all the other crackpots who
> want to convert completely to a new system.
The proposal I made may well be too far from present practice to be
acceptable, as I myself stated in the next few sentences of that post.
That doesn't change the fact that SMTP is broken. Looking for a
solution to a broken protocol doesn't make someone a crackpot. We're
just discussing ideas here.
>
> > This is one solution to a particular problem in SRS. I'm
> sure there are
> > other solutions and I'm really just stirring the pot with this. I
> > believe this would work, but it is very different from
> present practice,
> > probably too much so.
>
> Maybe, but then again SPF+SRS, even without whatever scheme may
> eventually 'fix' SRS, is _already_ breaking backward compatibility by
> requiring that SRS be implemented by all forwarding hosts on the
> Internet. It's _already_ so far away from current practice that it's
> probably doomed to failure, and is lumped into the crackpot
> 'throw away
> SMTP as we know it' pile in the eyes of many.
People will have to accept some change to fix the present problem. How
much they will accept, and how far to push things for how much gain are
probably best arrived at by group opinion, though I take your negative
vote very seriously.
>
> > Do you see other solutions within the SRS framework? Maybe some
> > use of callbacks?
>
> Solutions to the brokenness of SPF, and the need for multiple
> rewriting
> if SPF is used? No.
>
> Solutions to the problem which SPF attempts to solve? Maybe.
>
> I've now implemented SRS for _all_ outgoing mail from
> dwmw2@infradead.org. Once I update the laptop too, you should _never_
> see mail in the wild with a reverse-path of dwmw2@infradead.org.
>
> Once I'm sufficiently happy with my implementation, I'll
> start rejecting
> bounces to dwmw2@infradead.org, because they can _only_ now happen in
> response to job-jobs.
How about bounces to SRS0+HHH+TT+infrardead.org+dwm2@your_MX, harvested
from your outgoing mail, whose timestamp is within your expiration
window? Aside from this, I do agree you have given yourself a way to
reject today's bounce spam and joe-job spew.
As an unrelated general question, how compatible is any SRS scheme with
current mailing list software? Are they smart enough to not use the
return-path as a reply-to, for lists that let you reply to the poster in
addition to the list?
>
> Third parties who want to avoid receiving mail with faked senders will
> be able to verify this by doing sender verification callouts -- a
> mechanism which is _already_ widely used to reduce joe-jobs, and which
> requires no assistance from uninterested third parties or fundamental
> changes to the way SMTP operates.
Agreed.
>
> At this point it seems that I will have prevented the faking of my own
> addresses -- that's basically what one sets out to achieve by
> publishing
> SPF records, isn't it?
That right.
>
> Of course this prevents such mail being accepted _only_ by anyone who
> cares enough about such things to do some basic checking -- but that
> condition is _always_ going to be present in any scheme.
Correct. Publishing SPF records does no good if no one checks them,
either.
Your point is well-taken. Single-level SRS alone with sender callbacks
(from the far end only, I hope), should prevent joe-jobs and does not
introduce the open-relay problem of the current SRS1. If people tell me
that sender callbacks are not to expensive, I accept that.
If you do sender callbacks on SRS0-signed email that you receive, you
can verify the sender except for harvested outgoing address scenario
that I mentioned. It wouldn't be trivial to construct a system that is
immune to that sort of playback attack, but I think it's worth a shot.
Better to continue that discussion on the Sender-Auth list.
--
Seth Goodman
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com