On Thu, Jan 22, 2004 at 02:27:53AM -0600, Phil Howard wrote:
| | There are two difficulties with this approach. First there is barely a
| | process for developing SPF. Who gets to decide what goes into SPF 1.1? What
| | happens if someone makes a proposal for an extension and the group does not
| | think it is a good idea? There is no way we can force them to drop it, they
| | can go ahead and publish anyway.
|
| SPF is already extensible at the server side via the "exists" mechanism and
| a custom/hacked DNS server designed to implement whatever semantics the new
| extension needs. Every network could have its very own logic because it is
| performed on their own server. SPF would merely pass on the data, let the
| DNS server figure it out, and wait for the boolean answer.
Phillip is talking more about how to add new mechanisms like "smime" or
"domainkeys" or "habeas", and how to ensure that all the SPF
implementations out there can be expected to understand those
mechanisms.
So we'll see new mechanisms, and we should be prepared for them. But
there are at least two new things, and authentication mechanisms are
only one. What's the other?
Looking to the next step, we need to be able to add accreditation
semantics in a well defined way.
A sender domain wants to be able to make the assertion that it is not a
spammer. It can do this today by saying implicitly "look me up in
bondedsender.com if you don't believe me!" but that assertion is not
dynamically loaded at run-time, so to speak; it is hard-coded into
SpamAssassin. (Big icky list of hardcoding instructions at
http://www.bondedsender.org/)
Speaking of hardcoding, that's a pattern programmers are very familiar
with: when we program, we start out by hardcoding things for
convenience. Later we move those things into configuration files and
eventually they may go on to the network. Rather than hardcoding all the
possible accreditation schemes, it would be more forward-looking to put
extensibility in at the start. Look at the trouble with DNS RRs today.
So maybe the way to do it is this. We make sender authentication
assertions using SPF: v=spf1 a mx dk habeas whatever -all. Unknown
mechanisms are not recognized.
But we also include a pointer to accreditation information. We do this
by adding an "accredit=" modifier, which may be ignored by receiver MTAs
that don't want to deal with the added complexity. In the beginning,
many receiver MTAs will not want to bother; spoof detection is good
enough for them. But the antispam vendors will be very excited about
this accredit= modifier, because it gives them more ways to exercise
their cleverness.
So here's a potential SPF record, already legal in the current spec:
v=spf1 a mx dk whatever -all accredit=_accredit.%{d}
And _accredit.DOMAIN.COM has another TXT that says:
v=acc1 dnswl:%{ir}.sa.bondedsender.org cert:%{d}.acc.verisign.com
And it would be the responsibility of the reputation system used by the
receiver MTA to accrete information about the tokens listed in the
accreditation record. SpamAssassin, for instance, could assign the
appropriate score if the sender is found in
dnswl:%{ir}.sa.bondedsender.org. The appropriateness of the score would
be up to SpamAssassin to determine. When you upgrade SA, you
automatically learn about the new accreditation schemes and providers
that have come along since the last release.
"Wait, what is an Accreditation Scheme? Did I miss something?"
Today you know very little about an SMTP sender: you know its IP address
and its PTR name and its asserted MAIL FROM. Reputations are built on
those factors today, with DNSBLs and RHSBLs and "rDNS required" type
rules. Tomorrow, accreditation systems will help senders enrich their
attribute space, so that you can know (verifiably, without having to
trust the sender) certain other facts about the sender, such as, for
instance, the fact that somebody somewhere can be subpoenaed for a
real-world address for the sender where process can be served. Spammers
would, presumably, not possess that accreditation attribute.
The authentication / accreditation / reputation framework accommodates
all the harebrained schemes that people have come up with to date.
Things like micropayments can now be interpreted as an accreditation
scheme where the accreditation service provides an escrow account, and a
reputation service deducts from it on behalf of the recipient.
So people have been excited about XML because they want to be able to
explore this space efficiently, without having to wait for IETF
approval. If we can give them this kind of extensibility without the
bloat of XML, I think we will satisfy people. How do the accreditation
providers and the reputation services out there feel about that?
Comments please.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