ietf-mxcomp
[Top] [All Lists]

on per-user macros; and the IETF's role in a deployment campaign

2004-05-11 04:10:14

On Tue, May 11, 2004 at 11:24:34AM +0100, Jon Kyme wrote:
| It seems to me that this experiment is revealing exactly what one would
| expect: there are a number of early adopters and a tremendous difficulty in
| penetrating the mass. It may be that it's not the number of deployments
| that's important but rather the volume of mail / number of inboxen covered,
| in which case we're not so concerned with providing all the facilities that
| *everyone* wants, but rather those which the key deployments *need*. Who
| are the market makers?

Back in the early days, one of the biggest objections to SPF was the
problem with verbatim forwarding.  The forwarder communities (the
pure-plays eg. acm.org, and the "background radiation" /etc/aliases
and .forward installed base at ISPs large and small) were therefore
considered key stakeholders, and we spent a lot of effort on SRS to
give them a viable workaround.  John Levine also identified the
traveling mailman scenario.

The per-user macro logic was designed to mollify the traveling mailman
and forwarder communities.  I do not think it would be wise to
alienate those communities just because simplifying the specification
seemed liked a good idea at the time.

We have established that macros do not make SPF Turing-complete;
people who have implemented SPF, including the majority of the
antispam vendor market, have not complained about any difficulty.  The
publishing population rater likes them.

Still, a lot of people have said they have a problem with macros.  The
substantive objections have been dealt with: for example, concerns
with potential DDOS attacks removed %{t} from the domain-spec
definition.  (But you can still use it in the exp string.)  The
remaining objections are essentially speculative.

"Where do you want to go for lunch?"  "I have no preference, but I
heard Dad wants fish."  One hour later: "Dad, I'm really sorry but we
can't find any seafood places."  Dad: "What made you think I wanted
seafood?"  "Didn't you?"  "No, I would've been fine with any of the
places we passed in the last hour."  "Oh.  Well, how about here?"
"Fine by me."

I'd rather find out what people care about by asking them.
Speculating on someone else's behalf is bad engineering.
Wedding registries are efficient.  Post-Christmas returns, less so.

                         Regarding deployment

The SPF community has prepared a strategy for getting adoption by the
masses, but is holding off on executing that strategy in deference to
the IETF.  If the IETF decides that a deployment campaign encompassing
change management and industry coordination is outside its charter,
the SPF community will continue to run with the ball.  If the IETF is
willing to provide driving leadership in an official capacity for the
adoption campaign, that would be ideal for everyone involved.

Assuming MARID continues to validate the work already done by SPF, are
there any organizational precedents for the IETF not just developing
but actively promulgating a standard?  Or is adoption generally left
in the hands of fate?


<Prev in Thread] Current Thread [Next in Thread>