RE: The open relay problem.

> From: [email protected]
> Sent: Wednesday, March 24, 2004 4:30 PM
>
>
> On Wed, 24 Mar 2004, Seth Goodman wrote:
>
> > 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.
>
> Classical game theory would argue that if such a forwarder
> was performing
> SPF incorrectly, it would be treated exactly as if it were a source of
> spam in its own right. Indeed, the two are always
> indistinguishable. It is
> therefore to be assumed that any valid forwarder will attempt
> to act in
> its own best interest and perform SPF correctly.

Thank you for your reply.  I am unfamiliar with classical game theory,
but I trust your assertion.  Being more comfortable with a statistical
approach, I consider that there will be a stochastic variation in the
quality of implementations and local policy across a large number of
sites.  Over the very long term and taken as an ensemble average, I
agree with your statements.  However, it is not applicable for a
particular site at any specific instant in time.

Unfortunately, not every SPF implementation will be correct and perfect.
Some SPF local policies will make more sense than others.  The most
broken implementations will likely be abused and become listed as spam
sources.  However, until a site is actually abused, they will continue
to operate despite any flawed SPF assertions that they pass on.

Trusting that another site has done SPF checks to _your_ satisfaction
simply because they are not blacklisted does not sound like a reasonable
assumption.  Which blacklists are used and whether they are used at all
is a matter of local policy at each forwarder, so there is no assurance
that even a blacklisted site will be denied SMTP access to the next hop.
Until you receive all the message headers, you don't know how many or
which forwarders handled the message.  Under these conditions, what is
the basis for trusting the return-path before the DATA stage?  I would
assert that unless the SMTP-client is the originating gateway MTA,
trusting the return-path with the current SPF+SRS scheme requires trust
in parties whose identities are unknown to you at the time you have to
make the decision.

On the other hand, if you provide the final recipient with the
information they need to do the verification themselves before the DATA
stage, you don't have to depend on someone else's implementation to be
correct.  The final recipient can verify the return path information
themselves or trust the forwarders as they see fit.  Given the
environment, I suggest that "trust but verify" is a reasonable behavior
for a site.  Right now, the return-path does not carry sufficient
information for the destination gateway MTA to verify it.

My suggestion to remedy this is to SRS0 sign all outgoing mail and
include the originating gateway MTA local-part as part of the address.

--

Seth Goodman