Mailing List Archive

> -----Original Message-----
> From: owner-srs-discuss@v2.listbox.com
> [mailto:owner-srs-discuss@v2.listbox.com]On Behalf Of Neil Brown
> Sent: Wednesday, March 17, 2004 4:16 PM
> To: SRS-Discuss Forum
> Subject: [srs-discuss] The open relay problem.

<...>

> A simple backwards-compatible way to do this in an spf1 record would
> be to put e.g. "+srs0" *after* the "*all" word. e.g. I would replace
>
> cse.unsw.edu.au IN TXT "v=spf1 a mx ?all"
> with
> cse.unsw.edu.au IN TXT "v=spf1 a mx ?all +srs0"
>
> This should not affect the current processing of spf1 records as it
> should stop at the first 'all'.

This would certainly accomplish what you want, but I question if it is
really necessary. The situation you are talking about only happens for
a DSN. If the target of the SRS0 address does not actually produce SRS0
addresses, it should reject DSN during the SMTP session as soon as it
sees that the recipient address,

RCPT TO:<SRS0=HHH=TT=local-part@domain-part>

is not a valid user address. This could only be a problem for a backup
MX when the primary MX is offline or if the primary MX does not verify
deliverability at RCPT TO: time. Unless there is a catch-all account,
they MUST drop the undeliverable DSN, so no real harm was done aside
from wasting their own bandwidth. If they have a catch-all account and
don't check recipient addresses during the SMTP session, they reap what
they have sewn.

--

Seth Goodman

On Wednesday March 17, sethg@GoodmanAssociates.com wrote:
>
> This would certainly accomplish what you want, but I question if it is
> really necessary. The situation you are talking about only happens for
> a DSN. If the target of the SRS0 address does not actually produce SRS0
> addresses, it should reject DSN during the SMTP session as soon as it
> sees that the recipient address,
>
> RCPT TO:<SRS0=HHH=TT=local-part@domain-part>
>
> is not a valid user address. This could only be a problem for a backup
> MX when the primary MX is offline or if the primary MX does not verify
> deliverability at RCPT TO: time. Unless there is a catch-all account,
> they MUST drop the undeliverable DSN, so no real harm was done aside
> from wasting their own bandwidth. If they have a catch-all account and
> don't check recipient addresses during the SMTP session, they reap what
> they have sewn.

Thankyou for answering.

You seem to be saying that you don't think the problem is very big,
and doesn't need to be solved. Maybe you are right.

But there is another problem.

Some people think the problem *is* big enough and so they refuse to
forward SRS1 addresses to the corresponding SRS0 address.

At least one person on this list has stated that this is their
policy. If one person has said it, probably several other people
believe it. It doesn't matter if they are right or wrong. What
matters is that they are refusing to support SRS1 addresses.

I think *that* is a problem that is big enough to be worth solving.

If a way of querying if a site understands SRS were available to them,
I suspect they would be less adverse to sending SRS addresses to those
sites.


Alternate answer: You finish by saying "they reap what they have
sewn", and that may be true, but that doesn't stop them from being
angry at you when some spammer uses your SPS1-semiopen-relay to fill
their wildcard mailbox with spam. If their anger turned to a law
suit, would you be sure of your case?

NeilBrown

> -----Original Message-----
> From: owner-srs-discuss@v2.listbox.com
> [mailto:owner-srs-discuss@v2.listbox.com]On Behalf Of Neil Brown
> Sent: Wednesday, March 17, 2004 6:31 PM
> To: srs-discuss@v2.listbox.com
> Subject: RE: [srs-discuss] The open relay problem.

<...>

> But there is another problem.
>
> Some people think the problem *is* big enough and so they refuse to
> forward SRS1 addresses to the corresponding SRS0 address.
>
> At least one person on this list has stated that this is their
> policy. If one person has said it, probably several other people
> believe it. It doesn't matter if they are right or wrong. What
> matters is that they are refusing to support SRS1 addresses.
>
> I think *that* is a problem that is big enough to be worth solving.
>
> If a way of querying if a site understands SRS were available to them,
> I suspect they would be less adverse to sending SRS addresses to those
> sites.
>
>
> Alternate answer: You finish by saying "they reap what they have
> sewn", and that may be true, but that doesn't stop them from being
> angry at you when some spammer uses your SPS1-semiopen-relay to fill
> their wildcard mailbox with spam. If their anger turned to a law
> suit, would you be sure of your case?

Personally, I'm not a proponent of the present SRS scheme for a variety
of reasons, but I don't think the one you brought up is a valid
objection anymore. The original SRS spec did create a limited open
relay at the second forwarder, but the current spec has effectively
eliminated that. This was accomplished by protecting the SRS1 address
with a hash produced by the second forwarder who rewrote the SRS0
address that came from the first forwarder. This forces a DSN to go
back through the same second forwarder and then through the same first
forwarder that the message took on the outgoing path before being
returned to the user.

The second forwarder will refuse any DSN where the SRS1 hash in the RCPT
TO: address does not validate. Thus, the second forwarder is no longer
an open relay. Since the SRS1 hash also protects the inner SRS0
address, including its hash, an attacker must produce a valid RCPT
TO:<SRS1=HHH=...==SRS0=HHH=...> string if they are to get a forged DSN
through both forwarders. If you can get hold of those strings through
some subterfuge, you can indeed send bogus DSN's to the second
forwarder. It will accept the DSN, rewrite it to an SRS0 address and
send it back to the first forwarder. There it will be accepted and
relayed back to the original sender.

However, unless you can either get a copy of a valid outgoing SRS1
address (replay attack) or you know the secret keys for both the first
and second forwarders, you can't construct an address that will be
accepted by both the second forwarder and the first forwarder. Since
both the SRS1 hash and SRS0 hash are each the first several bytes of a
SHA-1 hash, a random guess attack would be pointless. So unless you can
somehow get a copy of the required information, bogus DSN's will be
rejected either at the second forwarder or the first, making the exploit
useless. Shevek has detailed a complicated exploit that he calls the
five-player game through which an attacker can, in limited
circumstances, harvest a valid SRS1 address. However, this exploit is
very complicated and has particular requirements that only make it
feasible for a small subset of target addresses. In general, there is
very little opportunity to harvest legitimate SRS1 outgoing addresses.

I can think of numerous objections to the present SRS scheme, in
particular its need to rewrite addresses at every forwarder, but I think
the open relay problem has been fairly well put to rest. If you can
outline a scenario where a forwarder still acts as an open relay, that
would be very important for this group to know about.

--

Seth Goodman

Seth Goodman <sethg@GoodmanAssociates.com> [2004-03-17/18:17]:
> [...] If they have a catch-all account and don't check recipient
> addresses during the SMTP session, they reap what they have sewn.

The fact that catch-all accounts exist in this real world we are talking
about, and are very unlikely to just magically go away because it would
make our life easier, is one of the main points in the argument. You
still seem to blindly ignore this matter of fact. I don't think that is
very constructive. Basically, SRS and catch-all accounts don't play well
together, and I think that's not too favourable to the acceptance of
SRS, and with it, to SPF. Ignoring it will not help.

But, we've been through this time and over again, so I'll just leave it
at that.

Cheers,
Dan


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

> -----Original Message-----
> From: owner-srs-discuss@v2.listbox.com
> [mailto:owner-srs-discuss@v2.listbox.com]On Behalf Of Daniel
> Roethlisberger
> Sent: Thursday, March 18, 2004 6:20 AM
> To: srs-discuss@v2.listbox.com
> Subject: Re: [srs-discuss] The open relay problem.

<...>

