MOstly agreeing with Roy here, but I'm raising a couple of questions that
could use extra pairs of eyes and feedback...
1. Placement of TXT records.
The co-chairs find that the working group has not come to consensus on
the use of a record prefix vs [unprefixed] TXT records
I think I would agree with Roy that allowing MARID-compliant MTAs to check
the unprefixed name is desirable.
In other words, if MARID-Brand LMAP works substantially similar to
SPF-Brand, let's go ahead and use their data.
One concern here is that we would want the semantics to be similar enough
to not upset or surprise anyone who isn't expecting their data to be used a
slightly different way, but I think we are able to do that. (That
certainly was the intent of the SenderID merged proposal)
In a straight race, I would probably root for the non-prefixed records to
win, simply because the underscore might scare and confuse people (it was
removed from early versions of SPF for mostly that reason). I do
understand the issue that the prefix is intended to address, but I don't
think the research we have shows it is anything to worry about. I think
most users will not have TXT records of any other type, and of those that
do, the records will mostly be small enough to coexist peacefully. I don't
have a strong preference in this area, except that backward compatibility
would allow MARID to harness and redirect the momentum SPF has built up.
(Of course we will be going through the process of getting our own RR so we
will eventually have an escape plan)
Does anyone have a strong objection to using unprefixed txt records?
1b. [the working group] has not
reached consensus on how to address domains with wildcard MX records.
Actually I think this one is pretty easy to fix... if there is a wildcard A
or wildcard MX record already there, the site should also create a wildcard
TXT record.
(I really wish we could go back in time and tell people they need to set up
MX records for all deliverable domains and hosts and not fallback to A...
any chance we could declare the fallback-to-A practice deprecated? It may
be officially outside our scope, but it really makes the job of publishing
LMAP records a lot harder.)
Let me add this sort of related point...
1c. The group has not agreed on an alternate placement for TXT records
other than the label exactly matching the (host part of the) identity being
checked. I.e. a MARID record at example.com does not cover
user(_at_)www(_dot_)example(_dot_)com(_dot_)
That means: the domain owner should create LMAP records for ALL hosts in
his domain that have A or MX records. (Note that a wildcard TXT record
does not cover names that have A or MX but no TXT, only names with no
defined data at all)
Is this something we need to work on more, or should we leave it like that?
We talked about looking for the "closest SOA name" and looking there, and
applying the TXT record at that location to other subdomains that have no
TXT of their own.
Another idea might be to have records set up like:
example.com. IN TXT "v=xxx1 a mx ptr ?all" ; only for mail @example.com
mail1.example.com. IN TXT "v=xxx1 a -all" ; for @mail1.example.com
_all.example.com. IN TXT "v=xxx1 -all" ; for @*.example.com if no
TXT
In this case I would totally support use of the underscore because this is
a little bit of an advanced feature anyway, but it doesn't have to be an
underscore to work. Then again this could be a performance problem... if
most domains don't have TXT records we would have to do a second query to
find the SOA and a third to find the higher-level (either example.com or
_all.example.com) so I don't want to push too hard for climbing up the
chain if there isn't a lot of support for it.
Any feedback as to whether we should pursue this any further or just leave
it as the domain itself only and no searching at higher levels?
Given MARID records are similar, but not identical, to SPF records,
and that it is at least possible that there will shortly be a large
number of SPF checkers in real world use, I'd like to propose the
following strategy:
MARID should define syntax versions 1 and 2 (identified by v=spf1 and
v=spf2) as identical. MARID-compliant implementations must interpret
both of these records identically, and must use the highest understood
version record if multiple versions are found (this is the same rule
as in SPF).
I think the records will be similar enough that we can honor the original
publisher's intentions. However, there's nothing really *wrong* with
defining a new prefix. MTAs will need to be revised a bit anyway to be
MARID-compliant, and a TXT lookup will still get both records.
What would folks in the group think about defining our own prefix like
"v=lmap1"? I think this is only really needed in the off chance that the
semantics are different enough for people to notice. I expect that people
will continue to publish "v=spf1" for a while until the new
MARID-compatible MTAs are widespread, then they could publish either.
Someone would really only want to publish both if they want one policy for
SPF Classic and a different policy for MARID-Brand LMAP.
(I called it LMAP because that seems to be a better name for the protocol,
and it leaves the door open for MARID-the-group to work on and publish
other stuff. The protocol is important but it's not the only important
thing the group has worked on :)
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>