Mailing List Archive

On Mon, 2004-02-23 at 14:51 +0000, Brian Candler wrote:
> Neither SPF, nor callouts, will reduce the amount of spam you get. They
> might for a very short time, until the spammers catch up. I don't buy into
> this arms race, as it cannot be won.

I agree to a certain extent, but the world moves _slowly_. You _can_
remain perpetually ahead of the game.

I'll grant you that anything like SPF which _depends_ on widespread
adoption of its workaround scheme is fairly fundamentally flawed, since
it can't actually be used for real until the point at which, by your
definition, it's useless. But callouts have been stopping spam for me
for a _very_ long time, and I fully expect that they'll continue to do
so for some time to come.

--
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 Mon, Feb 23, 2004 at 02:56:18PM +0000, David Woodhouse wrote:
> On Mon, 2004-02-23 at 14:35 +0000, Brian Candler wrote:
> > A bounce cannot have more than one RCPT. If it does, it is not a bounce, and
> > can be rejected on that basis alone (either at the second RCPT TO, or at the
> > DATA stage based on the count of RCPT TOs)
>
> Wrong. Consider the case of a r??le address which is aliased to two
> recipients

(I guess that's a "role" address - mutt didn't like your UTF-8 for some
reason)

> -- for example, 'sales@virtualdomain.com' which is sent to
> two addresses 'joe@hotmail.com' and 'bob@hotmail.com'. We send a mail
> from sales@virtualdomain.com, and it bounces. Both Joe and Bob will get
> a copy of the mail.

Hmm. The outgoing mail looks like this:

MAIL FROM:<sales@virtualdomain.com>
RCPT TO:<badaddress@somewhere.com>

The mail is stored at somewhere.com, and later bounced. Then the bounce will
be:

MAIL FROM:<>
RCPT TO:<sales@virtualdomain.com>

That's a single RCPT TO recipient. *Then* it gets expanded to two separate
bounce messages, sent to joe@hotmail.com and bob@hotmail.com. And as they're
the same domain, they could be delivered simultaneously. Yuk. OK, you win
:-)

> > The main objection was "callbacks are too expensive", which I don't really
> > buy, since many people are doing them already (pobox.com included; note that
> > pobox.com have rejected whitelists as being too expensive, but still perform
> > callbacks)
>
> Callbacks if done _only_ for SRS0- addresses are absolutely _not_ too
> expensive. The real problem was probably that callbacks aren't SPF, and
> SPF must be the fix for _everything_ in the minds of some people.

:-)

Well, eventually I reckon the whole world would be sending all their mail
SRS0-signed to prevent joe-job bounces. At that point, everything would need
a callback.

And for simplicity, I'd just verify everything with a callback anyway. Why
*not* verify non-SRS0-signed recipients? People do it already.

> And for the specific case of verifying SRS0- addresses... why would you
> want to send mail _to_ those addresses?

You wouldn't, unless it was a bounce.

But to protect yourself from joe-jobs, you sign everything outgoing with
SRS0, and reject incoming bounces which are not SRS-signed.

Option 1:

MAIL FROM:<>
250
RCPT TO:<me@mydomain.com>
550 We only accept SRS-signed bounces

Option 2:

MAIL FROM:<>
250
RCPT TO:<me@mydomain.com>
250
DATA
350
... some bounce (probably a joe job) or spam
.
550 We only accept SRS-signed bounces

Option 2 is the way which doesn't break the 'milter' people, i.e. those
using RCPT TO as a kind of off-line recipient verification service.

> Sounds like someone said "We don't want to do callouts for _everything_
> since that actually solves a part of the problem which SPF also solves,
> so we therefore can't do callouts even just for SRS0- addresses because
> that might legitimise the use of callouts."

Maybe. Personally I say SPF solves the wrong problem anyway.

Regards,

Brian.

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

wayne <wayne@midwestcs.com> [2004-02-22/20:12]:
> In <20040222211146.GD26125@dragon.roe.ch> Daniel Roethlisberger
> <daniel@roe.ch> writes:
> > Don't be so sure. People have suggested using cookies as short as 32
> > bits -- which works only if the adversary has no oracle, ie. cannot
> > verify cookies for validity. With a 32 bit cookie, collisions are
> > expected after around 2^16 tries, or 65k SMTP RCPT TO attempts. This
> > might not be "worth it" for spammers, but it is feasible. There is
> > no point in using a cryptographically strong HMAC and then doing the
> > degrading security later on in the protocol.
>
> Ok I may be missing something here, but a 32 bit cookie should only
> get a collision once very 2^31 tries on average. In order to drop to
> ~sqrt(2^32), you need to be able to do a birthday attack. In order to
> do a birthday attack, there would need to be a way to cause many
> different SRS hashes to be generated for the same (timestamp,
> localpart, domain name) triplet, and that can't be done.

