RE: The open relay problem.

> From: Neil Brown
> Sent: Tuesday, March 23, 2004 11:18 PM
>
>
> On Tuesday March 23, [email protected] 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.

Ooops (really big oops)!  Rewriting is not necessary in this case, so the
example that I gave is bad.  It admittedly would be pretty unusual to have
mail forwarded to a mailing list, though not impossible.  My proposal would
indeed send SRS0-signed MAIL FROM: addresses to _all_ mailing lists and this
would break some of them.

It doesn't appear that many mailing lists use the MAIL FROM: address rather
than the From: header to qualify posts, so I don't think this is a major
source of breakage.  I have no idea of the actual number of lists that would
be broken by this, but my personal experience suggests that it would be
relatively few.  If anyone has any idea of the total number or percentage of
mailing lists that operate this way and how difficult it would be for them
to change to the From: header, that would be useful information.

Therefore you are correct, I cannot claim that the proposed alternate scheme
causes _no_ breakage, but only that it causes a miniscule amount of breakage
compared to the present SPF+SRS.  Getting a few mailing lists to change
their logic is minor compared to convincing every forwarder to do SRS1
rewriting and dealing with forwarders who don't.


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

Joe-jobs are bad for two reasons.  First, it harms your reputation and is
akin to libel.  Secondly, it typically results in a flood of bounces to your
domain, which are a real nuisance.  I agree that protection from joe-jobs
will increase along with SPF adoption.  However, unless SPF adoption reaches
100%, there will continue to be successful joe-jobs that will result in lots
of bounces.  My alternate proposal gives you the same amount of protection
against joe-jobs that SPF currently does, because it does an SPF check at
every hop, but it also protects you from the resulting bounces.  The
protection from bounces is virtually air-tight and you get it today, without
requiring anyone else to adopt anything.


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

SRS signing of all outgoing mail would do more than help,  it rejects all
bogus DSN's.  I'm not sure why you say the cost is too high.  The cost is
certainly much lower than requiring all forwarders to do SRS1 rewriting and
dealing with the reality that they won't all comply.  If you don't find
_that_ cost too high, isn't a scheme that has a lower cost and provides more
benefit preferable?


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

Just SRS signing outgoing messages does not help with this, but including
the originating gateway MTA local-part in the SRS signature does.  As the
destination gateway MTA, you can then do an SPF check on the original
sender's domain and validate the originating gateway MTA as a permitted
sender.  Furthermore, you can interpret the SPF result according to _your_
SPF policy.

With the present SPF+SRS, if there is a forwarder, you have to trust that
the forwarder did the SPF check properly and you have to accept their local
SPF policy.  Since you, in general, have no way of knowing either of these,
you can't know how much trust to put in a particular forwarder's assertion
of your point #2 above.  That is a key limitation of the present SPF+SRS
scheme.  The alternate scheme that I proposed does not suffer from this
since the destination gateway MTA has all the tools it needs to verify the
mail source itself.


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

What you are saying is that by design, the present SPF+SRS does not prevent
this type of abuse.  The alternate scheme that I proposed does solve this
problem as well as achieve all the other benefits of 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.

The presence of a crypto cookie only tells you something if you can verify
that it is valid.  In addition, you really want to verify it before the DATA
stage of the SMTP session, so the mail headers are not the best place for
it.  That's the motivation for proposing a verifiable crypto cookie in the
MAIL FROM: of all outgoing mail.  There are many possible ways to generate
and validate such a cookie, but two general approaches seem most promising:
a one-way hash plus a CBV or a private key signature with public key
verification.  The present proposal that I posted uses a SHA-1 hash as a
crypto cookie, so it requires a CBV for the original sender verify it.

If doing CBV's is a deal-breaker, it is feasible to use a private key
signature as a crypto cookie that can be verified through a public key
published in the DNS.  This avoids CBV's, but puts considerable
computational overhead on an SMTP server.  I am somewhat agnostic on this
issue.  However, the anti-spam community has long advocated putting more
burden on mail senders than on mail recipients as a disincentive to
spamming.  That is why I posted the CBV version of the modified scheme as
opposed to the private/public key version.  It is conceivable for both
methods to coexist, though I don't advocate that.  That is, if a site
doesn't want callbacks, it does private key signing and publishes a public
key for verification.  We would simply need a way to distinguish which
method was used.


<...>

> > > 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 [email protected] gets forwarded to [email protected].
> 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: <[email protected]>
> I would register with the cse mail server that I am expecting mail
> to be forwarded from [email protected], and if it is receiving mail from
> somewhere such that SPF is returning other than 'Pass', and it sees a
> "RCPT TO:<[email protected]>", it will retry the SPF lookup with a
> responsible sender of [email protected].  Though brown.name doesn't have
> an SPF record, the standard guess will let this though with a higher
> SPF rating.

I did misunderstand, so thanks for clearing that up.  I didn't realize that
the whitelist was an alternate source of domains to do an SPF query on.
Your proposal should work as well as SPF-guess works.  That is, it will
often get it right, but not always.  That's a whole lot better than always
getting it wrong for non-SPF forwarding sites, so it sounds like a
reasonable way to configure things.

Of course, I should point out that the alternate proposal does not require
rewriting and your case above would be handled without any whitelisting.
According to the proposal, when an SMTP-client connects to your SMTP-server,
that triggers a rDNS lookup, a SPF query on the RHS of the result and a SPF
test on the SMTP-client.  If there is no SPF record, SPF-guess would
automatically be invoked, so it would do exactly what you suggested without
a whitelist.

If the SMTP-client domain has a SPF record, you can now trust that it is a
designated sender for its domain.  If there were any forwarders, that is
really all you can trust and you can't assert much about the original source
of the message.  At this point, you are in exactly the same state as with
the existing SPF scheme.  If all you care about is whether you can send a
DSN, you can probably stop here.

However, if you want some assurance that MAIL FROM: really represents where
the mail came from, unless the SMTP-client is the originating gateway MTA,
you need to do a few more tests.  If MAIL FROM: contains a SRS signed
address with the originating gateway MTA local-part, you could then do a SPF
query on the sender's domain to validate the originating gateway MTA as a
designated sender.  If it passes, you now trust that the _claimed_
originating gateway MTA is a designated sender for the _claimed_ sender
domain.  Finally, you do a CBV to verify that the _claimed_ originating
gateway MTA was the actual source of the message.  This allows you to trust
the return path, even in the presence of forwarding.

--

Seth Goodman