> The fact that catch-all accounts exist in this real world we
> are talking
> about, and are very unlikely to just magically go away
> because it would
> make our life easier, is one of the main points in the argument. You
> still seem to blindly ignore this matter of fact. I don't
> think that is
> very constructive. Basically, SRS and catch-all accounts
> don't play well
> together, and I think that's not too favourable to the acceptance of
> SRS, and with it, to SPF. Ignoring it will not help.
>
> But, we've been through this time and over again, so I'll
> just leave it
> at that.

I am aware that catch-all accounts exist and will continue to do so.
Rather than "blindly" ignoring this fact, I was expressing a personal
preference, albeit a strong one. However, my personal preference with
regard to catch-all accounts and whether an open relay exists in the
present SRS spec are two different matters. It was sloppy of me to
confuse the two, so thanks for pointing this out.

I find myself in an odd position here. As I stated, I am not a
proponent of the current SRS scheme for various reasons, but I disagree
that there still exists an open relay. To be sure, there was one in the
original SRS spec, but I believe that has been closed by the newer
protocol. Let me try to make an argument for this.

If a first forwarding site has a catch-all account _and_ neither
generates nor checks SRS0 addresses, they will accept any DSN that comes
back from an SRS1 forwarder. However, to get the second forwarder to
accept a bogus DSN to relay, it MUST have a valid SRS1 hash. The
internal SRS0 address it contains can be bogus and the SRS0 hash can be
junk, but the SRS1 hash is calculated over the SRS0 address and it must
validate to be accepted by the second forwarder. The existence of that
SRS1 hash is what, IMHO, effectively closes the open relay that existed
in earlier drafts of the protocol.

If an attacker sends a bogus DSN to a second forwarder with a SRS1 hash
that does not validate, it will be rejected during the SMTP session. If
the second forwarder operates in store-and-forward mode, the message
will be deleted when it is discovered that the SRS1 hash does not
validate. To produce a forged DSN containing an bogus SRS0 address for
the first (non-SRS) forwarder that the second forwarder will accept, one
must get a copy of a valid SRS1 address leaving the second forwarder
that includes an SRS0 address for the first forwarder. Since the first
forwarder never produces SRS0 addresses, this is not possible. Since
any SRS1 address leaving the second forwarder is protected by a hash, it
is not possible, without knowing the secret key of the second forwarder,
to create a valid SRS1 address from scratch. Even if we did succeed in
harvesting a valid SRS1 address leaving the second forwarder, we would
have to substitute an SRS0 address for the first forwarder, which would
invalidate the SRS1 hash. This is why I believe that the open relay to
catch-all accounts of non-SRS hosts that the original SRS spec created
is effectively closed in the newer protocol.

If I am misconstruing something, please correct me.

--

Seth Goodman

----- Original Message -----
From: "Neil Brown" <neilb@cse.unsw.edu.au>
To: "SRS-Discuss Forum" <srs-discuss@v2.listbox.com>
Sent: Wednesday, March 17, 2004 11:16 PM
Subject: [srs-discuss] The open relay problem.

> So, I'm proposing that an MTA should only unwrap an SRS1 address and
> forward on to the appropriate SRS0 address if the domain in the SRS0
> address publishes a "spf" record which declared "+srs0", and that
> MTAs which send SRS0 wrapped return addresses should declare that
> fact by having "+srs0" in the spf record for each domain they
> control.

Regardless of whether SRS1 addresses are valid, my question has always been,
Why relay at all? An open relay is simply this:

"A host which, barring local .forward functionality, relays mail to
non-local recipients, from non-authorized IP space."

SRS1 falls into that category. If you send me a valid, non-local, SRS0
address, wrapped in a valid SRS1 recipient, then I am an open relay; because
I allow you, from an unauthorized IP space, to use my (E)SMTP mailers to
send mail to non-local recipients. And my subsequent question has always
been, Why allow that to begin with?

Forget SRS for a moment. I am not an open relay now; so, why would I become
one now? Even if I receive a perfectly legit SRS1 address, the resulting
SRS0 address -- while its validity is difficult to check; and even if -- is,
for the purpose of this argument, still a non-local recipient.

I try and keep an open mind, of course. But I have yet to hear a good reason
why I should suddenly 'open' relay mail for third parties -- however nice
folks they may be. :) If I were in the forwarding business, like pobox, then
that would naturally change things.

But, as it stands, I only accept SRS1 addresses that result in a valid,
local SRS0 address (and, consequently, a in valid local recipient). Since I
only ever send out SRS0 addresses with my own domains, I expect to only see
such addresses return. In that context, the quoted "They reap what they have
sewn" is quite applicable here: I only reap SRS0 addresses I have sown.

Regards,

- Mark

System Administrator Asarian-host.org

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

> -----Original Message-----
> From: owner-srs-discuss@v2.listbox.com
> [mailto:owner-srs-discuss@v2.listbox.com]On Behalf Of Mark
> Sent: Thursday, March 18, 2004 10:46 AM
> To: srs-discuss@v2.listbox.com
> Subject: Re: [srs-discuss] The open relay problem.
>
>
> ----- Original Message -----
> From: "Neil Brown" <neilb@cse.unsw.edu.au>
> To: "SRS-Discuss Forum" <srs-discuss@v2.listbox.com>
> Sent: Wednesday, March 17, 2004 11:16 PM
> Subject: [srs-discuss] The open relay problem.
>
> > So, I'm proposing that an MTA should only unwrap an SRS1 address and
> > forward on to the appropriate SRS0 address if the domain in the SRS0
> > address publishes a "spf" record which declared "+srs0", and that
> > MTAs which send SRS0 wrapped return addresses should declare that
> > fact by having "+srs0" in the spf record for each domain they
> > control.
>
> Regardless of whether SRS1 addresses are valid, my question
> has always been,
> Why relay at all? An open relay is simply this:
>
> "A host which, barring local .forward functionality, relays mail to
> non-local recipients, from non-authorized IP space."

I couldn't agree more with these sentiments. That is, IMHO, a huge flaw
in the present SRS scheme and will make it much more unlikely that the
world will ever get the benefits of SPF.


>
> SRS1 falls into that category. If you send me a valid, non-local, SRS0
> address, wrapped in a valid SRS1 recipient, then I am an open
> relay; because
> I allow you, from an unauthorized IP space, to use my (E)SMTP
> mailers to
> send mail to non-local recipients. And my subsequent question
> has always
> been, Why allow that to begin with?

There is no reason to allow this, especially since there have been
reasonable alternatives proposed to the core group who wrote the present
protocol, though they were ignored without serious discussion.

>
> Forget SRS for a moment. I am not an open relay now; so, why
> would I become
> one now? Even if I receive a perfectly legit SRS1 address,
> the resulting
> SRS0 address -- while its validity is difficult to check; and
> even if -- is,
> for the purpose of this argument, still a non-local recipient.

You _could_ check the SRS0 address with a CBV, but you are still,
strictly speaking, operating a relay. It is a fairly trusted relay
since the address has to pass two cryptographic checks done at two
different sites, but it still is a relay. Even though it is fairly safe
relay, it would be best if it did not exist at all.

>
> I try and keep an open mind, of course. But I have yet to
> hear a good reason
> why I should suddenly 'open' relay mail for third parties --
> however nice
> folks they may be. :) If I were in the forwarding business,
> like pobox, then
> that would naturally change things.
>
> But, as it stands, I only accept SRS1 addresses that result
> in a valid,
> local SRS0 address (and, consequently, a in valid local
> recipient). Since I
> only ever send out SRS0 addresses with my own domains, I
> expect to only see
> such addresses return. In that context, the quoted "They reap
> what they have
> sewn" is quite applicable here: I only reap SRS0 addresses I
> have sown.
>
> Regards,
>
> - Mark

