On 5/3/04 at 11:40 AM -0700, Greg Connor wrote:
1. Express the set of "authorized" mailers for a domain. (REQUIRED)
1a. Minimal approach would be a list of IPs or hostnames, similar to MX
Actually, MX records point to domain names, not IPs. The domain names
point to A records, which have the IP addresses. That's one thing we
need (domain names that can point to A records), but we likely need
to allow for ranges of IP addresses, which is the important different
thing we have to account for that MXs don't give us.
1b. A flexible language like "a mx ptr" can save me a step when
adding MTAs later. The actual language is not important, but
"flexible mechanisms" is an important feature to me
I'm less convinced about this. It is surely a departure from most
existing things that can be expressed in the DNS. I don't really want
servers to be in the business of "resolve foo, get bar, resolve bar,
get baz, resolve baz, get (the answer or something else to resolve)."
I'd like to see us do at most one or two steps as the normal state of
affairs (i.e., getting back addresses or domain names that can be
resolved doing an A lookup).
2. Express other mailers as unknown, or known bad. (Strongly recommended)
2a. Analog to spf ( - ? ~ )
2b. Ability to express a "default" or "fallback" included here
So there's two things here:
- Ability to express that one or more IP addresses are specifically
*not* allowed to send mail purporting to be from this domain name.
- Ability to express a series of tests that will fail, or softfail, etc.
I think the former is clearly on the strongly recommended list. I'm
not as convinced about the latter. Looking up data in the DNS is one
thing; looking up algorithms gives me the willies.
3. Ability to include other domains (and get their LMAP info) by reference
3a. Analog to include: mechanism
I would reword this to "Ability to have an aliasing mechanism, i.e.,
to treat example.com as example.org".
I would add in here the ability to wildcard subdomainss as desirable,
though perhaps not necessary.
4. Extensible enough to include some data we haven't thought of yet
4a. Analagous to spf modifiers "foo=bar" which can be ignored by
older clients
4b. "Extensibility" must be treated with caution... for now we
can postpone discussion of syntax and just say "Extensibility" is a
required feature.
We need to make a decision on whether we need (more-or-less)
arbitrary extensibility or not. For instance, do we think that a
limited set of boolean extension flags are sufficient (which we could
limit to some reasonable number), or do we need more expressiveness
than just flags. For something like caller id's "directOnly", a
boolean flag would suffice. To allow things like "check in this
particular header field" or "check in this particular SMTP extension
field", booleans might be too limiting.
Overall, I think we could limit the entire semantics to:
- The set of "approved" domains, IP addresses, and IP address ranges/subnets
- The set of "specifically unapproved" domains, IP addresses and IP
address ranges/subnets
- Aliasing of domains to other domains
- A limited set of boolean extension flags
and optionally:
- Wildcarding of subdomains.
Then again, I'm a minimalist.
pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102