--Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com> wrote:
I would recommend focusing first on what data we want to represent i.e.
semantics, before jumping to the actual syntax.
Good idea. I think most folks will have a general idea of what is required
for LMAP (which mostly matches everyone else's) but we might diverge a bit
in terms of optional information. That's OK... we should just focus on
listing everything for now and go back and trim as needed.
So. Here is what I want in terms of semantics.
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
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
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
3. Ability to include other domains (and get their LMAP info) by reference
3a. Analog to include: mechanism
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.
There are more "features" I am skipping here that have to do with semantics
but I think these are the "core" that hopefully everyone can agree on.
Anyone want to add to the list?
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>