Quoting Niels Ferguson & Bruce Schneier: Practical Cryptography, p102:
``However, HMAC is still limited to n/2 bits of security, as there are
birthday attacks against the function that make use of the internal
collisions of the iterated hash function. The HMAC construction ensures
that these require 2^(n/2) interactions with the system under attack,
which is more difficult to do than performing 2^(n/2) computations on
your own computer.''

Yes, this statement does not explicitly apply to shortened HMACs. But
are you qualified to decide whether the attacks mentioned above apply
when the HMAC is shortened? I know that as a computer scientist and not
a mathematician, I am not, so I made it a general rule for myself to
always consider the birthday bound when assessing the strength of
cryptosystems involving hashes or MACs, even if there might not be any
obvious applicable birthday attacks (obvious to me, that is).

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 Mon, 2004-02-23 at 15:15 +0000, Brian Candler wrote:

> And for simplicity, I'd just verify everything with a callback anyway. Why
> *not* verify non-SRS0-signed recipients? People do it already.

No reason. I do that too. My point was just that we don't need to
_require_ it.

> Option 1:
> RCPT TO:<me@mydomain.com>
> 550 We only accept SRS-signed bounces
>
> Option 2:
> DATA
> 350
> ... some bounce (probably a joe job) or spam
> .
> 550 We only accept SRS-signed bounces
>
> Option 2 is the way which doesn't break the 'milter' people, i.e. those
> using RCPT TO as a kind of off-line recipient verification service.

In general, people use it as a kind of off-line _sender_ verification
service. And it's _better_ in that case if you let it fail.

It's very rare for someone to use it for _recipient_ verification, and
if they do, they should be using a reverse-path which matches the
reverse-path in the message they'd actually be trying to send. They
shouldn't be using an empty reverse-path.

> Maybe. Personally I say SPF solves the wrong problem anyway.

From my point of view, SPF solves nothing which couldn't be better
solved in other ways. SPF _is_ the problem which I'm trying to work
around by finding some non-broken SRS scheme.

--
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 Mon, Feb 23, 2004 at 03:00:32PM +0000, David Woodhouse wrote:
> On Mon, 2004-02-23 at 14:51 +0000, Brian Candler wrote:
> > Neither SPF, nor callouts, will reduce the amount of spam you get. They
> > might for a very short time, until the spammers catch up. I don't buy into
> > this arms race, as it cannot be won.
>
> I agree to a certain extent, but the world moves _slowly_. You _can_
> remain perpetually ahead of the game.

But what will you do next after SPF?

I would prefer to work on *strong* solutions which have a chance of
remaining viable over time, and which don't break things in the mean time.

Sender-validation schemes can never be strong, as long as domains are freely
registerable to all and sundry. If each company in the world were limited to
a single domain, well, that might be something (but even then, people can
create new companies at will). If domains could only be registered on
production of a passport, and the passport number were included in the
domain record, then, well, the Internet police state is born :-)

SRS is at least strong in the sense that it can prevent spam from <> and
prevent joe-job bounces, and is actually quite difficult to circumvent.

Challenge-response systems which require that a human read and interpret a
response message are pretty good.

A system which cryptographically signed a mail to say "it has definitely
been through ISP X's smarthost from IP address A at time B" or "it was sent
by authenticated user Y through ISP X's smarthost" would help in quickly
blacklisting spammers, with reliable real-time spam reporting.

> I'll grant you that anything like SPF which _depends_ on widespread
> adoption of its workaround scheme is fairly fundamentally flawed, since
> it can't actually be used for real until the point at which, by your
> definition, it's useless. But callouts have been stopping spam for me
> for a _very_ long time, and I fully expect that they'll continue to do
> so for some time to come.

Callouts are fine as far as they go; you are verifying that the spammer has
likely used a real, working mailbox for the return address. It's almost
certainly someone else's, of course :-)

If widely adopted, it may encourage a fair amount of list husbandry. That
is, spammers may take destinations which are rejected at RCPT TO: time out
of their lists, or at least, exclude them from being used as forged MAIL
FROM: senders. If I were a spammer, I'd be doing that now.

Regards,

Brian.

-------
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, Feb 23, 2004 at 03:23:56PM +0000, David Woodhouse wrote:
> > Option 1:
> > RCPT TO:<me@mydomain.com>
> > 550 We only accept SRS-signed bounces
> >
> > Option 2:
> > DATA
> > 350
> > ... some bounce (probably a joe job) or spam
> > .
> > 550 We only accept SRS-signed bounces
> >
> > Option 2 is the way which doesn't break the 'milter' people, i.e. those
> > using RCPT TO as a kind of off-line recipient verification service.
>
> In general, people use it as a kind of off-line _sender_ verification
> service. And it's _better_ in that case if you let it fail.

I agree with you - when verifying senders (i.e. callbacks) it is good for it
to fail. But as I say, I bow to those people on the list who see it used for
verifying *recipients*. Whether we should actively break those people is up
for discussion, but I generally take the large ISP view of breaking as
little as possible, because upset customers cost money, and generate upset
managers.

