Subject: RE: Drive Towards Consensus [was Re: On Extensibility in MARID Records]

From: "Jim Lyon" <[email-masked]>
Date: Fri, 18 Jun 2004 15:42:09 -0700

As requested by the cochairs, here are two more examples of scenarios
for which the SPF syntax is insufficient.

My initial scenario (feedback tied to individual mechanisms, xxx) kicked
off the thread.
The second scenario deals with reputation tied to individual mechanisms.
The third scenario deals with message types tied to individual
mechanisms.

Reputations Tied to Individual Mechanisms 
----------- ---- -- ---------- ----------

(This is mostly a repeat of xxx)

Suppose I have a small domain with no reputation.  Suppose I'm a
customer of both MSN and Comcast, and I send some of my outbound mail
through MSN's mail servers, and some through Comcast's mail servers.  As
things currently stand, I'd publish a MARID record like:
    v=spf1 +indirect:msn.com +indirect:comcast.com -all

This authenticates me very well (assuming that MSN and Comcast each do a
sufficient job of policing their internal networks to keep other
customers from masquerading as me).

When we get into the question of reputation, the argument goes something
like:  If you get mail from me through MSN's mail servers, you should
believe it's not spam because MSN does a good job of keeping its
customers from sending spam.  Similarly, if you get mail from me through
Comcasts's mail servers.  The degree to which you as a receiver believe
my mail is not spam is exactly a function of one of my ISP's
reputations.

Using invented syntax, I could say something like:
    v=spf1 +indirect:msn.com/targetrep +indirect:comcast.com/targetrep
-all
which gets the point across nicely.

Contrast this with the case of hotmail's record. Hotmail has more
address ranges for outgoing servers than fits into a single DNS record,
even using SPF syntax. So they publish something like:
    v=spf1 +indirect:a.hotmail.com +indirect:b.hotmail.com
+indirect:c.hotmail.com -all

In this case, the indirections are a mere implementation detail, and
receivers shouldn't attempt to read anything into the fact that they
received a message from the "b" list of servers instead of the "a" list.

As a separate example, consider a domain that sends a lot of spam,
through its own servers. It also sends non-spam, indirected through
Comcast.  It may well publish a MARID record like:
    v=spf1 +mx +indirect:comcast.com/targetrep -all
So, if you get mail directly from this domain's servers, the domain's
lousy reputation applies. If you get mail from Comcast's servers,
Comcast's reputation applies. (This example sidesteps the question of
whether some vigilantes might want to reject a domain's identifiably
legitimate mail because it also sends spam -- a question I don't want to
go into right now).

Message Types Tied to Individual Mechanisms
------- ----- ---- -- ---------- ----------

Many domains send both non-bulk and bulk mail, generally through very
different parts of their organization.  It may be useful to have
annotations on an SPF mechanism that describe the kinds of mail they
send.  For example:
    v=spf1 +mx/bulk +indirect:comcast.com/nonbulk -all

Summary
-------

The common theme among these hard-to-represent-in-SPF extensions is that
the extension says something about an individual mechanism, instead of
saying something about the domain as a whole -- other proposed
extensions that say something about the domain as a whole are much
easier to represent using SPF modifiers (unless the somethings have
internal structure, in which case it gets hard again).

When you put it all together, we need a way to say something new about
an individual mechanism.  Furthermore, we need the ability to say more
than one something new about the same mechanism
(+indirect:comcast.com/targetrep,nonbulk).  Furthermore, some of the
somethings have some internal structure (?all/feedback=xxx,hdrs,p=.001).
[Note that I'm not proposing syntax here -- the commas in this last
example mean something different than the commas in the previous
example.]

XML gives you all of the above.  We don't have any other proposals on
the table that give you any of the above.

-- jimbo

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Jun 2004 20:51:22 -0700

