"wayne" == wayne <wayne(_at_)midwestcs(_dot_)com> writes:
>> of deployment otherwise.
wayne> With many major ISPs publishing records and very rapid
wayne> increase in the amount of email being check with SPF, I
wayne> think the prospects for substantive levels of deployment of
wayne> SPF is very good.
And when SpamAssassin 3.0 is released in a couple of months, the
number of people performing SPF checks will increase markedly, I would
guess.
SPF is not going to go away immediately (or even ever) when this WG
publishes a spec. MARID will take time to be deployed, and it will
obviously be quite a while before MARID checks make their way into
Spamassassin and other spam checkers, since a spec won't even exist
for quite some time, and some of these products have quite long
release cycles. So it will be beneficial for people to continue
publish SPF records in addition to MARID records long into the future.
The converse will also be true to some extent -- it will probably
remain useful to check SPF records after the MARID spec is finalized,
although I expect this effect to be somewhat smaller; my gut feeling
is that most of the people publishing SPF records, being early
adopters, will fairly quickly publish MARID records, too (always
assuming that MARID allows them to express their desired policy).
It's quite possible that SPF and MARID may continue to be deployed in
parallel indefinitely; before the formation of this WG many people
were predicting that we would see parallel deployment of SPF, Caller
ID for E-mail and DomainKeys, with most people publishing and checking
all three kinds of records.
For someone who is interested in publishing LMAP records, there is
little incentive to publish just one type of record: they may as well
publish all types of record that both have a significant number of
sites checking them and allow them to describe their desired policy.
We may even see automated tools that allow a single (tool-specific)
policy definition used to generate multiple types of LMAP
records.--(1)
For someone who is interested in checking LMAP records, there is
little incentive to check just one type of record: they may as well
check every type of record that is published by a significant number
of sites. I predict that there will be a number of integrated tools
that will check many types of LMAP records... I'm strongly suspect
that SpamAssassin will add checks for other LMAP records as and when
they start being deployed, for example--(2)
So will MARID become yet another record we all end up publishing and
checking, or will it supplant the other record types? If it becomes
yet another record, will it gain us anything?
If you believe that I'm correct in my predictions (1) and (2) above,
then SPF will probably stay around for a long time after MARID is
released.
The only (1) won't happen is if the semantics of MARID allow people to
create policies that are more acceptable to them than SPF -- either if
MARID is a superset of SPF and includes additional features that
people want (even if they don't know they want them yet) or if SPF and
MARID end up choosing fundamentally different and incomparable
semantic models, and the latter allows people to express policies that
are more useful to them than those that can be expresssed with SPF.
Point (2) will probably happen to some extent regardless, but if there
are people who have already published SPF records, and can't describe
their policy in a MARID record (eg because MARID only offers a subset
of SPF functinality) then they may well be happy to continue to
publish just SPF records rather than change their policy to fit in
with the capabilities of MARID -- in the knowledge that most people
checking MARID records are checking SPF records, too. In this
scenario the incentive for continuing to check SPF records remains
stronger.
I'm really not trying to promote SPF here; the only reason I publish
and check SPF records rather than some other kind of LAMP record for
my personal domain is because the spec and the tools are there, and it
has a userbase. (I'm happy to be a follower here. It's only useful
to me to publish records if people will check them, and it's only
useful to me to check records if there are people publishing them.)
In fact, I also publish a Caller ID record (in testing mode), and will
happily remove the testing status once I see signs of deployment, and
am confident that it won't cause me problems (ie that posts I make to
mailing lists won't end up being dropped by list members).
In fact, I'm far from convinced that LMAP will have a significant long
term impact on the spam problem, though I certainly think it could
make a significant dent in the problem in the short to medium term
(before spammers start publishing LMAP records). But, like most
people these days, I'm prepared to try pretty much anything to tackle
spam, as long as it seems (to me) to be deployable and has acceptable
(to me) cost.
But, for all the cost and complexity arguments, my gut feeling is that
MARID will just add complexity for me. I'll just end up having to
publish one more type of LMAP record, and I'll have to install one
more LMAP checker module in my MTA.
If MARID ends up having a subset of SPF functinality, then it seems to
me almost inevitable that that extra cost will remain indefinitely (or
at least, for the useful life of LMAP as a concept). But even if
MARID has comparable functionality, but an incompatible syntax, I fear
that extra cost will remain for a long time.
I predict that as far as tools go, people will, over time, write LMAP
tools, rather than SPF tools or MARID tools or CID tools or DK tools.
So having yet another standard increases implementation cost for LMAP
tools, no matter what that standard is. And having yet another
standard also increases the cost in terms of the number of DNS lookups
I have to make.
This is really just me thinking aloud, and I'm not trying to argue for
any particular course of action by this WG. I'm just trying to look
ahead and see what benefit this WG may bring to e-mail. And right now
it's not clear to me what this WG will achieve, or whether it will be
beneficial, if it creates a new standard.
This is all just my opinion, of course, and my predictions may well be
wrong (they often are ;-)
-roy