> > Maybe. Personally I say SPF solves the wrong problem anyway.
>
> >From my point of view, SPF solves nothing which couldn't be better
> solved in other ways. SPF _is_ the problem which I'm trying to work
> around by finding some non-broken SRS scheme.

:-)

It seems people who believe in SPF are also prepared to accept a fair degree
of breakage in their mail.

Regards,

Brian.

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

In <20040223152142.GC7005@dragon.roe.ch> Daniel Roethlisberger <daniel@roe.ch> writes:

> wayne <wayne@midwestcs.com> [2004-02-22/20:12]:
>> In <20040222211146.GD26125@dragon.roe.ch> Daniel Roethlisberger
>> <daniel@roe.ch> writes:
>> > [...] With a 32 bit cookie, collisions are
>> > expected after around 2^16 tries, or 65k SMTP RCPT TO attempts. This
>> > might not be "worth it" for spammers, but it is feasible. [...]
>>
>> [...] In order to drop to
>> ~sqrt(2^32), you need to be able to do a birthday attack. In order to
>> do a birthday attack, there would need to be a way to cause many
>> different SRS hashes to be generated for the same (timestamp,
>> localpart, domain name) triplet, and that can't be done.
>
> Quoting Niels Ferguson & Bruce Schneier: Practical Cryptography, p102:
> [snip]
>
> Yes, this statement does not explicitly apply to shortened HMACs. But
> are you qualified to decide whether the attacks mentioned above apply
> when the HMAC is shortened? I know that as a computer scientist and not
> a mathematician, I am not, [...]

OK, if you don't consider your self qualified, why did you make the
declarative statement that "With a 32 bit cookie, collisions are
expected after around 2^16 tries, or 65k SMTP RCPT TO attempts. This
might not be "worth it" for spammers, but it is feasible."?

I don't feel qualified enough to know exactly how much a lower the
security for a shortened HMAC is, but I do feel qualified to recognize
a birthday paradox attack when one is described. You said that a
birthday attack is feasible. I can't see how one is possible, but I am
very interested in any scenarios that might allow one against SRS.

Please either show how a birthday attack against SRS could be
possible, or stop spreading FUD by claiming that such an attack is
feasible.



-wayne

-------
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: "David Woodhouse" <dwmw2@infradead.org>
To: <srs-discuss@v2.listbox.com>
Sent: Monday, February 23, 2004 3:56 PM
Subject: Re: [srs-discuss] Re: [spf-discuss] Sender Rewriting Scheme and
open relays.

> On Mon, 2004-02-23 at 14:35 +0000, Brian Candler wrote:
>
> > A bounce cannot have more than one RCPT. If it does, it is not a bounce,
> > and can be rejected on that basis alone (either at the second RCPT TO,
> > or at the DATA stage based on the count of RCPT TOs)
>
> Wrong. Consider the case of a rôle address which is aliased to two
> recipients -- for example, 'sales@virtualdomain.com' which is sent to
> two addresses 'joe@hotmail.com' and 'bob@hotmail.com'. We send a mail
> from sales@virtualdomain.com, and it bounces. Both Joe and Bob will get
> a copy of the mail.
>
> It's perfectly valid to have bounces going to more than one address.

The envelope recipient of a valid DSN can, at all times, only be ONE
"controlling address". That address may, internally, 'resolve' to multiple
new addresses; but that is beyond the scope of the SMTP session.

> > The main objection was "callbacks are too expensive", which I don't
> > really buy, since many people are doing them already (pobox.com
> > included; note that pobox.com have rejected whitelists as being too
> > expensive, but still perform callbacks)

The main objection against callbacks, if I recall correctly, was merely that
you cannot rely on the result. I argued the case that a domain who writes
out SRS0 addresses be obligated to honor verification callouts requests.
Otherwise, there is for the middle man, not sharing in the secret, no way of
testing the validity of an SRS0 address.

But not everyone agreed with this position. And there were even people
saying my bouncing invalid SRS users was tantamount to giving spammers "a
way to brute force valid cookies".

Yet, we have to do one or the other: either we provide for callbacks to SRS0
addresses, or to regular addresses. But if an SMTP probe is not permitted
against the latter, then surely we must allow it against the former. Or what
else is there left to verify?

- 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

In <1077548178.11584.702.camel@imladris.demon.co.uk> David Woodhouse <dwmw2@infradead.org> writes:

>> Anyway, I raised exactly your suggestion a week or so back: if we sign
>> envelopes in an SRS-way, reject unsigned bounces at RCPT TO time, and
>> recipients perform callback verification, then the whole SPF shebang is
>> solved in one fell swoop.
>>
>> The main objection was "callbacks are too expensive", [...]

There are a couple of other reasons that I can immediately think of as
to why SRS isn't a complete replacement for SPF. One is the key
management issues with SRS. SPF can, if set up right, allow roaming
users and people working from home to send email without having them
know a secret/private key needed to create the SRS hash. The other is
that most MUAs don't allow you to easily specify the envelope-from
separately from the From: header, thus making it a real pain for many
people to use SRS.

> Callbacks if done _only_ for SRS0- addresses are absolutely _not_ too
> expensive.

