On Fri, Sep 26, 2003 at 12:35:48PM -0400, Yakov Shafranovich wrote:
|
| I co-chair the Anti-Spam Research Group (ASRG) of the IRTF
| [www.irtf.org/asrg]. All of you are involved with RMX-type proposals for
| for verifying mail servers (in order to kill spam). We are currently
| aware of the following proposals:
|
| http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-02.txt
| http://www.ietf.org/internet-drafts/draft-fecyk-dsprotocol-04.txt
| http://www.ietf.org/internet-drafts/draft-brand-drip-01.txt
| http://www.irtf.org/asrg/draft-vixie-repudiating-mail-from.txt
| http://spf.pobox.com/draft-mengwong-spf-01.txt
| http://nospam.couchpotato.net/
|
| As per the list message below, there exist a significant interest in the
| ASRG in reconciling all of these various proposals in hope of coming up
| with a single draft. We would like to ask all of you if you want to
| participate in this effort, and any other suggestions that you may have.
| There are several individuals in the ASRG that are willing to help out
| with the editing, review and reconciliation. Please let us know what you
| think.
|
Yes, this would be good, especially since ISPcon draws near and we
should be able to present "The Future Of Spam: Leading Holistic
Solutions" with a unified voice.
Here are my thoughts.
The different proposals each have their pros and cons. They all share
the goal of weakly authenticating email by checking with the sender
domain to see if the SMTP transaction is legitimate. The different
designs reflect different beliefs about the normative scenario. Each
view is valid, and represents a good set of compromises given the
underlying assumptions.
However, the Internet is a big place, and there are many different
scenarios. A single protocol cannot be all things to all people.
That is the problem that drives SPF's growth. Over the past few months,
I have watched SPF evolve. There is a pattern to its evolution. It has
evolved away from defining policy by fiat. It has evolved toward
providing more mechanisms to support whatever policy humans want to
define.
One could describe SPF's current design like this:
Sender domains use SPF to designate a set of legitimate mailers.
No other SMTP clients may use that sender domain in MAIL FROM:.
Decisions are made by looking up 4.3.2.1.in-addr._smtp_client.DOMAIN.
But its design *philosophy* is this:
SPF allows two mutually consenting parties to construct and observe
policy, using a commonly agreed mechanism, to the advantage of both.
While the design has changed over time, the philosophy has stayed the
same.
It is a good philosophy. It tells us immediately that the current
design is too specific: while the reversed-IP notation may be good in
some situations, there may be better approaches in other situations.
Claus Assmann mentioned his desire to minimize the number of required
DNS lookups. Does he mean the number of required lookups over time, or
the number of required lookups initially for a given transaction? It's
a tradeoff. SPF chooses to minimize the number of required lookups for
a given transaction. RMX chooses to publish the full set of permitted
servers right away. Resolvers that cache the result will minimize the
number of lookups over time.
So a single protocol cannot be all things to all people.
The only way to please everybody is to let each person tell you what
they want. The design philosophy agrees.
We all believe that sender domains deserve to decide who can send mail
from them.
Shouldn't we also believe that sender domains deserve to decide *how* to
decide?
The latest SPF discussion allows domain owners to specify their
preferred mechanisms at a higher level.
We introduce the concept of a configuration domain. Sender domains
use that domain to define mechanisms for resolving designated-mailer
status.
Here's how it works.
1) Perform an initial TXT query against a configuration label for the
domain, eg. config._smtp_client.DOMAIN
2) That returns a set of configuration directives representing the
designated-mailer policies of a purported sender domain. We have
been focusing on the SPF scheme so my examples may lean in that
direction but the design is meant to be general.
Suppose we query "config._smtp_client.DOMAIN TXT" and get the response
"mx:permit; a=designated-mailers.DOMAIN:permit; spf:permit; default:deny"
3) Each configuration directive represents a different approach to
answering the "is this client for real" question.
"permit:mx; permit:a=designated-mailers.DOMAIN; permit:spf; include:OTHERDOMAIN; deny:default"
4) permit:mx. Do an MX -> A lookup on the sender domain. The set of A
records returned defines the designated mailers. This is useful for
simple setups where the inbound MXes are the same as the outbound.
This bypasses the potential O(N) traffic of SPF, and permits O(1)
caching by resolvers, which is one advantage of the RMX design.
5) permit:a=designated-mailers.DOMAIN. Do an A lookup on the hostname
"designated-mailers.DOMAIN". The set of A records returned defines
the designated mailers. This provides the essentials of RMX
functionality without adding new record types, and also has the
benefit of caching. If CIDR records are needed, they can be sent
using a variation on this technique, such as
permit:txt/cidr=designated-mailers.DOMAIN
6) permit:spf. Do an SPF/DMP style lookup on
4.3.2.1.in-addr._smtp_client.DOMAIN according to the SPF/DMP spec.
This may be preferred by large domains who want to know who's forging
their addresses. On the downside, in a large spam run, you get O(N)
DNS volume, which may prove to be undesirable.
7) include:OTHERDOMAIN; if none of the preceding lookups has
short-circuited to "permit", recursively repeat the lookup using
OTHERDOMAIN.
8) default:deny. Mechanism, not policy; we should refrain from
specifying that by default everything should be denied; that decision
should be up to individual domains. By default the answer would be
"unknown", as if the sender domain did not participate in the protocol.
A recipient MTA might also downgrade a "default:deny" to "unknown" if
a sender domain specified a mechanism that the MTA did not recognize.
Other mechanisms can be included in this design. For example,
Mark-Jason Dominus has suggested another proposal based on message-IDs.
If that proposal sees widespread support, it could be simply added to
the directive list.
If people agree that the configuration concept is worth considering, we
may end up with a number of related RFCs, one that defines the config
domain, one that defines SPF-style 4.3.2.1.*.DOMAIN lookups, and one
that defines the RMX-style enumerations of designated mailers.
If you like the idea, please re-post to the ASRG list.
cheers
meng
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@©#«Mo\¯HÝÜîU;±¤Ö¤Íµøˆ¡
|
| I co-chair the Anti-Spam Research Group (ASRG) of the IRTF
| [www.irtf.org/asrg]. All of you are involved with RMX-type proposals for
| for verifying mail servers (in order to kill spam). We are currently
| aware of the following proposals:
|
| http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-02.txt
| http://www.ietf.org/internet-drafts/draft-fecyk-dsprotocol-04.txt
| http://www.ietf.org/internet-drafts/draft-brand-drip-01.txt
| http://www.irtf.org/asrg/draft-vixie-repudiating-mail-from.txt
| http://spf.pobox.com/draft-mengwong-spf-01.txt
| http://nospam.couchpotato.net/
|
| As per the list message below, there exist a significant interest in the
| ASRG in reconciling all of these various proposals in hope of coming up
| with a single draft. We would like to ask all of you if you want to
| participate in this effort, and any other suggestions that you may have.
| There are several individuals in the ASRG that are willing to help out
| with the editing, review and reconciliation. Please let us know what you
| think.
|
Yes, this would be good, especially since ISPcon draws near and we
should be able to present "The Future Of Spam: Leading Holistic
Solutions" with a unified voice.
Here are my thoughts.
The different proposals each have their pros and cons. They all share
the goal of weakly authenticating email by checking with the sender
domain to see if the SMTP transaction is legitimate. The different
designs reflect different beliefs about the normative scenario. Each
view is valid, and represents a good set of compromises given the
underlying assumptions.
However, the Internet is a big place, and there are many different
scenarios. A single protocol cannot be all things to all people.
That is the problem that drives SPF's growth. Over the past few months,
I have watched SPF evolve. There is a pattern to its evolution. It has
evolved away from defining policy by fiat. It has evolved toward
providing more mechanisms to support whatever policy humans want to
define.
One could describe SPF's current design like this:
Sender domains use SPF to designate a set of legitimate mailers.
No other SMTP clients may use that sender domain in MAIL FROM:.
Decisions are made by looking up 4.3.2.1.in-addr._smtp_client.DOMAIN.
But its design *philosophy* is this:
SPF allows two mutually consenting parties to construct and observe
policy, using a commonly agreed mechanism, to the advantage of both.
While the design has changed over time, the philosophy has stayed the
same.
It is a good philosophy. It tells us immediately that the current
design is too specific: while the reversed-IP notation may be good in
some situations, there may be better approaches in other situations.
Claus Assmann mentioned his desire to minimize the number of required
DNS lookups. Does he mean the number of required lookups over time, or
the number of required lookups initially for a given transaction? It's
a tradeoff. SPF chooses to minimize the number of required lookups for
a given transaction. RMX chooses to publish the full set of permitted
servers right away. Resolvers that cache the result will minimize the
number of lookups over time.
So a single protocol cannot be all things to all people.
The only way to please everybody is to let each person tell you what
they want. The design philosophy agrees.
We all believe that sender domains deserve to decide who can send mail
from them.
Shouldn't we also believe that sender domains deserve to decide *how* to
decide?
The latest SPF discussion allows domain owners to specify their
preferred mechanisms at a higher level.
We introduce the concept of a configuration domain. Sender domains
use that domain to define mechanisms for resolving designated-mailer
status.
Here's how it works.
1) Perform an initial TXT query against a configuration label for the
domain, eg. config._smtp_client.DOMAIN
2) That returns a set of configuration directives representing the
designated-mailer policies of a purported sender domain. We have
been focusing on the SPF scheme so my examples may lean in that
direction but the design is meant to be general.
Suppose we query "config._smtp_client.DOMAIN TXT" and get the response
"mx:permit; a=designated-mailers.DOMAIN:permit; spf:permit; default:deny"
3) Each configuration directive represents a different approach to
answering the "is this client for real" question.
"permit:mx; permit:a=designated-mailers.DOMAIN; permit:spf; include:OTHERDOMAIN; deny:default"
4) permit:mx. Do an MX -> A lookup on the sender domain. The set of A
records returned defines the designated mailers. This is useful for
simple setups where the inbound MXes are the same as the outbound.
This bypasses the potential O(N) traffic of SPF, and permits O(1)
caching by resolvers, which is one advantage of the RMX design.
5) permit:a=designated-mailers.DOMAIN. Do an A lookup on the hostname
"designated-mailers.DOMAIN". The set of A records returned defines
the designated mailers. This provides the essentials of RMX
functionality without adding new record types, and also has the
benefit of caching. If CIDR records are needed, they can be sent
using a variation on this technique, such as
permit:txt/cidr=designated-mailers.DOMAIN
6) permit:spf. Do an SPF/DMP style lookup on
4.3.2.1.in-addr._smtp_client.DOMAIN according to the SPF/DMP spec.
This may be preferred by large domains who want to know who's forging
their addresses. On the downside, in a large spam run, you get O(N)
DNS volume, which may prove to be undesirable.
7) include:OTHERDOMAIN; if none of the preceding lookups has
short-circuited to "permit", recursively repeat the lookup using
OTHERDOMAIN.
8) default:deny. Mechanism, not policy; we should refrain from
specifying that by default everything should be denied; that decision
should be up to individual domains. By default the answer would be
"unknown", as if the sender domain did not participate in the protocol.
A recipient MTA might also downgrade a "default:deny" to "unknown" if
a sender domain specified a mechanism that the MTA did not recognize.
Other mechanisms can be included in this design. For example,
Mark-Jason Dominus has suggested another proposal based on message-IDs.
If that proposal sees widespread support, it could be simply added to
the directive list.
If people agree that the configuration concept is worth considering, we
may end up with a number of related RFCs, one that defines the config
domain, one that defines SPF-style 4.3.2.1.*.DOMAIN lookups, and one
that defines the RMX-style enumerations of designated mailers.
If you like the idea, please re-post to the ASRG list.
cheers
meng
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@©#«Mo\¯HÝÜîU;±¤Ö¤Íµøˆ¡