That is, IMHO, a very rational approach. David Woodhouse and I have
worked on a proposal where MTA's only sent out SRS0 addresses, just like
you do, and SPF is used differently so that it does _not_ require
rewriting of the return address _anywhere_ in the mail chain. It also
happens to be interoperable with the current SPF+SRS. I think there are
better ways to do things than the current SRS scheme. I am afraid that
the current SRS will stall adoption of SPF and give an undesired boost
to CID and DK. That would be a real shame.


--

Seth Goodman

On Thu, Mar 18, 2004 at 11:50:59AM -0600, Seth Goodman wrote:
> > -----Original Message-----
> > From: owner-srs-discuss@v2.listbox.com
> > [mailto:owner-srs-discuss@v2.listbox.com]On Behalf Of Mark
> > Sent: Thursday, March 18, 2004 10:46 AM
> > To: srs-discuss@v2.listbox.com
> > Subject: Re: [srs-discuss] The open relay problem.
> >
> >
> > ----- Original Message -----
> > From: "Neil Brown" <neilb@cse.unsw.edu.au>
> > To: "SRS-Discuss Forum" <srs-discuss@v2.listbox.com>
> > Sent: Wednesday, March 17, 2004 11:16 PM
> > Subject: [srs-discuss] The open relay problem.
> >
> > > So, I'm proposing that an MTA should only unwrap an SRS1 address and
> > > forward on to the appropriate SRS0 address if the domain in the SRS0
> > > address publishes a "spf" record which declared "+srs0", and that
> > > MTAs which send SRS0 wrapped return addresses should declare that
> > > fact by having "+srs0" in the spf record for each domain they
> > > control.
> >
> > Regardless of whether SRS1 addresses are valid, my question
> > has always been,
> > Why relay at all? An open relay is simply this:
> >
> > "A host which, barring local .forward functionality, relays mail to
> > non-local recipients, from non-authorized IP space."
>
> I couldn't agree more with these sentiments. That is, IMHO, a huge flaw
> in the present SRS scheme and will make it much more unlikely that the
> world will ever get the benefits of SPF.
>
>
> >
> > SRS1 falls into that category. If you send me a valid, non-local, SRS0
> > address, wrapped in a valid SRS1 recipient, then I am an open
> > relay; because
> > I allow you, from an unauthorized IP space, to use my (E)SMTP
> > mailers to
> > send mail to non-local recipients. And my subsequent question
> > has always
> > been, Why allow that to begin with?
>
> There is no reason to allow this, especially since there have been
> reasonable alternatives proposed to the core group who wrote the present
> protocol, though they were ignored without serious discussion.
>
Am I that far off base on how I read the SRS proposal in how
SRS0 and SRS1 operate. How could the SRS1 have the SRS0 portion that
would pass verification if the SRS0 host hadn't forwarded it through to
the SRS1 host? Only the SRS0 host should be able to verify the hash so
if it receives a hash that doesn't verify drop it to the floor and stomp
on it a bit till it stops twitching.

> >
> > Forget SRS for a moment. I am not an open relay now; so, why
> > would I become
> > one now? Even if I receive a perfectly legit SRS1 address,
> > the resulting
> > SRS0 address -- while its validity is difficult to check; and
> > even if -- is,
> > for the purpose of this argument, still a non-local recipient.
>
> You _could_ check the SRS0 address with a CBV, but you are still,
> strictly speaking, operating a relay. It is a fairly trusted relay
> since the address has to pass two cryptographic checks done at two
> different sites, but it still is a relay. Even though it is fairly safe
> relay, it would be best if it did not exist at all.
>
This is exactly what I was mentioning above. Both the SRS0 and
SRS1 hosts are going to have their own crypto hash checks to perform and
only they can produce/verify them.

> >
> > I try and keep an open mind, of course. But I have yet to
> > hear a good reason
> > why I should suddenly 'open' relay mail for third parties --
> > however nice
> > folks they may be. :) If I were in the forwarding business,
> > like pobox, then
> > that would naturally change things.
> >
> > But, as it stands, I only accept SRS1 addresses that result
> > in a valid,
> > local SRS0 address (and, consequently, a in valid local
> > recipient). Since I
> > only ever send out SRS0 addresses with my own domains, I
> > expect to only see
> > such addresses return. In that context, the quoted "They reap
> > what they have
> > sewn" is quite applicable here: I only reap SRS0 addresses I
> > have sown.
> >
> > Regards,
> >
> > - Mark
>
> That is, IMHO, a very rational approach. David Woodhouse and I have
> worked on a proposal where MTA's only sent out SRS0 addresses, just like
> you do, and SPF is used differently so that it does _not_ require
> rewriting of the return address _anywhere_ in the mail chain. It also
> happens to be interoperable with the current SPF+SRS. I think there are
> better ways to do things than the current SRS scheme. I am afraid that
> the current SRS will stall adoption of SPF and give an undesired boost
> to CID and DK. That would be a real shame.
>
>
> --
>
> 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

----- Original Message -----
From: "Seth Goodman" <sethg@GoodmanAssociates.com>
To: <srs-discuss@v2.listbox.com>
Sent: Thursday, March 18, 2004 6:51 PM
Subject: RE: [srs-discuss] The open relay problem.


> That is, IMHO, a very rational approach. David Woodhouse and I
> have worked on a proposal where MTA's only sent out SRS0 addresses,
> just like you do, and SPF is used differently so that it does _not_
> require rewriting of the return address _anywhere_ in the mail chain.
> It also happens to be interoperable with the current SPF+SRS.

Would you care to restate that proposal? I'd be interested in hearing about
it.

Cheers,

- Mark

System Administrator Asarian-host.org

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

> -----Original Message-----
> From: owner-srs-discuss@v2.listbox.com
> [mailto:owner-srs-discuss@v2.listbox.com]On Behalf Of Mark
> Sent: Thursday, March 18, 2004 6:02 PM
> To: srs-discuss@v2.listbox.com
> Subject: Re: [srs-discuss] The open relay problem.

<...>

> Would you care to restate that proposal? I'd be interested in
> hearing about it.


I made a couple of changes to item 3 and the text wrapping in item 1 to
make things more readable. The functionality is the same.


Here it is in _very brief_ outline to give the overall flavor. Some
details, options and special cases are not included.


1) At the originating gateway MTA, create the following return path and
relay the message via SMTP:

MAIL FROM:<SRS0+HHH=TT=domain=local_part=originating_MTA_local_part@
originating_MTA_domain>

where

HHH is a SHA-1 hash computed over all the remaining
characters in the MAIL FROM: up to the ending >
prepended with the secret for the domain of the
originating gateway MTA

TT is a timestamp with resolution in days

domain is the domain part of the address the
originating MUA put in the Reply-To: field

local_part is the local part of the address the
originating MUA put in the Reply-To: field

originating_MTA_local_part is the local part of
the originating gateway MTA address

originating_MTA_domain is the domain part of
the originating gateway MTA address


2) At each SMTP-recipient, the following test is optional but strongly
recommended.

Do a PTR query on the IP of the SMTP-sender. If
the PTR query returns a result, extract the domain
name and do an SPF query for that domain. Evaluate
the result according to SPF rules with regard to the
SMTP-sender as a designated sender for its own domain
and accept or reject the message as appropriate. If
the PTR query returns a NULL result, some sites may
wish to reject the message as local policy. If not,
there are several fall-back methods to give the SMTP-
sender a chance to qualify as a designated sender
according to SPF.


3) If the SMTP-recipient is the final gateway MTA, it MUST perform the
following tests.

a) If the MAIL FROM: address is SRS0-signed, do an SPF
query on "domain". Evaluate the result with regard to
"originating_MTA_local_part@originating_MTA_domain"
as a designated sender and accept or reject the
message as appropriate.

