Re: Limited scope of work

> > > I think a fourth category may be needed:  Unknown -- IPs that
> > > are untrusted, but not necessarily bad.
> > >
> > > Otherwise, we risk falling into the mindset that anything not
> > > explicitly permitted is to be dropped.
> "Gordon Fecyk" <gordonf(_at_)pan-am(_dot_)ca> writes:
> > Actually, that is EXACTLY the mindset that should be adopted.  If we
> > don't adopt this mindset we might as well trust everything by default
> > like we have for the past fifteen+ years.  Or is it twenty+ years?
I'm going to go with Gordon on this one... however, I don't see it as black 
and white.  (Similar to what I was saying in the RFC2476 thread... we can 
certainly SAY something is deprecated, but that will not turn it off day 
one.
Which is what I think the previous writer was getting at.  Nobody is 
planning to drop non-LMAP mail on the floor right away... I am guessing it 
will be some months, probably years, before large numbers of people turn 
off the unchecked/unknown/non-LMAP mail.  We will have to decide what to do 
with unknown cases, or perhaps allow the recipient flexibility to decide as 
they do today -- caveat receiver (receiver beware).
There is a sliding scale between "break (all) (now)" and "break (nothing) 
(ever)" - very few people live at either extreme.  We will have to decide 
what to break (or excuse me, *deprecate*) and when... odds are that our 
thoughts on this are closer than we think.

--wayne <wayne(_at_)midwestcs(_dot_)com> wrote:
> The issue of whether there should be just a pass/fail, or if there
> should be some levels of gray in the LMAP proposals seems to be one
> that many reasonable people disagree on.  I think most people agree
> that the desired result is widespread adoption with generally only
> pass/fail results, but there is disagreement about how to reach this
> goal.

Speaking for myself, I like the flexibility that "soft fail" or "test only" 
type of modes give you.  SPF has it, MS-CID has it, though much weaker.

> The second most popular SPF record in the adoption roll is an example
> of how one specialized web hosting company who decides to add SPF
> records for all(?) of their clients can skew the results of the
> adoption roll.  Actually, the same goes for numbers 7 and 8.
More info as followup to wayne's info.  #7 is actually this:

> 7   171 v=spf1 +exists:CL.%{i}.FR.%{s}.HE.%{h}.null.spf.altavista.com 
-all

which was added to altavista.com and a crapload of other domains.  This is 
another example of SPF's "Xtreme Flexibility" (which I know makes some of 
you cringe).  In our case, the domain "null.spf.altavista.com" does not 
exist, BUT all queries to it are logged, so I can actually tell when other 
MTAs "out there" are getting connections forging our unused names.
If you wanted a variation on this, something that reverts to unknown but 
logs when it has done so, you could do something like:
 v=spf1 +a +mx +ptr +exists:CL.%{i}.FR.%{s}.HE.%{h}.null.spf.altavista.com 
?all
and the DNS query log would show any cases that were not authorized.

I'm pretty sure you could do this with DMP also - just log the queries and 
away you go.  But without a ?all or other "revert to unknown" or "soft 
fail" behavior, there's no real safety net for domain owners to try it out 
and see how it goes.
> There are 204 SPF records on the adoption roll that use the exists:
> mechanism with a macro variable, so a non-trivial number of domain
> owners want some sort of more complex than a simple list of IP
> addresses.
Some of them could be using it just for the logging like we are with 
altavista.com, but there are also some who have actual authorization trees 
that include IP or localpart, and there are also examples of "rate 
limiting" DNS servers that give "Allow" responses for the first dozen or 
hundred from the same IP, then block the unknown IP after a limit is hit 
(which you could do with DMP also, probably)
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>