On Thu, Jan 22, 2004 at 04:53:08AM -0500, Meng Weng Wong wrote:
| 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.
When will it end?
The problem is a deployment issue. Unlike many other protocols, when a
new mechanism is added to SPF, using it breaks until AFTER all the MTAs
that are SPF aware will recognize it ... unless you bump the version
number each time a new mechanism is added.
| 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?
How do you prepare for a new mechanism? You have to implement the logic
to deal with it in every MTA implementation, or at least link it in. Then
you have to wait for all the MTAs to deploy it. Extensibility is not so
trivial in SPF.
| Looking to the next step, we need to be able to add accreditation
| semantics in a well defined way.
Let's define what the actually means, first.
| 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/)
It is wrong for the sender to specify to the MTA where to look things up.
That's wide open for abuse. Instead, the MTA should look up the domain
from whomever it trusts to provide it truthful and trustable information.
Isn't this also out of scope for SPF? SPF lets you know if the source
is one the domain owner designates. If you want to know if that source
(which has now been determined to be the designated one) has a spamming
history, you look up the domain through the information providers you
happen to trust (not who the domain owner tells you to look up). This
is already done as RHSBL anyway.
| 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.
In principle, I would agree to that as a programming practice. But as a
design, "schemes" should be minimized on the high scaled end of things.
The high scaled end is the MTAs that are querying SPF. The more complex
things get, the more they should be pushed back to where the complexity
demands originate ... at the domain owner and his DNS implementation.
| 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.
So you are saying the logic should be, if the mechanism is not recognized,
skip it as if it were not there?
Based on what I see so far, I won't even put accreditation in, anyway.
I'm not going to trust a spammer to tell me to look at DMA to find out
he's a good guy.
| 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
Why can't "exists:" be used? Is it too much to ask the domain owner
who wants complex designations to deploy their own complexity, instead
of demanding that every MTA do it for them?
| 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?"
Yeah.
| 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
The PTR name is usable only as a hint. If there is no A or AAAA record
under that name to match the connection, the PTR is moot.
There is also the HELO banner. It's about as usable as the PTR record.
Oh, yes, you can look up that name for an A or AAAA record, and if such
a record is found and matches, you at least know the name is credible in
the context of the domain that gave the matching address record back.
| those factors today, with DNSBLs and RHSBLs and "rDNS required" type
and "matching rDNS required" or "matching (rDNS or HELO) required".
| 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.
But a mechanism that allows the spammers to fake it is useless. If the
spammer tells you where to look things up, that's no good. I need to be
able to look things up from where *I* specify, not where the spammer says
to.
| 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.
Look for these things to be cracked in 6 months from the time there is
any money to be made from it.
| 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.
You still have to implement the logic behind the data for it to be of any
use. Unvetted extensibility is a bad idea. That doesn't mean new ideas
are to be discard; in fact things _must_ change. But they should be very
carefully reviewed and studied before deployment, and I think IETF actually
has done a reasonably good job at that. Unvetted extensibility risks
fragmentation as different people are too readily able to coordinate new
ideas, which are sure to include many bad ones. Unvetted extensibility
will lead to chaos, eventually. Why not let people drive on whatever side
of the road they wish to, and leave it up to the other drivers to get out
of the way as needed.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
-------
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;±¤Ö¤Íµø?¡