b) If the message was not rejected and the MAIL FROM:
address is SRS0-signed, do a CBV with the MX for
"originating_MTA_domain" from the return-path as follows.
Issue a MAIL FROM:<> followed by a
RCPT TO:<SRS0+HHH=TT=domain=local_part=
originating_MTA_local_part@originating_MTA_domain>
and obtain the response. If the MX does not
return a recipient OK result, the MTA MAY make another
attempt using MAIL FROM:<postmaster@gateway-MTA-domain>
and the same RCPT TO: as above. If the MX does not
return a recipient OK result, the MTA SHOULD reject
the incoming message.

c) If the MAIL FROM: address is not SRS-signed, the MTA MAY
do a conventional CBV. If the CBV fails, the MTA SHOULD
reject the incoming message.




There is more detail and more options that can make this system
stronger, but this is the basic idea and it offers the same degree of
validation that SPF+SRS currently does. The basic system uses an SRS0
signature at the originating gateway MTA that protects the entire MAIL
FROM: line. This MAIL FROM: address is never changed in transit, so it
is compatible with existing systems today. SPF checks are optionally
done at each hop based on the rDNS result of the connecting IP rather
than the RHS of the MAIL FROM:. This is what allows us to avoid
rewriting, yet it still permits us to verify that the SMTP-sender who
has connected to us is a designated sender for their own domain. The
system handles DSN's exactly the same way they are done now, so there
are no additional relays created.

The final gateway MTA does more verification, since it is at highest
risk for being stuck with an undeliverable message. First, it attempts
a CBV to make sure that the message did indeed come from the originating
gateway MTA that appears in MAIL FROM:. If that originating gateway MTA
is SRS-aware, it will verify the SRS0 hash before returning recipient OK
and we have a high degree of confidence as to the source of the message.
If it is not SRS-aware, we at least know that address will accept a DSN.

If the originating gateway MTA is SRS-aware, it will have included both
the users original domain and its own domain. We can therefore do our
own SPF check to verify that the originating gateway MTA is a designated
sender for the domain the original user declares. We don't have to
trust that anyone else in the chain did this validation and we can
evaluate the SPF results according to local policy.

Comments are welcome.

--

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

>>>>> "Seth" == Seth Goodman
>>>>> "RE: The open relay problem."
>>>>> Fri, 19 Mar 2004 12:50:14 -0600

>> Would you care to restate that proposal? I'd be interested in
>> hearing about it.

Seth> Here it is in _very brief_ outline to give the overall
Seth> flavor. Some details, options and special cases are not
Seth> included.

Seth> 1) At the originating gateway MTA, create the following
Seth> return path and relay the message via SMTP:

Seth> MAIL
Seth> FROM:<SRS0+HHH=TT=domain=local_part=originating_MTA_local_part@originati
ng_MTA_domain>

Seth> where

Seth> HHH is a SHA-1 hash computed over all the remaining
Seth> characters in the MAIL FROM: up to the ending >
Seth> prepended with the secret for the domain of the
Seth> originating gateway MTA

Seth> TT is a timestamp with resolution in days

Seth> domain is the domain part of the address the
Seth> originating MUA put in the Reply-To: field

So the gateway MTA needs to look at the header in the payload?

Seth> local_part is the local part of the address the
Seth> originating MUA put in the Reply-To: field

So the gateway MTA needs to look at the header in the payload?

jam

> -----Original Message-----
> From: owner-srs-discuss@v2.listbox.com
> [mailto:owner-srs-discuss@v2.listbox.com]On Behalf Of Mark
> Sent: Thursday, March 18, 2004 6:02 PM
> To: srs-discuss@v2.listbox.com
> Subject: Re: [srs-discuss] The open relay problem.

<...>

> Would you care to restate that proposal? I'd be interested in
> hearing about it.


OK, one last try and I'll wait for comments. I made the descriptive
text at the end agree with the protocol steps.


Here it is in _very brief_ outline to give the overall flavor. Some
details, options and special cases are not included.


1) At the originating gateway MTA, create the following return path and
relay the message via SMTP:

MAIL FROM:<SRS0+HHH=TT=domain=local_part=originating_MTA_local_part@
originating_MTA_domain>

where

HHH is a SHA-1 hash computed over all the remaining
characters in the MAIL FROM: up to the ending >
prepended with the secret for the domain of the
originating gateway MTA

TT is a timestamp with resolution in days

domain is the domain part of the address the
originating MUA put in the Reply-To: field

local_part is the local part of the address the
originating MUA put in the Reply-To: field

originating_MTA_local_part is the local part of
the originating gateway MTA address

originating_MTA_domain is the domain part of
the originating gateway MTA address


2) At each SMTP-recipient, the following test is optional but strongly
recommended.

Do a PTR query on the IP of the SMTP-sender. If
the PTR query returns a result, extract the domain
name and do an SPF query for that domain. Evaluate
the result according to SPF rules with regard to the
SMTP-sender as a designated sender for its own domain
and accept or reject the message as appropriate. If
the PTR query returns a NULL result, some sites may
wish to reject the message as local policy. If not,
there are several fall-back methods to give the SMTP-
sender a chance to qualify as a designated sender
according to SPF.


3) If the SMTP-recipient is the final gateway MTA, it MUST perform the
following tests.

a) If the MAIL FROM: address is SRS0-signed, do an SPF
query on "domain". Evaluate the result with regard to
"originating_MTA_local_part@originating_MTA_domain"
as a designated sender and accept or reject the
message as appropriate.

b) If the message was not rejected and the MAIL FROM:
address is SRS0-signed, do a CBV with the MX for
"originating_MTA_domain" from the return-path as follows.
Issue a MAIL FROM:<> followed by a
RCPT TO:<SRS0+HHH=TT=domain=local_part=
originating_MTA_local_part@originating_MTA_domain>
and obtain the response. If the MX does not
return a recipient OK result, the MTA MAY make another
attempt using MAIL FROM:<postmaster@gateway-MTA-domain>
and the same RCPT TO: as above. If the MX does not
return a recipient OK result, the MTA SHOULD reject
the incoming message.

c) If the MAIL FROM: address is not SRS-signed, the MTA MAY
do a conventional CBV. If the CBV fails, the MTA SHOULD
reject the incoming message.




There is more detail and more options that can make this system
stronger, but this is the basic idea and it offers the same degree of
validation that SPF+SRS currently does. The basic system uses an SRS0
signature at the originating gateway MTA that protects the entire MAIL
FROM: line. This MAIL FROM: address is never changed in transit, so it
is compatible with existing systems today. SPF checks are optionally
done at each hop based on the rDNS result of the connecting IP rather
than the RHS of the MAIL FROM:. This is what allows us to avoid
rewriting, yet it still permits us to verify that the SMTP-sender who
has connected to us is a designated sender for their own domain. The
system handles DSN's exactly the same way they are done now, so there
are no additional relays created.

The final gateway MTA does more verification, since it is at highest
risk for being stuck with an undeliverable message. First, if the
originating gateway MTA was SRS-aware, it will have included both the
users original domain as well as its own domain and local-part. We can
therefore do our own SPF check to verify that the originating gateway
MTA is a designated sender for the domain the original user declares.
We don't have to trust that anyone else in the chain did this validation
and we can evaluate the SPF results according to local policy.

If the message passes the SPF check, we next attempt a CBV to make sure
that the message did indeed come from the originating gateway MTA that
appears in MAIL FROM: address. If that originating gateway MTA is
SRS-aware, it will verify the SRS0 hash before returning recipient OK
and we have a high degree of confidence as to the source of the message.
If it is not SRS-aware, we at least know that the return-path address
will accept a DSN.

Comments are welcome.

--

Seth Goodman