"Too expensive" is a relative term. There are large ISPs that
consider having to do a single DNS lookup during an SMTP session to be
"too expensive".

I, personally, do not consider callbacks to be too expensive and I
currently use them. I do, however, understand that reasonable people
can disagree on this issue.


> The real problem was probably that callbacks aren't SPF, and
> SPF must be the fix for _everything_ in the minds of some people.

Well, I can't speak for others, but I strongly disagree with this. I
suspect that many others also have very valid reasons for objecting to
doing callbacks for reasons other than "it isn't SPF."



-wayne

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

wayne <wayne@midwestcs.com> [2004-02-23/09:55]:
> > Quoting Niels Ferguson & Bruce Schneier: Practical Cryptography,
> > p102: [snip]
> >
> > Yes, this statement does not explicitly apply to shortened HMACs.
> > But are you qualified to decide whether the attacks mentioned above
> > apply when the HMAC is shortened? I know that as a computer
> > scientist and not a mathematician, I am not, [...]
>
> OK, if you don't consider your self qualified, why did you make the
> declarative statement that "With a 32 bit cookie, collisions are
> expected after around 2^16 tries, or 65k SMTP RCPT TO attempts. This
> might not be "worth it" for spammers, but it is feasible."?

You are right in that I should have included the full reasoning in my
earlier posting, it did sound a little too assertive. Keep in mind that
English is not my native tongue.

The snippet you removed from the quoted text states that clever online
birthday attacks are possible against HMACs. SRS uses a shortened HMAC.
On what grounds do you assume that this shortening makes the described
birthday attack infeasible? The obvious conservative and only guaranteed
save conclusion is to assume that the birthday attacks mentioned by
Ferguson/Schneier are also applicable on shortened HMACs.

I do not consider myself qualified to assert that we can safely rule out
the possibility of such a clever online birthday attack on shortened
HMACs. So I have no choice but to assume that such an attack is
possible until somebody proofs that they are not.

> [...] You said that a birthday attack is feasible. I can't see how
> one is possible, but I am very interested in any scenarios that might
> allow one against SRS.

I did imply that one is feasible, yes. Instead I should have stated that
there seems to be no reason to assume that one is infeasible. I haven't
got the time right now to deeply dig into the sources referenced by
Ferguson / Schneier on this, that might yeld more information on the
exact nature of the attacks described, and whether they are feasible
against shortened HMACs. My gut feel tells me they are, but obviously
that is not good enough. But just assuming that shortening will make
them infeasible seems to be dangerous.

> Please either show how a birthday attack against SRS could be
> possible, or stop spreading FUD by claiming that such an attack is
> feasible.

I disagree. Being conservative when designing cryptosystems is
definately not spreading FUD. Whe designing cryptosystems, it should
always work the other way around: you should assume possible what you
cannot explicitly rule out. So I turn the challenge over to you: how can
you rule out the possibility of birthday attacks on shortened HMACs,
given that they seem to be possible on full length HMACs?

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 Mon, Feb 23, 2004 at 10:43:57AM -0600, wayne wrote:
> >> The main objection was "callbacks are too expensive", [...]
>
> There are a couple of other reasons that I can immediately think of as
> to why SRS isn't a complete replacement for SPF. One is the key
> management issues with SRS. SPF can, if set up right, allow roaming
> users and people working from home to send email without having them
> know a secret/private key needed to create the SRS hash.

With SRS you'd have to use SMTP AUTH to relay via your provider's smarthost,
agreed. With SPF you either do the same, or pre-declare the IP addresses
that they will be using. You have to keep this set of IP addresses as small
as possible; for genuinely roaming users you don't really want to open up
their address to the whole world.

> The other is
> that most MUAs don't allow you to easily specify the envelope-from
> separately from the From: header, thus making it a real pain for many
> people to use SRS.

I think SRS rewriting would generally be done at the ISP mail relay; you
would not be expected to type an SRS address in directly at your MUA! The
From: address would be unchanged, and the MTA would rewrite only the
envelope-sender.

Forged From: headers are a different and more intractable issue. If you mean
that validating an envelope-sender has not achieved much from the point of
view of the recipient of a mail, then I agree.

Regards,

Brian.

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

In <20040223170433.GA2947@uk.tiscali.com> Brian Candler <B.Candler@pobox.com> writes:

> On Mon, Feb 23, 2004 at 10:43:57AM -0600, wayne wrote:
>> >> The main objection was "callbacks are too expensive", [...]
>>
> With SRS you'd have to use SMTP AUTH to relay via your provider's smarthost,
> agreed. With SPF you either do the same, or pre-declare the IP addresses
> that they will be using. You have to keep this set of IP addresses as small
> as possible; for genuinely roaming users you don't really want to open up
> their address to the whole world.