On Mon, 2004-06-21 at 17:04, Roy Badami wrote:
> >>>>> "Margaret" == Margaret Olson <[email-masked]> writes:
> 
>     Margaret> The rate limiting needs to occur on the sending side,
>     Margaret> but the receiver needs to know what it is.
> 
> But there's no need for the sender to publish the rate limiting
> information, because there's little reason for you to trust them.  It
> make more sense for the sender to simply refer to a rate limit policy
> published by their ISP (which could be achieved by an SPF modifier).
> 
> The reciever would then query the ISPs rate limiting policy for this
> domain and (assuming positive accreditation of the ISP) the recipient
> would then believe it.
> 
> Obviously the ISP's rate limiting policy would have to specify the IP
> addresses that they're responsible for (they can't rate limit mail you
> send out via another source) but this is all information that should
> be published by the ISP, not the sender.
> 
> So I don't believe it belongs in policies published by the sender, but
> in a completely new type of policy published by ISPs who send mail on
> behalf of their customers.
> 
> Though, as I said before, I'd like to see a move towards (return to)
> sites originating (and being responsible for) their own mail rather
> than relaying through their ISP...

Those sending mail must be accountable whether originating or relaying. 
Finding a practical way to assess accountability for the administrative
entity is the challenge.  There are many different schemes to access
identities of the author, if the author so wishes.  With mechanisms
defined in the Fenton "Identified Internet Mail" proposal, organizations
can assure recipients of having received valid mail from the indicated
author through the use of an HTTP key serving scheme.  Although DNS is
not able to handle this type of query, the HTTP key server both
minimizes queries and leaves the current mail infrastructure intact.

Publishing outbound mail paths to restrict the function of error returns
essentially hinders posting mail from various access points.  As a fix,
rewriting envelopes transfers the accountability of the sending
administration (the current outbound host) in an effort to repair the
damage and allow mail to travel over otherwise unpublished channels. 
The recipient may see the same name as being the author of the message
but must also be wary that my-pda.com is not the same as my-pda.co.jp
when these entities are acting as the accountable sending
administration.  In addition, anyone within such a domain is still able
to mimic these headers as being checked.  How is this different than
authenticating the MTA and _always_ holding this entity accountable? 
The envelope information is not exposed to the recipient, but even doing
so may not be an effective means of countering fraudulent mail.

Countering fraudulent mail requires evaluating policies of the
administrative entities and refusing service to those known to cause or
allow abuse unabated. Rate limiting the receiver could be effective for
administrative entities not yet evaluated.  Accreditation services could
assess the rates of mail by various means (perhaps by way of
queries) and tally complaints or evidence of abuse.  These accreditation
services may also provide a uniform query mechanism to ascertain
accreditation, affiliations, as well as authorization and authentication
of the address in conjunction with the administrative domain.  Such
accreditation could combine all these functions into a single query
(perhaps in logarithmic form)!

ipaddr.helo-domain.accredit.com -> affiliations.time.size.complaints

Expecting the MTA to query several records in sequence to assess each
message to uncover possible relationships between an author and their
means of access results in undefined levels of recursion and extensive
computational resources to build complex maps from these distributed
structures.  Expecting access providers to enable direct SMTP
connectivity to simplify this process removes methods for monitoring and
controlling abuse.  This would drop one form of protection for a dubious,
expensive, and highly prone alternative.

Already a scheme such as SPF could be considered over extended.  Further
extensions will only cause greater harm. Instead, ensure the author with
an end-to-end scheme such as the Fenton proposal.  Insert simple DNS
records to assert the authority and authenticity of the MTA by way of
CIDR notation or SRV records for a single administrative domain. These
records may acquire assistance from the accreditation service, however
no scheme will be able to curtail abuse without accreditation services.
Policing the channel at the MTA will scale, but not at the message.
Expect abusers to be the first to implement all manner and means of
affecting a pretense of legitimate commerce.  Stop the abuse and then
end-to-end remains possible.  Don't break mail and DNS with a burden of
excessive and complex structures and, in doing so, make the system even
more prone.

-Doug