> -----Original Message-----
> From: owner-srs-discuss@v2.listbox.com
> [mailto:owner-srs-discuss@v2.listbox.com]On Behalf Of John A. Martin
> Sent: Friday, March 19, 2004 1:33 PM
> To: srs-discuss@v2.listbox.com
> Subject: [srs-discuss] Re: The open relay problem.
>
>
> >>>>> "Seth" == Seth Goodman
> >>>>> "RE: The open relay problem."
> >>>>> Fri, 19 Mar 2004 12:50:14 -0600
>
> >> Would you care to restate that proposal? I'd be interested in
> >> hearing about it.
>
> Seth> Here it is in _very brief_ outline to give the overall
> Seth> flavor. Some details, options and special cases are not
> Seth> included.
>
> Seth> 1) At the originating gateway MTA, create the following
> Seth> return path and relay the message via SMTP:
>
> Seth> MAIL
> Seth>
> FROM:<SRS0+HHH=TT=domain=local_part=originating_MTA_local_part
> @originati
> ng_MTA_domain>
>
> Seth> where
>
> Seth> HHH is a SHA-1 hash computed over all the remaining
> Seth> characters in the MAIL FROM: up to the ending >
> Seth> prepended with the secret for the domain of the
> Seth> originating gateway MTA
>
> Seth> TT is a timestamp with resolution in days
>
> Seth> domain is the domain part of the address the
> Seth> originating MUA put in the Reply-To: field
>
> So the gateway MTA needs to look at the header in the payload?

The originating gateway MTA is the first MTA to send the message on the
public internet. The MUA side of the gateway MTA is, by definition, a
private network and mail transfer may or may not be via SMTP. However
the message transfer from the MUA to the originating gateway MTA is
accomplished, the originating gateway MTA must make sure the MAIL FROM:
address meets SMTP requirements before relaying to the public internet.
If the private network transfers messages by some method other than
SMTP, the originating gateway MTA may well have to look into the message
headers to figure out what to put in the MAIL FROM: field. This is no
different from the current situation. If the private network uses SMTP
for message transfer, the originating gateway MTA could just rewrite the
MAIL FROM: address coming from the MUA, assuming the address it contains
meets local policy.


>
> Seth> local_part is the local part of the address the
> Seth> originating MUA put in the Reply-To: field
>
> So the gateway MTA needs to look at the header in the payload?

Same answer as above.

On Friday March 19, sethg@GoodmanAssociates.com wrote:
>
> Comments are welcome.


1/ I think you are suggesting that an SPF compliant MTA would use SRS
signed envelope-from addresses for *all* outgoing mail.

While this idea certainly has a lot of merits, I think it would
break a lot of subscriber-only mailing lists, which might cause
discontent among customers.

2/ I cannot see the point of the SPF lookup in 3a.
Given that you will always do a CBV is this lookup doesn't result
in a reject, I think you may as well do the CBV anyway.
If I am right in that, then the internal structure of the proposed
SRS address becomes irrelevant to anyone other than the issuing MTA.
So you may as well specify that it should be:

SRS-xxxxxxxx@mta-domain
where xxxxxxxx is some cookie that the mta @mta-domain understands

Have I misunderstood something?

NeilBrown

On Thursday March 18, admin@asarian-host.net wrote:
> ----- Original Message -----
> From: "Neil Brown" <neilb@cse.unsw.edu.au>
> To: "SRS-Discuss Forum" <srs-discuss@v2.listbox.com>
> Sent: Wednesday, March 17, 2004 11:16 PM
> Subject: [srs-discuss] The open relay problem.
>
> > So, I'm proposing that an MTA should only unwrap an SRS1 address and
> > forward on to the appropriate SRS0 address if the domain in the SRS0
> > address publishes a "spf" record which declared "+srs0", and that
> > MTAs which send SRS0 wrapped return addresses should declare that
> > fact by having "+srs0" in the spf record for each domain they
> > control.
>
> Regardless of whether SRS1 addresses are valid, my question has always been,
> Why relay at all? An open relay is simply this:
>
> "A host which, barring local .forward functionality, relays mail to
> non-local recipients, from non-authorized IP space."

An alternate, and arguably more practical definition might be that an
open relay is:

"A host which makes it's services available for spammers to
successfully deliver spam to other hosts."

Given that definition, SRS1 need not make you an open relay.

>
> I try and keep an open mind, of course. But I have yet to hear a good reason
> why I should suddenly 'open' relay mail for third parties -- however nice
> folks they may be. :) If I were in the forwarding business, like pobox, then
> that would naturally change things.

If you are not in the forwarding business, then you do not need to
know about SRS at all. You can ignore it completely. You don't need
to relay anything, openly or otherwise.

BUT: if you are in the relay business (whether large-scale or in small
amounts, and many of us are), then you obviously forward messages from
off-site to off-site, and it doesn't seem unreasonable to ask you to
forward any automatic replies (DSNs). But it would be nice to be sure
that you are only forwarding SRS0 to sites that understand SRS.

SRS combined with an SPF indication that "I understand SRS" makes this
possible and safe, and plays nicely with the rest of SPF.

Just to summarise the key issues of SRS here:

1/ a host that doesn't forward messages does not need to understand
SRS.
2/ a host that does forward messages must make sure that the MAIL FROM:
of the forwarded message has a domain part that it is responsible
for.
It *may* choose to use SRS to achieve this.
3/ A forwarding host that chooses to use SRS when forwarding must
apply the SRS transformation as described elsewhere but briefly
stated as:
SRS1+stuff@some.domain -> SRS1+stuff@my.domain
SRS0+stuff@some.domain -> SRS1+some.domain=stuff@my.domain
stuff@some.domain -> SRS0=xx=yy=some.domain=stuff@my.domain
[.Before accepting a message from an SRS address, the MTA *may*
confirm that the SRS0 domain advertises that it speaks SRS.]
4/ A forwarding host that chooses to use SRS and which receives a
message from <> and to an SRS0 address should check the validity (did I
create this?) and reject if invalid.
5/ A forwarding host that chooses to use SRS and which receives a
message from <> and to an SRS1 address should forward to the
corresponding SRS0 address *if-and-only-if* that domain of that
address advertises that it speaks SRS.

(The if-and-only-if clause in 5, and the [bracket] bit in 3 being my
proposal)

With this,
1/ only those who choose to forward need to forward. i.e. you only
need to relay SRS if you relay other things.
2/ When you do relay, you have good reason to believe that the
recipient is willing to receive the relay.
3/ MAIL FROM: addresses are clear-text for un-relayed messages.



>
> But, as it stands, I only accept SRS1 addresses that result in a valid,
> local SRS0 address (and, consequently, a in valid local recipient). Since I
> only ever send out SRS0 addresses with my own domains, I expect to only see
> such addresses return. In that context, the quoted "They reap what they have
> sewn" is quite applicable here: I only reap SRS0 addresses I have sown.

If you don't send out SRS1 addresses, I don't see the point of ever
accepting any SRS1 addresses. But I guess that's up to you.

NeilBrown

> -----Original Message-----
> From: owner-srs-discuss@v2.listbox.com
> [mailto:owner-srs-discuss@v2.listbox.com]On Behalf Of Neil Brown
> Sent: Sunday, March 21, 2004 8:11 PM
> To: srs-discuss@v2.listbox.com
> Subject: RE: [srs-discuss] The open relay problem.
>
>
> On Friday March 19, sethg@GoodmanAssociates.com wrote:
> >
> > Comments are welcome.
>
>
> 1/ I think you are suggesting that an SPF compliant MTA would use SRS
> signed envelope-from addresses for *all* outgoing mail.
>
> While this idea certainly has a lot of merits, I think it would
> break a lot of subscriber-only mailing lists, which might cause
> discontent among customers.

Thanks very much for the comments.

You are correct that I am suggesting all outgoing mail be SRS0 signed.
This certainly would break some mailing lists, but it would break them
exactly in the same way as the existing SRS scheme if a message goes
through a forwarder. The forwarder will rewrite the "plain" return-path
into an SRS0 one and they have created the same problem.