There are other things you can do with SPF to deal with roaming
users who can not (or will not) use SMTP AUTH back to an official
MTA. One is to use a rate-limiting DNS server, as described by Philip
Gladstone. This allows a low rate of "unauthorized" emails to be
sent, which will allow people to use a cybercafe or customer systems
in to send email, while blocking massive forgeries. Another is
possibility (I forget the name of the person who suggested it) is to do
"SPF after IMAP". Basically, you can automatically add an IP address
on to an allowed list after the IP address has authenticated
themselves via IMAP.

These are some of the methods I was implying when I said that "SPF
can, if set up right, allow [easier roaming solutions]".

While SRS+callbacks is one way of detecting forged email, I don't see
it as the only useful system. I think that SPF can is more useful for
many, but not all, domains.


> Forged From: headers are a different and more intractable issue. If you mean
> that validating an envelope-sender has not achieved much from the point of
> view of the recipient of a mail, then I agree.

Forged From: headers are certainly a much harder issue, but I think
that validating the envelope-from can often play a very important part
in validating the From: header. There are other good reasons to validate
the envelope-from anyway, so I'm quite willing to start with SPF/SRS.


-wayne

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

In <20040223151548.GA2619@uk.tiscali.com> Brian Candler <B.Candler@pobox.com> writes:

> On Mon, Feb 23, 2004 at 02:56:18PM +0000, David Woodhouse wrote:
>> On Mon, 2004-02-23 at 14:35 +0000, Brian Candler wrote:
>> > A bounce cannot have more than one RCPT. If it does, it is not a bounce, and
>> > can be rejected on that basis alone (either at the second RCPT TO, or at the
>> > DATA stage based on the count of RCPT TOs)
>>
>> Wrong. Consider the case of a r??le address which is aliased to two
>> recipients
> [example snipped]
> That's a single RCPT TO recipient. *Then* it gets expanded to two separate
> bounce messages, sent to joe@hotmail.com and bob@hotmail.com. And as they're
> the same domain, they could be delivered simultaneously. Yuk. OK, you win
> :-)

Uh, but that doesn't show that a bounce with two RCPT TO:'s are
valid. I think you were right to begin with, a bounce can only go to
one recipient.



-wayne

-------
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]
> On Sun, 2004-02-22 at 22:31 -0600, Seth Goodman wrote:
> > This scheme also supports SPF at each
> > transfer. Here's my current best shot at how it would work. Your
> > criticism, and everyone else's, is welcome.
>
> Stage 4. You seem to say that the DSN has a non-empty
> reverse-path. You
> can't do that. I'm not sure it's a typo for 'destination'
> either, given
> the domains you have in it. Should I assume you meant that the
> destination matches the reverse-path of the original outgoing mail:
> SRS1+qwertyuiopzxasdfghjklzxcv+HHH+TT+goodmanassociates.com+se
> thg@forwarder

Doh (with loud slap to the forehead)! Thanks for your patience. As you
suggested, step 4 should have been:

MAIL FROM:<>
RCPT
TO:<SRS1+qwertyuiopzxasdfghjklzxcv+HHH+TT+goodmanassociates.com+sethg@fo

The subsequent steps need to be corrected, as well. Sorry for the
confusion. As per the SPF scheme, you do SPF checks on DSN's using the
FQDN from the HELO string.

>
> Stage 5. You assume that you'll get a bounce back from the
> same address
> you forwarded to. That's not the case. If you were forwarding to an
> aliasfile entry with multiple recipients, you could get back _many_
> bounces from all over the place.