I can only think of one solution for this but maybe there are others:
don't send SRS0-signed mail to lists that don't grok this format. At
least you can configure this from your own site. The present SPF+SRS
scheme has to deal with exactly the same problem, except that the
rewriting is done at another site that you presumably have less control
over.


>
> 2/ I cannot see the point of the SPF lookup in 3a.
> Given that you will always do a CBV is this lookup doesn't result
> in a reject, I think you may as well do the CBV anyway.
> If I am right in that, then the internal structure of the proposed
> SRS address becomes irrelevant to anyone other than the
> issuing MTA.
> So you may as well specify that it should be:
>
> SRS-xxxxxxxx@mta-domain
> where xxxxxxxx is some cookie that the mta @mta-domain understands
>
> Have I misunderstood something?

Perhaps, but it is still a reasonable question. The SPF query and the
CBV have complementary functions. The SPF lookup is to verify that the
machine that _claims_ to have sent out the message is designated by the
domain owner as a legitimate sender. Once you are satisfied that this
is true, the CBV makes sure that this MTA actually _was_ the source of
the message as claimed. As a side benefit, you also know whether they
will accept a DSN. Since some messages will presumably fail the SPF
check, and many more will fail the locally configured tests that precede
the SPF check, you only do CBV's on messages that pass all the other
tests.

In the current SPF scheme, if the first forwarding host does not do the
SPF checks properly or interprets them in a way that does not suit you,
the whole scheme breaks. In fact, any host along the message path that
does not do SPF checks becomes a possible injection point for forgeries.
Since you have no control over how other sites implement SPF, the
present SPF+SRS system is only as good as the weakest site along the
message path.

By preserving the local-part of the originating gateway MTA address in
the SRS0 address, you insure that the destination gateway MTA can always
do an SPF check on the original sender regardless of the message path.
This does not prevent intermediate hosts from doing SPF checks and
rejecting forgeries, it just means that you don't have to depend on
their having done it to your satisfaction. The system continues to work
regardless of what any intermediate site does.

Did I answer your questions adequately?

--

Seth Goodman

> -----Original Message-----
> From: owner-srs-discuss@v2.listbox.com
> [mailto:owner-srs-discuss@v2.listbox.com]On Behalf Of Neil Brown
> Sent: Sunday, March 21, 2004 8:11 PM
> To: srs-discuss@v2.listbox.com
> Subject: RE: [srs-discuss] The open relay problem.
>
>
> On Friday March 19, sethg@GoodmanAssociates.com wrote:
> >
> > Comments are welcome.
>
>
> 1/ I think you are suggesting that an SPF compliant MTA would use SRS
> signed envelope-from addresses for *all* outgoing mail.
>
> While this idea certainly has a lot of merits ...

One of the primary benefits of SRS0-signing _all_ outgoing messages,
that I failed to mention before, is that it gives you a bulletproof
method to reject bounce spam. The only addresses that you will see
legitimate DSN's returned to are the ones that you put in MAIL FROM:,
which are SRS0 signed addresses with hashes that validate. If a DSN
comes back to you with a hash that does not verify, or without an SRS0
signature, you can simply reject it right after RCPT TO: and not waste
your bandwidth.

People and viruses/worms can still forge your domain name. Unless the
whole world implements SPF, you will likely still get some hate mail to
your postmaster address. But you _can_ confidently reject all the bogus
bounces and viruses that you would otherwise have to deal with.

--

Seth Goodman

On Thu, 18 Mar 2004, Neil Brown wrote:

>
> Hi,
> I'm new and have been pouring over the archives of the spf and srs
> lists trying to get up to speed.
>
> I would like to make comment about the partial-open-relay problem.
>
> i.e. that fact that if an SRS aware MTA willing forwards SRS1
> addresses after unwrapping to SRS0, they run the risk for forwarding
> junk-mail to a wildcard address on the target domain.
>
> I agree that while this may not be an enormous problem, it is a real
> problem (being the recipient of wildcard mail to atleast one domain
> myself).
[SNIP]
> So, I'm proposing that an MTA should only unwrap an SRS1 address and
> forward on to the appropriate SRS0 address if the domain in the SRS0
> address publishes a "spf" record which declared "+srs0", and that
> MTAs which send SRS0 wrapped return addresses should declare that
> fact by having "+srs0" in the spf record for each domain they
> control.
>
> Comments?

Yes, it's a very real problem, _IF_ and you assume that you can easily
generate the hash in the SRS1 address without knowing the host secret.

You can't.

Therefore this isn't a problem.

It hasn't been a problem since ... version 0.27 (see the ChangeLog in the
Mail::SRS documentation). That was a long time ago.

S.

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

On Tuesday March 23, spf@anarres.org wrote:
>
> Yes, it's a very real problem, _IF_ and you assume that you can easily
> generate the hash in the SRS1 address without knowing the host secret.
>
> You can't.
>
> Therefore this isn't a problem.
>
> It hasn't been a problem since ... version 0.27 (see the ChangeLog in the
> Mail::SRS documentation). That was a long time ago.
>

Ahhh... SRS1 how has a second signature

I was going by the information at
http://spf.pobox.com/srs.html

which appears to be a bit out-of-date.

Thank you for clearing this up for me.

NeilBrown

On Monday March 22, sethg@GoodmanAssociates.com wrote:
> > While this idea certainly has a lot of merits, I think it would
> > break a lot of subscriber-only mailing lists, which might cause
> > discontent among customers.
>
> Thanks very much for the comments.
>
> You are correct that I am suggesting all outgoing mail be SRS0 signed.
> This certainly would break some mailing lists, but it would break them
> exactly in the same way as the existing SRS scheme if a message goes
> through a forwarder. The forwarder will rewrite the "plain" return-path
> into an SRS0 one and they have created the same problem.

I don't think the existing SRS scheme hurts mailing lists at all.

When I send to a mailing list, it doesn't go through a forwarder. It
goes straight to the list.

Forwarders are set up by and/or for the recipient. The recipient
(presumably) knows about them and should be prepared to handle the
fact that forwarded messages might look a bit different from direct
messages.

Infact, I'm leaning toward the idea of leveraging this fact to overcome
what I see as the biggest problem with SPF.
That problem is that mail forwarded by a non-SRS aware forwarder might
be assessed wrongly by SPF.
The possibly solution would be to have our customers register any
sites that they expect forwarded mail from, and to explicitly
whitelist those.

>
> >
> > 2/ I cannot see the point of the SPF lookup in 3a.
> > Given that you will always do a CBV is this lookup doesn't result
> > in a reject, I think you may as well do the CBV anyway.
> > If I am right in that, then the internal structure of the proposed
> > SRS address becomes irrelevant to anyone other than the
> > issuing MTA.
> > So you may as well specify that it should be:
> >
> > SRS-xxxxxxxx@mta-domain
> > where xxxxxxxx is some cookie that the mta @mta-domain understands
> >
> > Have I misunderstood something?
>
> Perhaps, but it is still a reasonable question. The SPF query and the
> CBV have complementary functions. The SPF lookup is to verify that the
> machine that _claims_ to have sent out the message is designated by the
> domain owner as a legitimate sender. Once you are satisfied that this
> is true, the CBV makes sure that this MTA actually _was_ the source of
> the message as claimed. As a side benefit, you also know whether they
> will accept a DSN. Since some messages will presumably fail the SPF
> check, and many more will fail the locally configured tests that precede
> the SPF check, you only do CBV's on messages that pass all the other
> tests.

Thanks. That makes it a bit clearer, but I'll need to go over it a
few more times myself I think...

>
> In the current SPF scheme, if the first forwarding host does not do the
> SPF checks properly or interprets them in a way that does not suit you,
> the whole scheme breaks. In fact, any host along the message path that
> does not do SPF checks becomes a possible injection point for forgeries.
> Since you have no control over how other sites implement SPF, the
> present SPF+SRS system is only as good as the weakest site along the
> message path.

It all depends on how you view SPF.
SPF is not a spam-control system as such. It is a way of
communication information from the owner of a domain to the recipient
of an Email.
By far the strongest statement that can be made by SPF is "Pass",
which says "I'm willing to stand by the authenticity of this address
and to accompanying email".

Thus it can be use to ease the path of genuine mail through the
gauntlet of spam checkers. With that in place, you can be more harsh
with your heuristic spam/virus checkers.
For example, I use something similar to SPF guessing (I haven't
implemented real SPF yet) to mark an item as questionable, and then if
I find an executable extension on a MIME component, then I reject the
mail item (as it probably is a virus). This drops maybe 10% of our
incoming mail but still lets a lot of genuine attachments through.

So SPF doesn't control junk. It rather gives me the "right" to use
tighter junk controls, and (once it becomes a standard) allows me to
say to people whose mail I reject "Get with the program!!"

>
> By preserving the local-part of the originating gateway MTA address in
> the SRS0 address, you insure that the destination gateway MTA can always
> do an SPF check on the original sender regardless of the message path.
> This does not prevent intermediate hosts from doing SPF checks and
> rejecting forgeries, it just means that you don't have to depend on
> their having done it to your satisfaction. The system continues to work
> regardless of what any intermediate site does.
>

But I don't think that a "return-address-is-valid" gives me as much
information as an "SPF returns Pass" does. In particular, there is no
guarantee that the message was actually sent by anyone associated with
that return address. How easy is it for a criminal to get a valid
innocent return address? I'm not sure. But once they have it, they
can use it to send lots of spam.

> Did I answer your questions adequately?

It certainly helpped, thanks.

NeilBrown

> From: Neil Brown
> Sent: Tuesday, March 23, 2004 6:39 PM
>
>
> On Monday March 22, sethg@GoodmanAssociates.com wrote:
> > > While this idea certainly has a lot of merits, I think it would
> > > break a lot of subscriber-only mailing lists, which might cause
> > > discontent among customers.
> >
> > Thanks very much for the comments.
> >
> > You are correct that I am suggesting all outgoing mail be
> > SRS0 signed.
> > This certainly would break some mailing lists, but it would
> > break them
> > exactly in the same way as the existing SRS scheme if a message goes
> > through a forwarder. The forwarder will rewrite the
> > "plain" return-path
> > into an SRS0 one and they have created the same problem.
>
> I don't think the existing SRS scheme hurts mailing lists at all.
>
> When I send to a mailing list, it doesn't go through a forwarder. It
> goes straight to the list.

That's the case for most of us, but not everyone. One case is a domain
on a commercial hosting service whose outgoing mail server is shared by
many domains. Each domain lists the common SMTP server as a permitted
sender in its SPF record. If the hosting service implements SRS, the
hosting service's SMTP server must rewrite the MAIL FROM: into an SRS0
address because the return-path domain name is different from the domain
name of the SMTP server, thus it is a forward. This is a common enough
situation that it has to be considered.

Unfortunately, whitelists of non-SRS compliant recipients is about the
only solution that I can think of, but this has some very bad
consequences. First, I think it will be very hard to convince large
commercial hosting services that they have to give every customer the
ability to list addresses to which they don't rewrite MAIL FROM:. Even
more importantly, once a forwarder no longer rewrites _every_ forwarded
message, they must then accept non-SRS0 signed DSN's. Unfortunately,
those DSN's won't necessarily come back from the same address that you
sent the mail to, so your whitelist can't be used as a filter. You have
now opened up the floodgates to the effects of a joe-job that SPF was
designed to prevent.


>
> Forwarders are set up by and/or for the recipient. The recipient
> (presumably) knows about them and should be prepared to handle the
> fact that forwarded messages might look a bit different from direct
> messages.
>
> Infact, I'm leaning toward the idea of leveraging this fact
> to overcome
> what I see as the biggest problem with SPF.
> That problem is that mail forwarded by a non-SRS aware forwarder might
> be assessed wrongly by SPF.
> The possibly solution would be to have our customers register any
> sites that they expect forwarded mail from, and to explicitly
> whitelist those.

If you do that, you will lose the ability to reject bogus DSN's since
some of the outgoing mail that you forward for a particular domain does
not have the SRS0 hash for you to verify.


> > >
> > > 2/ I cannot see the point of the SPF lookup in 3a.
> > > Given that you will always do a CBV is this lookup
> > > doesn't result
> > > in a reject, I think you may as well do the CBV anyway.
> > > If I am right in that, then the internal structure of
> > > the proposed
> > > SRS address becomes irrelevant to anyone other than the
> > > issuing MTA.
> > > So you may as well specify that it should be:
> > >
> > > SRS-xxxxxxxx@mta-domain
> > > where xxxxxxxx is some cookie that the mta @mta-domain
> > > understands
> > >
> > > Have I misunderstood something?
> >
> > Perhaps, but it is still a reasonable question. The SPF
> > query and the
> > CBV have complementary functions. The SPF lookup is to
> > verify that the
> > machine that _claims_ to have sent out the message is
> > designated by the
> > domain owner as a legitimate sender. Once you are
> > satisfied that this
> > is true, the CBV makes sure that this MTA actually _was_
> > the source of
> > the message as claimed. As a side benefit, you also know
> > whether they
> > will accept a DSN. Since some messages will presumably fail the SPF
> > check, and many more will fail the locally configured tests
> > that precede
> > the SPF check, you only do CBV's on messages that pass all the other
> > tests.
>
> Thanks. That makes it a bit clearer, but I'll need to go over it a
> few more times myself I think...

Please do. There are a few exceptions, of course. For instance, you
wouldn't SRS0 sign mail that you received as a secondary MX that did not
have an SRS MAIL FROM: when you relayed it to the primary MX. That's a
pretty special case. Come to think of it, I don't know what the current
SRS implementation does for relays from a secondary to a primary MX. I
don't see it as a problem, I just don't know what they have in mind.

>
> >
> > In the current SPF scheme, if the first forwarding host
> > does not do the
> > SPF checks properly or interprets them in a way that does
> > not suit you,
> > the whole scheme breaks. In fact, any host along the
> > message path that
> > does not do SPF checks becomes a possible injection point
> > for forgeries.
> > Since you have no control over how other sites implement SPF, the
> > present SPF+SRS system is only as good as the weakest site along the
> > message path.
>
> It all depends on how you view SPF.
> SPF is not a spam-control system as such. It is a way of
> communication information from the owner of a domain to the recipient
> of an Email.
> By far the strongest statement that can be made by SPF is "Pass",
> which says "I'm willing to stand by the authenticity of this address
> and to accompanying email".

The point I was trying to make is that with the present scheme, unless
_everyone_ along the message path does SPF checks and is not overly
permissive in what they accept, an SPF pass at the receiving end may
wind up telling you exactly nothing. The only thing that you can be
sure of is that the previous hop was a designated sender for _their_
domain. You _cannot_ assert that the originating gateway MTA was a
designated sender for the originating domain unless you know the whole
message path and you know that every host on the path implements SPF
properly.

With the modified scheme that includes the local-part of the originating
gateway MTA address, the final recipient can do an SPF check with
respect to the originating domain and the originating gateway MTA as a
designated sender for that domain. Only then can you make the statement
that you quoted above.

<...>

> >
> > By preserving the local-part of the originating gateway MTA
> > address in
> > the SRS0 address, you insure that the destination gateway
> > MTA can always
> > do an SPF check on the original sender regardless of the
> > message path.
> > This does not prevent intermediate hosts from doing SPF checks and
> > rejecting forgeries, it just means that you don't have to depend on
> > their having done it to your satisfaction. The system
> > continues to work
> > regardless of what any intermediate site does.
> >
>
> But I don't think that a "return-address-is-valid" gives me as much
> information as an "SPF returns Pass" does. In particular, there is no
> guarantee that the message was actually sent by anyone associated with
> that return address. How easy is it for a criminal to get a valid
> innocent return address? I'm not sure. But once they have it, they
> can use it to send lots of spam.