This scheme forces you to only send a DSN back to the domain that handed
you the message originally. You never send it anywhere else, and no one
else will accept it. There can be multiple recipients at different
domains. Each individual copy of an outgoing message for which you are
the SMTP-sender has a single SMTP-recipient, and the domain of that
SMTP-recipient is part of what you encode in the return path. If there
are multiple recipient domains (that don't share an MX), there are
multiple SMTP sessions and you encode a single SMTP-receiver domain in
the return path during each session. Since each SMTP-recipient can have
multiple RCPT TO addresses, you can get multiple verifiable bounces from
every SMTP-recipient you send an instance of the message to. When an
MTA attempts to hand you a DSN with an SRS return path, you decrypt the
leading part and make sure that they were the SMTP-recipient on the
outbound path. If they were not, you reject the DSN before DATA.
Again, this means that a DSN must traverse the outgoing path in reverse
if it to be delivered. Some people might find that objectionable, but
it does allow for verification without callbacks and makes it difficult
to inject bogus DSN's that will not be immediately rejected before DATA.

>
> Also, you handle the case of a second forwarder, but what
> about a third
> and subsequent forwarders? They can't decrypt the domain from
> which the
> SRS0 address came, so have to add their own information to the address
> in order to get it back to forwarder for decryption... and hence we
> haven't actually solved the problem for anything but the second hop.

Since each relay records where it got the message from and where it
relayed it to, there is no limit to the number of forwards. No one but
the first forwarder cares about the SRS0 information. This systems says
that if you forward a message to an SMTP-recipient, you will only accept
a DSN for that particular message from that particular SMTP-recipient.
I will repost the corrected scheme with an additional forwarder to show
this, or let you show me where it falls apart.

>
> > > Sender verification callouts _already_ answer your
> initial objection, in
> > > the real world. Why do you need SPF to fix it too?
> >
> > Callbacks are expensive, from what I am told.
>
> My first-hand experience is that they are not significantly
> expensive.
> I do them for all addresses, but if you really care about the cost you
> could do them _only_ for SRS0-bounce addresses coming from
> hosts listed
> as 'neutral' by the SPF record for the domain in question.
>
> So if srs.aol.com had an SPF record which precisely matches
> the one for
> aol.com, you'd bypass the callbacks if receiving such a
> message directly
> from AOL, and you'd callback to AOL _only_ in the case where you're
> receiving it from somewhere else due to multi-hop forwarding.
>
> Doing callouts for that limited case is surely not too expensive?

That's a reasonable suggestion.

>
> > I don't think I saw your alternative. Could you repost it please?
>
> (with the refinement above).
>
> The problem with SRS as it stands is the multi-hop forwarding and in
> particular the 'shortcut' which opens you up to forward _unverified_
> SRS1+... addresses as a (limited) open relay.
>
> My suggestion was just that we avoid the need to perform the
> second and
> subsequent rewrite. Declare that the addresses used for SRS
> _shall_ not
> need rewriting because they _shall_ be acceptable from any address.

You won't accept DSN's with concocted SRS0 strings, but you will if
someone succeeds in harvested the return path from a valid SRS0-signed
message that you sent. If you want to do SPF on the forward path, you
can still use the FQDN from the HELO string just like you do for a DSN.
I suppose that works and it does avoid sender rewriting.

However, I still have two problems with this scheme. The first problem,
that perhaps isn't avoidable at all, is that anyone who harvests one of
your legitimate SRS0 signatures can send you DSN spam that SRS will
happily pass. My scheme for restricting the return path closes the
window on this a bit, since there are limited machines that you will
accept DSN's from. I think it also helps your open relay scenario.

The second problem is generic to any cryptographic validation scheme.
Since checking validity requires more CPU time than creating a bogus
message, we have now made ourselves vulnerable to a DDOS attack. If a
few thousand zombies send you bogus DSN's at wide intervals, you would
reject every one, but only after computing thousands of SHA-1 hashes.
If enough machines are doing it, you won't get a high enough count on
any of them to blacklist them. Unless you have accelerator hardware at
your end to make the crypto verification time negligible, it costs you a
lot more to reject a message than for them to send it, thus it is a good
DOS tool. Having accelerator hardware would negate this, and since I
design hardware, I like that approach!

BTW, I did previously argue against SHA-1 due to its computational
overhead, but others declared that negligible and a non-issue. Perhaps
this should be reconsidered, but I won't push it. I should point out
that one prominent anti-spamming proposal was to forced the sending MTA
to compute an expensive hash in order to add a cost to sending mail. As
things now stand, we have created the opposite situation. It is more
expensive to reject a bogus DSN than to send one.


>
> The problem of forged SRS0+... addresses is easily fixed by callouts,
> and the cost of those can be kept down by accepting _without_ callout
> for any host for whom the SPF record evaluates to 'Pass'.
>
>
> > Unless you can compute a valid hash for my domain, which
> you would need
> > to know my secret key to do, my MTA will reject the message
> during SMTP
> > before DATA.
>
> The proposed scheme doesn't _give_ you a hash to check on SRS1+
> messages. Yours does but doesn't seem to actually allow shortcuts,
> unless I'm missing something obvious.

That's right, it forgoes the shortcut and forces validation at each hop.


>
> > Not much bandwidth or CPU wasted. If you _have_ managed
> > to harvest a valid SRS0 signed message from me, with the current SRS
> > protocol, I'm in deep yogurt and you could send me bogus
> bounces from
> > anywhere on the net that will pass SRS and tie my MTA up in
> knots. That
> > is why I proposed the modified SRS scheme at the beginning
> of this post.
> > I also happens to solve your open relay exploit.
>
> We can only 'solve' that by limiting the timestamps; you can't discard
> bounces because there is _no_ way of telling if they're valid.

As long as they get their paws on an SRS0 string whose hash verifies,
that's true. I was merely attempting to close the window somewhat by
greatly limiting the legitimate source of each DSN, thus making it
impractical to use harvested SRS addresses.

--

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

In <1077532438.11584.457.camel@imladris.demon.co.uk> David Woodhouse <dwmw2@infradead.org> writes:

> On Mon, 2004-02-23 at 02:18 +0000, Mark wrote:
>> Indeed, I do not understand you here; _all_ whose IP addresses? Surely only
>> those of AOL itself, I hope?
>
> No. For the specific case of the 'srs.aol.com' domain, a domain used
> _only_ for SRS addresses, I suggest that _all_ IP addresses should be
> permitted. These addresses are trivially verifiable by other means. SPF
> doesn't _have_ to be the solution to _every_ problem.

Eh?

You really want anyone to be able to send email using the
srs.domain.tld domain? If, as is currently the case, the vast
majority of MTAs don't do sender callbacks, then this is just begging
to be abused.



-wayne

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

In <200402231430.I1NEUDVB017346@asarian-host.net> Mark <admin@asarian-host.net> writes:

>> Right. The ones done in response to a _valid_ mail will be done with the
>> SRS-signed address. The only time you'll get a callout with the 'raw'
>> address, if you're never sending mail from the 'raw' address, is if a
>> third party is faking it.
>
> Or someone trying to see whether my address exists.

If I want to see if I can send email to a given address, I shouldn't use a null
envelope-from. If I want to see if an envelope-from is valid, I
shouldn't use a MAIL FROM: address.

Granted, I suspect that many systems confuse these two cases....


-wayne

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

Here is a revised approach for fixing the open-relay problem that has
been pointed out, as well as providing some protection if an SRS0-signed
address gets harvested. This breaks the shortcut return method for a
DSN. Any DSN must go through the same series of domains, in reverse
order, that the message took on the outgoing path. This may be
burdensome from the protocol standpoint, but legitimate DSN's are not a
large part of normal mail traffic, so the extra overhead should not be a
practical issue. To the extent that it is adopted, this scheme makes it
very hard to send bogus DSN's anywhere. Even if you can harvest an
SRS-signed address, it must sent to the right domain from another
specific domain for it to be accepted. Hopefully, this plugs the holes
in the system.

The following description uses hashing for SRS0 and reversible
encryption for SRS1. Any of these could be done using a database scheme
resulting in a much shorter, though unreadable, return path. A database
lookup may also take less CPU cycles than the cryptographic solution.
Either approach can be used an any site and there are no compatibility
issues, as each site only has to undo the part of the address it
created.

Here is an example of a message going through a local gateway, two
forwarders and a target gateway with a DSN coming back from the far end.


1) The MUA in my machine sends a message to my MTA for outbound relay:

MAIL FROM:<local_part@domain>
RCPT TO:<alias1@forwarder1>


2) My outgoing mailserver, whose domain is "originating_MTA", relays it
to the MX for forwarder1. To prevent DSN abuse in case its SRS0
signature gets out, it adds the domain that it is sending to,
"forwarder1", to the SRS0 address and protects it with the SRS0 hash:

MAIL FROM:<SRS0+HHH+TT+forwarder1+domain+local_part@originating_MTA>
RCPT TO:<alias1@forwarder1>


3) The MTA at forwarder1 changes the outgoing address to
alias2@forwarder2. Since forwarder1 is relaying a message with an SRS0
return-path, it also rewrites the return-path to an SRS1 path. To
prevent open relaying, it reversibly encrypts both the domain the
message came from, "originating_MTA", and the domain it is going to,
"forwarder2", into the SRS1 return path. It then relays the message to
the MX for forwarder2:

forwarder2+originating_MTA
| |
MAIL
FROM:<SRS1+qwertyuiopasdfghjklzxcvbnm+HHH+TT+forwarder1+domain+local_par
t@forwarder1>
RCPT TO:<alias2@forwarder2>


4) The MTA at forwarder2 changes the outgoing address to
local_part@target_domain. Since forwarder2 is relaying a message with
an SRS1 return path, it extends that path just like forwarder1 did. It
reversibly encrypts both the domain the message came from, "forwarder1",
and the domain it is going to, "target_domain", into the SRS1
return-path. I then relays the message to the MX for target_domain:

target_domain+forwarder1
| |
MAIL
FROM:<SRS1+zxcvbnmasdfghjklqwertyui+qwertyuiopasdfghjklzxcvbnm+HHH+TT+fo
rwarder1+domain+local_part@forwarder2>
RCPT TO:<local_part@target_domain>


5) The MTA at target_domain tries to deliver the message to the MUA for
whatever local_part resolves to, but that mailbox stays full for a week.
The MTA gives up and sends a DSN back to the MX for forwarder2:

MAIL FROM:<>
RCPT
TO:<SRS1+zxcvbnmasdfghjklqwertyui+qwertyuiopasdfghjklzxcvbnm+HHH+TT+forw
arder1+domain+local_part@forwarder2>


6) Since this is an SRS1-signed DSN, the MTA at forwarder2 decrypts the
first field to see if it should accept it. The first field decrypts
into target_domain+forwarder1. Since the DSN did indeed come from
target_domain, it accepts the DSN. The second half of the decrypted
field tells the MTA to forward the DSN to the MX for forwarder1, after
removing the first encrypted field:

MAIL FROM:<>
RCPT
TO:<SRS1+qwertyuiopasdfghjklzxcvbnm+HHH+TT+forwarder1+domain+local_part@
forwarder1>


7) Since this is an SRS1-signed DSN, the MTA at forwarder1 decrypts the
first field to see if it should accept it. The first field decrypts
into forwarder2+originating_MTA. Since the DSN did indeed come from
forwarder2, it accepts the DSN. The second half of the decrypted field
tells the MTA to forward the DSN to the MX for originating_MTA, after
removing the encrypted field and rewriting the return-path as an SRS0
address:

MAIL FROM:<>
RCPT TO:<SRS0+HHH+TT+forwarder1+domain+local_part@originating_MTA>


8) Since this is an SRS0-signed message, the MTA at originating_MTA
validates the hash and also makes sure the connecting machine is from
forwarder1. Since both conditions are met, it accepts the DSN. It then
delivers the DSN to whatever local_part@domain resolves to.


--

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 17:23 -0600, Seth Goodman wrote:
> The MTA gives up and sends a DSN back to the MX for forwarder2:
>
> MAIL FROM:<>
> RCPT TO:<SRS1+zxcvbnmasdfghjklqwertyui+qwertyuiopasdfghjklzxcvbnm+HHH+TT+forwarder1+domain+local_part@forwarder2>
>
> 6) Since this is an SRS1-signed DSN, the MTA at forwarder2 decrypts the
> first field to see if it should accept it. The first field decrypts
> into target_domain+forwarder1. Since the DSN did indeed come from
> target_domain, it accepts the DSN.

You can't require that it comes from target_domain. It can come from
_anywhere_.

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

wayne (wayne@midwestcs.com) wrote:

> Uh, but that doesn't show that a bounce with two RCPT TO:'s are
> valid. I think you were right to begin with, a bounce can only go to
> one recipient.

I'm still unclear on this, because we don't know what happens next.
To reiterate:

## Session from somewhere unspecified to example.com
MAIL FROM:<>
RCPT TO:<sales@example.com> # which expands to two @hotmail.com addrs

On a qmail system (just as an example), this message would go into the
queue, and qmail-send would mark it "local" (assuming that example.com
is a local domain). It would be delivered to the local user "sales",
which would then forward it (without SRS, for the sake of example) to the
two hotmail addresses. Because of the nature of qmail, each of those two
messages would be delivered separately, in different SMTP sessions, thus:

## Session 1 from example.com to hotmail.com (qmail)
MAIL FROM:<>
RCPT TO:<alice@hotmail.com>

## Session 2 from example.com to hotmail.com (qmail)
MAIL FROM:<>
RCPT TO:<bob@hotmail.com>

But, as I understand it, sendmail will (try very hard to) consolidate
the two recipients into a single session:

## Session from example.com to hotmail.com (sendmail)
MAIL FROM:<>
RCPT TO:<alice@hotmail.com>
RCPT TO:<bob@hotmail.com>

So, a few questions:

* Do I remember sendmail's behavior correctly? It may have changed....

* The bounces would be sent on with empty MAIL FROM: in a pre-SRS
universe; what if example.com is using SRS in some form?

* Is anyone currently using "only one RCPT TO per bounce" as a filter
in the real world; and if so, what can you tell us about it?

--
Greg Wooledge | "Truth belongs to everybody."
greg@wooledge.org | - The Red Hot Chili Peppers
http://wooledge.org/~greg/ |

-------
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]
>
> On Mon, 2004-02-23 at 17:23 -0600, Seth Goodman wrote:
> > The MTA gives up and sends a DSN back to the MX for forwarder2:
> >
> > MAIL FROM:<>
> > RCPT
> TO:<SRS1+zxcvbnmasdfghjklqwertyui+qwertyuiopasdfghjklzxcvbnm+H
> HH+TT+forwarder1+domain+local_part@forwarder2>
> >
> > 6) Since this is an SRS1-signed DSN, the MTA at forwarder2
> decrypts the
> > first field to see if it should accept it. The first field decrypts
> > into target_domain+forwarder1. Since the DSN did indeed come from
> > target_domain, it accepts the DSN.
>
> You can't require that it comes from target_domain. It can come from
> _anywhere_.

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.

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. Do you see other solutions within the SRS
framework? Maybe some use of callbacks?

--

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 20:20 -0500, Greg Wooledge wrote:
> But, as I understand it, sendmail will (try very hard to) consolidate
> the two recipients into a single session:
>
> ## Session from example.com to hotmail.com (sendmail)
> MAIL FROM:<>
> RCPT TO:<alice@hotmail.com>
> RCPT TO:<bob@hotmail.com>
>
> So, a few questions:
>
> * Do I remember sendmail's behavior correctly? It may have changed....

Not sure about sendmail, but you're probably right. Exim will try to do
this, certainly. It's an obvious optimisation which you'd expect from
any serious MTA.

> * The bounces would be sent on with empty MAIL FROM: in a pre-SRS
> universe; what if example.com is using SRS in some form?

They'd still need to use an empty reverse-path.

> * Is anyone currently using "only one RCPT TO per bounce" as a filter
> in the real world

Probably -- there are even people rejecting 'MAIL FROM:<>' _entirely_;
there's no reason to believe that in a world where people can be that
stupid, they won't also do the above.

> and if so, what can you tell us about it?

That it should be considered sufficient grounds for being listed in an
rfc-ignorant.org blacklist?

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

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

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

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.

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?

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.

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