SPF cannot validate an individual user, only domains. The modified
scheme does have the same limitation. Let me compare the two approaches
again. The modified scheme allows the destination gateway MTA to verify
three specific statements:

1) The originating gateway MTA is a designated sender for the domain
inside the return-path.

2) The originating gateway MTA did actually send the message that you
just received.

3) The originating gateway MTA will accept a DSN to the return-path.

The current SPF scheme can verify the first two statements IFF every
host along the message path implements SPF+SRS properly. If any host
along the path does not implement SPF+SRS properly, an SRS pass at the
receiving end does not verify the first two statements. All it can tell
you is that the SMTP-sender that handed you the message was a designated
sender for _its_ domain. What is worse is that you cannot tell when
this is the situation. If you add a CBV to your local policy as a
supplement to the present SPF+SRS scheme, you can verify the second and
third statements, but there is no way for you to verify the first
statement. The only way for you as a final recipient to be confident
that an SPF pass verifies the first statement is if you trust that every
host along the path implemented SPF properly. That is a serious, if not
fatal, flaw in the present scheme.

--

Seth Goodman

On Tuesday March 23, sethg@GoodmanAssociates.com wrote:
> >
> > When I send to a mailing list, it doesn't go through a forwarder. It
> > goes straight to the list.
>
> That's the case for most of us, but not everyone. One case is a domain
> on a commercial hosting service whose outgoing mail server is shared by
> many domains. Each domain lists the common SMTP server as a permitted
> sender in its SPF record. If the hosting service implements SRS, the
> hosting service's SMTP server must rewrite the MAIL FROM: into an SRS0
> address because the return-path domain name is different from the domain
> name of the SMTP server, thus it is a forward. This is a common enough
> situation that it has to be considered.

I don't see this.
You only *have* to rewrite the MAIL FROM: if you are sending out using
an IP address that the owner of the domain in the MAIL FROM: has not
authorised using SPF.
But in your example, you say that each domain has authorised that SMTP
server via SPF. So no rewriting is needed.
It has nothing (directly) to do with the domain that the SMTP server
is in.

>
> Unfortunately, whitelists of non-SRS compliant recipients is about the
> only solution that I can think of, but this has some very bad
> consequences. First, I think it will be very hard to convince large
> commercial hosting services that they have to give every customer the
> ability to list addresses to which they don't rewrite MAIL FROM:. Even
> more importantly, once a forwarder no longer rewrites _every_ forwarded
> message, they must then accept non-SRS0 signed DSN's. Unfortunately,
> those DSN's won't necessarily come back from the same address that you
> sent the mail to, so your whitelist can't be used as a filter. You have
> now opened up the floodgates to the effects of a joe-job that SPF was
> designed to prevent.

I am not protected from joe-jobs just because I implement SPF. I am
only protected if everyone else implements SPF (and the more that do,
the more I am protected).

Yes. DSN's are a problem that SPF doesn't help with.
Universal SRS would help, but I believe the cost is too high.

There are two features that SPF helps provide I believe:
1/ The MAIL FROM: address can be safely used as an address for
bounces.
2/ The MAIL FROM: address can be used to reliably identify the sender,
and so can be tested against personal whitelists and blacklists.

Universal SRS doesn't help a lot with (2) as it doesn't provide the
recipient an easy way to determine if the address is a probable sender
of the mail item.

The problem of identifying bounces to faked email, while very real, is
separate from SPF.

I think the idea of putting a crypto-cookie in the headers of all
outgoing mail is worth pursuing. I think it has been mentioned on one
of these lists before, but I'm not sure if there was much conclusion.

While the absence of a crypto-cookie does not guarantee a bad bounce
(any more than "SPF returns Fail" guarantees a bad message), it's
presence does strongly indicate a good bounce (much like "SPF returns
Pass") and so other heuristics can be more aggressive at minimal cost.


>
>
> >
> > Forwarders are set up by and/or for the recipient. The recipient
> > (presumably) knows about them and should be prepared to handle the
> > fact that forwarded messages might look a bit different from direct
> > messages.
> >
> > Infact, I'm leaning toward the idea of leveraging this fact
> > to overcome
> > what I see as the biggest problem with SPF.
> > That problem is that mail forwarded by a non-SRS aware forwarder might
> > be assessed wrongly by SPF.
> > The possibly solution would be to have our customers register any
> > sites that they expect forwarded mail from, and to explicitly
> > whitelist those.
>
> If you do that, you will lose the ability to reject bogus DSN's since
> some of the outgoing mail that you forward for a particular domain does
> not have the SRS0 hash for you to verify.
>

I think you mis-understood me.
Let me be more specific.

Mail to neil@brown.name gets forwarded to neilb@cse.unsw.edu.au.
The managers of brown.name don't use SRS or support SPF.
So the mailserver at cse.unsw.edu.au is likely to get an SMTP
connection from a host associated with brown.name (typically
mx*.nic.anme) with MAIL FROM: <anybody@any.where>
I would register with the cse mail server that I am expecting mail
to be forwarded from neil@brown.name, and if it is receiving mail from
somewhere such that SPF is returning other than 'Pass', and it sees a
"RCPT TO:<neilb@cse.unsw.edu.au>", it will retry the SPF lookup with a
responsible sender of neil@brown.name. Though brown.name doesn't have
an SPF record, the standard guess will let this though with a higher
SPF rating.

This has nothing to do with me forwarding mail with SRS0, or with
rejecting bogus DSN's (which I claim above, SPF doesn't help with
anyway).

NeilBrown

On Wed, 2004-03-24 at 16:17 +1100, Neil Brown wrote:
> I think the idea of putting a crypto-cookie in the headers of all
> outgoing mail is worth pursuing. I think it has been mentioned on one
> of these lists before, but I'm not sure if there was much conclusion.

I suspect that too many mailers return bounces without enough of the
original message included. I asked if anyone had numbers to confirm or
refute that, but nobody obliged.

That was about when the conversation fizzled out, and I opted to put the
cookie in the reverse-path instead, where its absence _does_ guarantee a
bad bounce. This has one or two minor disadvantages but they aren't
significant enough to be a problem to me. YMMV.

There are few enough people filtering on reverse-path that it seems
reasonable to expect them to implement fuzzy-matching of SRS addresses
_if_ they care enough. Mostly they tend to be using it for 'soft'
heuristics like whitelisting. The only one which has given me pause for
thought has been the occasional subscriber-only mailing list which
checks the reverse-path instead of the From: address as most list
manager software does. I haven't ever experienced that but I've been
told it exists.

But again, it's not very common. Asking those people to do
fuzzy-matching of SRS0 addresses if they want to fix their filters is a
much less onerous request than asking the _whole_ world to do SRS for
us. A much more simple request, and made of far fewer people.

--
dwmw2

On Tue, 23 Mar 2004, Seth Goodman wrote:

> Please do. There are a few exceptions, of course. For instance, you
> wouldn't SRS0 sign mail that you received as a secondary MX that did not
> have an SRS MAIL FROM: when you relayed it to the primary MX. That's a
> pretty special case. Come to think of it, I don't know what the current
> SRS implementation does for relays from a secondary to a primary MX. I
> don't see it as a problem, I just don't know what they have in mind.

SRS is to be performed only when the address is actually rewritten by a
forwarding mechanism. This does not happen on a secondary MX. Therefore
this is not currently an issue. This problem only arises for people who
have implemented SRS to do unconditional rewriting of all (or too much)
mail.

S.

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