Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: SPF: Discuss

Standard Authentication Query

 

 

First page Previous page 1 2 Next page Last page  View All SPF discuss RSS feed   Index | Next | Previous | View Threaded


dmquigg-spf at yahoo

Mar 29, 2005, 9:00 AM

Post #1 of 27 (2245 views)
Permalink
Standard Authentication Query

At 05:31 PM 3/29/2005 +0200, Frank wrote:

>I want an RfC for
>v=spf1 a.s.a.p. All these permanent modifications like adding
>zone-cut, removing zone-cut, use PRA instead of MAIL FROM,
>don't use PRA, MAYbe test HELO, ignore HELO, SHOULD test HELO,
>limit the processing time to at least 20 seconds, at most 20
>seconds, at least 10 indirections, at most 10 indirectionss,
>exactly 10 mechanisms, 10 queries, etc.
>
>...all this infuriates me. V=spf1 is supposed to be stable for
>more than a year now. I'm not interested in "new features", as
>long as we don't have this one "really stable" RfC. Even if it
>is only "experimental".
>
>In your case I felt that you insisted on going through a wall
>(anything with DNS is a "wall" from my POV), where I could see
>the SIQ-door, but couldn't explain the "wall"-part.
>
>Chris Haynes has now done it: It's not a theoretical problem
>with DNS, but "only" a practical problem with the deployment of
>new uses of DNS queries for new RRs like the future SPF RR.
>
>Back to square one: Adding new features to DNS is no option
>but a bad case of FUSSP - "when all DNS libraries, servers,
>firewalls, and what else are updated". Yes, then we could do
>wonderful things. We could even forget SPF and implement CSV.
>
>But in practice that's not possible. SPF has reasons to abuse
>TXT "at the moment", and this moment will last for decades plus
>the time wasted to get a RfC with the new SPF RR (without your
>modified query),
>
>It was a design decision to have a 1:1 correspondence between
>the "old" TXT RR solution and the "new" SPF RR. Maybe add an
>optional "additional info section" with the IP to these queries
>for v=spf6 or spf/6.0 later.
>
>But please stay away from v=spf1 "as is" before we have some
>kind of "official" RfC for v=spf1. It's already hell to get
>at least so far. The very last v=spf1 needs now are some "new
>features". Let alone new features in its DNS layer.

I appreciate your frustration. It sure seems like the entire technical
community is floundering over what should be a simple standard. I don't
mean the SPF standard, but a standard that all methods can live
within. This would not include any controversial items like redirected
queries, but just those few items needed for inter-operability of all methods.

My worry is that we might get agreement within the SPF community, barely
squeeze it through IETF, then face adamant opposition from SenderID,
DomainKeys, and any other group that doesn't like the letters SPF in an
authentication header.

My suggestion is that we take one little step backwards and try for a
standard that everyone can agree on (or at least make clear that their
objections are frivolous). With a few items standardized, SPF and any
other method can do whatever they want within the standard, and the much
bigger community that is not involved in the competition between
authentication methods (spam filter companies, ISPs, spam blocking
services, etc.) - that much larger community can move forward, knowing
exactly what an authentication header will look like.

As for the opposition from the DNS community, I may be wrong because I
haven't reviewed the earlier controversies, but I'll bet we can get them to
help if we address their fundamental concerns, and enlist their help in
coming up with a solution. We need them to think as proud fathers, not
jealous guardians. Surely they would like to have their invention be a key
player in the solution to a serious international problem. If not, there
are alternatives.

Here is what I see as the fundamental requirements for a standard
authentication query:
1) The authentication query must be quick and independent of any particular
method. The alternative is to have the sender declare the authentication
method in the envelope, but let's put that option aside for the moment.
2) The response must be quick and allow rejection of most forgeries with no
additional queries.

I'm tempted to suggest how this might be done, but first let's see if
anyone has objections to these requirements, or anything else we should add
at this level.

-- Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


spf2 at kitterman

Mar 29, 2005, 9:12 AM

Post #2 of 27 (2229 views)
Permalink
RE: Standard Authentication Query [In reply to]

>-----Original Message-----
>From: owner-spf-discuss [at] v2
>[mailto:owner-spf-discuss [at] v2]On Behalf Of David MacQuigg
>Sent: Tuesday, March 29, 2005 12:00 PM
>To: spf-discuss [at] v2
>Subject: [spf-discuss] Standard Authentication Query
>
>My worry is that we might get agreement within the SPF community, barely
>squeeze it through IETF, then face adamant opposition from SenderID,
>DomainKeys, and any other group that doesn't like the letters SPF in an
>authentication header.
>
>My suggestion is that we take one little step backwards and try for a
>standard that everyone can agree on (or at least make clear that their
>objections are frivolous). With a few items standardized, SPF and any
>other method can do whatever they want within the standard, and the much
>bigger community that is not involved in the competition between
>authentication methods (spam filter companies, ISPs, spam blocking
>services, etc.) - that much larger community can move forward, knowing
>exactly what an authentication header will look like.
>
For those of us who've been around through the MARID working group, I would
expect that the rough consensus is that we've already tried that. WRT
Sender ID, I doubt that there will be significant support for working with
them until MS changes the license agreement to be compatible with the GPL
(this has been explored and is apparently not in the cards).

With the exception of CSV, BATV, and SES, none of the other authentication
methods are working in the RFC 2821 envelope domain. I tend to think that
envelope authentication can proceed pretty much independently of RFC 2822
message authentication.

There are one or two internet drafts that deal with authentication headers
running around, but I don't know that a lot of progress is being made on
that front (sorry, the references escape me at the moment).

I'm, by and large, with Frank. We need to get the existing v=SPF1
documented in an experimental RFC and then move on to whatever comes next.
I do think that some added cautions wrt DNS loading and security risks may
be in order. I'm thinking that one over.

Scott Kitterman

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


dmquigg-spf at yahoo

Mar 29, 2005, 9:42 AM

Post #3 of 27 (2208 views)
Permalink
RE: Standard Authentication Query [In reply to]

At 12:12 PM 3/29/2005 -0500, Scott Kitterman wrote:

> >-----Original Message-----
> >From: owner-spf-discuss [at] v2
> >[mailto:owner-spf-discuss [at] v2]On Behalf Of David MacQuigg
> >Sent: Tuesday, March 29, 2005 12:00 PM
> >To: spf-discuss [at] v2
> >Subject: [spf-discuss] Standard Authentication Query
> >
> >My worry is that we might get agreement within the SPF community, barely
> >squeeze it through IETF, then face adamant opposition from SenderID,
> >DomainKeys, and any other group that doesn't like the letters SPF in an
> >authentication header.
> >
> >My suggestion is that we take one little step backwards and try for a
> >standard that everyone can agree on (or at least make clear that their
> >objections are frivolous). With a few items standardized, SPF and any
> >other method can do whatever they want within the standard, and the much
> >bigger community that is not involved in the competition between
> >authentication methods (spam filter companies, ISPs, spam blocking
> >services, etc.) - that much larger community can move forward, knowing
> >exactly what an authentication header will look like.
> >
>For those of us who've been around through the MARID working group, I would
>expect that the rough consensus is that we've already tried that. WRT
>Sender ID, I doubt that there will be significant support for working with
>them until MS changes the license agreement to be compatible with the GPL
>(this has been explored and is apparently not in the cards).

The IETF is probably not the place to deal with this kind of
controversy. I'm thinking the FTC might do better in dealing with hostile
competitors. ( Their main activity is anti-trust.) They have the mandate
from Congress. It is in their plan to provide a solution if the industry
doesn't provide one soon. More than any industry or standards group, the
FTC can require cooperation among hostile competitors.

I would like to see the FTC:

1) Call for a simple email authentication standard that all parties can
live with.
2) Use neutral experts to evaluate the objections to each proposal.
3) Chose the one proposal that provides the optimum tradeoff of
a) minimizing time to a workable shared standard
b) addressing all items that are nice but not essential in a shared standard
c) providing a fair basis for the different methods to compete
4) Modify the chosen proposal if necessary to achieve the optimum.
5) Promote the standard among ISPs and companies providing anti-spam
products to those ISPs.
6) Evaluate the results of competition between the various methods working
within the standard, and then decide if there is any need to mandate one or
another.

Item 3 will give some incentive to each of the competitors to give serious
thought to what the other guy needs. Some of the differences I'm seeing
between the current proposals are frivolous.

My expectation is that just starting this process will break the current
logjam. Hopefully, it will result in a voluntary standard good enough that
it is not necessary to write a detailed technical standard into law.

< snip discussion of authentication headers >

>I'm, by and large, with Frank. We need to get the existing v=SPF1
>documented in an experimental RFC and then move on to whatever comes next.
>I do think that some added cautions wrt DNS loading and security risks may
>be in order. I'm thinking that one over.

I wouldn't slow down the progress on the SPF standard, but be prepared to
make some changes to the parts relating to inter-operability.

-- Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


spf2 at kitterman

Mar 29, 2005, 9:48 AM

Post #4 of 27 (2217 views)
Permalink
RE: Standard Authentication Query [In reply to]

>-----Original Message-----
>From: owner-spf-discuss [at] v2
>[mailto:owner-spf-discuss [at] v2]On Behalf Of David MacQuigg
>Sent: Tuesday, March 29, 2005 12:43 PM
>To: spf-discuss [at] v2
>Subject: RE: [spf-discuss] Standard Authentication Query
>
>
>At 12:12 PM 3/29/2005 -0500, Scott Kitterman wrote:
>
>> >-----Original Message-----
>> >From: owner-spf-discuss [at] v2
>> >[mailto:owner-spf-discuss [at] v2]On Behalf Of David MacQuigg
>> >Sent: Tuesday, March 29, 2005 12:00 PM
>> >To: spf-discuss [at] v2
>> >Subject: [spf-discuss] Standard Authentication Query
>> >

>>I'm, by and large, with Frank. We need to get the existing v=SPF1
>>documented in an experimental RFC and then move on to whatever comes next.
>>I do think that some added cautions wrt DNS loading and security risks may
>>be in order. I'm thinking that one over.
>
>I wouldn't slow down the progress on the SPF standard, but be prepared to
>make some changes to the parts relating to inter-operability.
>
But the current RFC effort is meant to describe the CURRENT practice. I
really think that for v=SPF1 we need to limit ourselves to codifying what's
in place. I wouldn't propose any changes to the current spec that directly
affect processing or creation of records.

Scott Kitterman

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


george+spf at m5p

Mar 29, 2005, 9:55 AM

Post #5 of 27 (2189 views)
Permalink
RE: Standard Authentication Query [In reply to]

> >>I'm, by and large, with Frank. We need to get the existing v=SPF1
> >>documented in an experimental RFC and then move on to whatever comes next.
> >>I do think that some added cautions wrt DNS loading and security risks may
> >>be in order. I'm thinking that one over.
> >
> >I wouldn't slow down the progress on the SPF standard, but be prepared to
> >make some changes to the parts relating to inter-operability.
> >
> But the current RFC effort is meant to describe the CURRENT practice. I
> really think that for v=SPF1 we need to limit ourselves to codifying what's
> in place. I wouldn't propose any changes to the current spec that directly
> affect processing or creation of records.
>
> Scott Kitterman

Amen to this! Please, let's get a standard describing the status quo
out the door. In this, I agree with Frank and Scott 100%.
-- George Mitchell


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


mark at primefactor

Mar 29, 2005, 9:58 AM

Post #6 of 27 (2197 views)
Permalink
Re: Standard Authentication Query [In reply to]

On Tue, Mar 29, 2005 at 12:12:59PM -0500, Scott Kitterman wrote:
>
> I'm, by and large, with Frank. We need to get the existing v=SPF1
> documented in an experimental RFC and then move on to whatever comes next.
> I do think that some added cautions wrt DNS loading and security risks may
> be in order. I'm thinking that one over.

I'm the same way.

The design phase for spf1 is long over.

Tweaks that address DNS DOS attacks make sense to me as
acceptable modifications, but IMHO pretty much nothing else
does, outside of fixing spelling/editing/wording problems
or internal inconsistencies within the spec.

--
Mark Shewmaker
mark [at] primefactor

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


dmquigg-spf at yahoo

Mar 29, 2005, 11:25 AM

Post #7 of 27 (2209 views)
Permalink
RE: Standard Authentication Query [In reply to]

At 12:48 PM 3/29/2005 -0500, Scott Kitterman wrote:

> >>I'm, by and large, with Frank. We need to get the existing v=SPF1
> >>documented in an experimental RFC and then move on to whatever comes next.
> >>I do think that some added cautions wrt DNS loading and security risks may
> >>be in order. I'm thinking that one over.
> >
> >I wouldn't slow down the progress on the SPF standard, but be prepared to
> >make some changes to the parts relating to inter-operability.
> >
>But the current RFC effort is meant to describe the CURRENT practice. I
>really think that for v=SPF1 we need to limit ourselves to codifying what's
>in place. I wouldn't propose any changes to the current spec that directly
>affect processing or creation of records.

Most of the potential changes can be done later at very little cost. The
one I worry about is the DNS query. SPF could be facing some very
difficult rework if the final standard mandates a one-packet
response. Also, I suspect the guardians of DNS at the IETF will be unhappy
that no changes were made to address their concerns.

As I understand it, Radu's mask proposal will allow almost all domains to
provide a one-packet response, even if the mask is only a rough
approximation to their actual server addresses. If this rejects 90% of the
forgeries, that may be good enough.

I can even see a large ISP clustering all their servers so their SPF record
might be nothing but a few masks. As long as spammers can't get access to
the addresses within the mask blocks, the masks alone are good enough.

A typical top record might look like this one for rr.com:
v=spf1
m=24.30.203/24,24.28.200/24,24.28.204/24,24.30.218/24,24.93.47/24,24.25.9/24,
65.24.5/24,24.94.166/24,24.29.109/24,66.75.162/24,24.24.2/24,65.32.5/24 ...
-all
The ... redirects and such might never be needed if rr.com decides it can
clean out the zombies in each of those /24 blocks.

-- Dave

************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


spf2 at kitterman

Mar 29, 2005, 11:38 AM

Post #8 of 27 (2209 views)
Permalink
RE: Standard Authentication Query [In reply to]

>-----Original Message-----
>From: owner-spf-discuss [at] v2
>[mailto:owner-spf-discuss [at] v2]On Behalf Of David MacQuigg
>Sent: Tuesday, March 29, 2005 2:25 PM
>To: spf-discuss [at] v2
>Subject: RE: [spf-discuss] Standard Authentication Query
>
>
>At 12:48 PM 3/29/2005 -0500, Scott Kitterman wrote:
>
>> >>I'm, by and large, with Frank. We need to get the existing v=SPF1
>> >>documented in an experimental RFC and then move on to whatever
>comes next.
>> >>I do think that some added cautions wrt DNS loading and
>security risks may
>> >>be in order. I'm thinking that one over.
>> >
>> >I wouldn't slow down the progress on the SPF standard, but be
>prepared to
>> >make some changes to the parts relating to inter-operability.
>> >
>>But the current RFC effort is meant to describe the CURRENT practice. I
>>really think that for v=SPF1 we need to limit ourselves to
>codifying what's
>>in place. I wouldn't propose any changes to the current spec
>that directly
>>affect processing or creation of records.
>
>Most of the potential changes can be done later at very little cost. The
>one I worry about is the DNS query. SPF could be facing some very
>difficult rework if the final standard mandates a one-packet
>response. Also, I suspect the guardians of DNS at the IETF will
>be unhappy
>that no changes were made to address their concerns.
>
>As I understand it, Radu's mask proposal will allow almost all domains to
>provide a one-packet response, even if the mask is only a rough
>approximation to their actual server addresses. If this rejects
>90% of the
>forgeries, that may be good enough.
>
>I can even see a large ISP clustering all their servers so their
>SPF record
>might be nothing but a few masks. As long as spammers can't get access to
>the addresses within the mask blocks, the masks alone are good enough.
>
>A typical top record might look like this one for rr.com:
>v=spf1
>m=24.30.203/24,24.28.200/24,24.28.204/24,24.30.218/24,24.93.47/24,2
>4.25.9/24,
>65.24.5/24,24.94.166/24,24.29.109/24,66.75.162/24,24.24.2/24,65.32.
>5/24 ...
>-all
>The ... redirects and such might never be needed if rr.com decides it can
>clean out the zombies in each of those /24 blocks.
>
>-- Dave
>
For SPF checking libraries that don't implement the mask (currently all of
them), that record would parse as:

v=spf1 -all

The mask only has potential to help once it's deployed and senders modify
their policies to use it.

Regardless of the potential for increased effeciency, I think that a
significant change like this is going to have a hard time getting traction
in the market. If this sort of approach will appeal to people, then perhaps
we ought to concentrate in the near term on selling Frank's slightly less
efficient approach since it's fully compatible with the current syntax.

Scott Kitterman

Scott Kitterman

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


therr at security

Mar 29, 2005, 11:42 AM

Post #9 of 27 (2201 views)
Permalink
RE: Standard Authentication Query [In reply to]

On Tue, 29 Mar 2005, at 12:25, David MacQuigg wrote:

> I can even see a large ISP clustering all their servers so their SPF record
> might be nothing but a few masks. As long as spammers can't get access to
> the addresses within the mask blocks, the masks alone are good enough.
>
> A typical top record might look like this one for rr.com:
> v=spf1
> m=24.30.203/24,24.28.200/24,24.28.204/24,24.30.218/24,24.93.47/24,24.25.9/24,
> 65.24.5/24,24.94.166/24,24.29.109/24,66.75.162/24,24.24.2/24,65.32.5/24 ...
> -all
> The ... redirects and such might never be needed if rr.com decides it can
> clean out the zombies in each of those /24 blocks.

Our servers already _are_ clustered in the /24s we list; we list so
many /24s because we have our servers located in nine different
geographically dispersed data centers stretching from New York to
California, and the rules of the game as they apply to routing and
so forth do not allow us to put all nine data centers into that
many fewer /24s than what we have listed. The first four /24s
listed above are all in one geographic location, but in-house
political reasons do not allow them to be collapsed into one
/24.

The /24s in our SPF record are reserved for data center usage;
servers, network gear, etc. No customers are put in those /24s.
The zombies that are on our network are not in the /24s listed in
our SPF record. Zombies that are configured to route their spew
from the infected host through the smarthost configured on the
infected host's mail client will be rate limited, as a matter of
policy, to 1,000 messages per day.

Note too that our SPF record currently ends in ~all, not the -all
you listed here. Unless and until our AUP changes (and there's
no promise that it ever will), our SPF record will likely never
end in -all. We have customers who wish to run their own mail
servers in our residential space, and some of them even send
email from their $foo.rr.com addresses; we currently allow this
practice and make no promises that we will ever change this.

--
Todd Herr
Senior Security Policy Specialist/Postmaster V: 703.345.2447
Time Warner Cable IP Security M: 571.344.8619
therr [at] security AIM: RRCorpSecTH

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


mark at primefactor

Mar 29, 2005, 11:46 AM

Post #10 of 27 (2216 views)
Permalink
Re: Standard Authentication Query [In reply to]

On Tue, Mar 29, 2005 at 12:25:24PM -0700, David MacQuigg wrote:
>
> Also, I suspect the guardians of DNS at the IETF will be unhappy
> that no changes were made to address their concerns.

Given that there have been extensive discussions with DNS folks
over the years, can you provide links to actual concerns that
they have voiced that continue to not be addressed and that you
think should be addressed?

> A typical top record might look like this one for rr.com:
> v=spf1
> m=24.30.203/24,24.28.200/24,24.28.204/24,24.30.218/24,24.93.47/24,24.25.9/24,
> 65.24.5/24,24.94.166/24,24.29.109/24,66.75.162/24,24.24.2/24,65.32.5/24 ...
> -all

I could have sworn that the last few times this came up that
"ip4:1.2.3/24" was valid syntax. I now see that the phrasing "It is not
permitted to omit parts of the IP address instead of using CIDR
notations. That is, use 10.23.45.0/24 instead of 10.23.45." still means
that it's not completely clear whether or not "ip4:1.2.3/24" is valid.

I'm biased on saying that it should be valid, (I'll look into the
archives tonight), but either way, that wording should be clarified.

--
Mark Shewmaker
mark [at] primefactor

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


dmquigg-spf at yahoo

Mar 29, 2005, 12:37 PM

Post #11 of 27 (2205 views)
Permalink
Re: Standard Authentication Query [In reply to]

At 02:46 PM 3/29/2005 -0500, Mark wrote:

>On Tue, Mar 29, 2005 at 12:25:24PM -0700, David MacQuigg wrote:
> >
> > Also, I suspect the guardians of DNS at the IETF will be unhappy
> > that no changes were made to address their concerns.
>
>Given that there have been extensive discussions with DNS folks
>over the years, can you provide links to actual concerns that
>they have voiced that continue to not be addressed and that you
>think should be addressed?

I'm just going by what I have read on this list. As I understand it, the
objections to SPF at the vote on the last draft had to do with DNS
loading. If we can address those concerns by something as simple as adding
a modifier that doesn't break anything, I would say go for it.

I don't usually like "adding features" in a situation like this, but I
think of masks as a counter to some features that were added without much
thought as to abuse. The purpose is not to add new conveniences, but limit
abuse.

> > A typical top record might look like this one for rr.com:
> > v=spf1
> >
> m=24.30.203/24,24.28.200/24,24.28.204/24,24.30.218/24,24.93.47/24,24.25.9/24,
> > 65.24.5/24,24.94.166/24,24.29.109/24,66.75.162/24,24.24.2/24,65.32.5/24
> ...
> > -all
>
>I could have sworn that the last few times this came up that
>"ip4:1.2.3/24" was valid syntax. I now see that the phrasing "It is not
>permitted to omit parts of the IP address instead of using CIDR
>notations. That is, use 10.23.45.0/24 instead of 10.23.45." still means
>that it's not completely clear whether or not "ip4:1.2.3/24" is valid.

I think Radu addressed this point yesterday. As I understand it, we are
free to define any syntax we want within the string on the right side of
m=. Maybe to avoid confusion we should write the compact notation as
24~24.30.203.

--Dave

************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


dmquigg-spf at yahoo

Mar 29, 2005, 1:10 PM

Post #12 of 27 (2217 views)
Permalink
RE: Standard Authentication Query [In reply to]

At 02:38 PM 3/29/2005 -0500, Scott Kitterman wrote:

> >A typical top record might look like this one for rr.com:
> >v=spf1
> >m=24.30.203/24,24.28.200/24,24.28.204/24,24.30.218/24,24.93.47/24,2
> >4.25.9/24,
> >65.24.5/24,24.94.166/24,24.29.109/24,66.75.162/24,24.24.2/24,65.32.
> >5/24 ... -all
> >The ... redirects and such might never be needed if rr.com decides it can
> >clean out the zombies in each of those /24 blocks.

Which, according to Todd, is already done.

> >
> >-- Dave
> >
>For SPF checking libraries that don't implement the mask (currently all of
>them), that record would parse as:
>
>v=spf1 -all

That should be "v=spf1 ... -all". The ... was intended to include all the
usual complexities for those checkers that don't understand the new mask
notation.

>The mask only has potential to help once it's deployed and senders modify
>their policies to use it.

Both methods have to be deployed before they can help. Either of these
will have to be built into the compiler. ( I hope you are not suggesting
that we teach users to write the "not.me" syntax. We'll have to put Frank
on the help desk. :>)

>Regardless of the potential for increased effeciency, I think that a
>significant change like this is going to have a hard time getting traction
>in the market. If this sort of approach will appeal to people, then perhaps
>we ought to concentrate in the near term on selling Frank's slightly less
>efficient approach since it's fully compatible with the current syntax.

The masks will be generated automatically by a compiler. The compiler will
get market traction because it is easier and more fun than creating records
with a text editor, and it will be a webtool or a free download, not
requiring any DNS patches, etc.

The "include:not.me" syntax, as I understand it, can never provide a
one-shot DNS response, and once people start using it, we will never get
rid of it.

Spammers are not going to give up their lucrative business without a
fight. I can easily imagine them turning up the volume by a factor of 10
or even 100. I like the idea of having as the final defense, a "one-query"
mode where 90% of the legitimate mail gets through, and the spammers are
rejected at a cost not much more than they spend in sending their sh*t.

-- Dave

************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


spf2 at kitterman

Mar 29, 2005, 1:32 PM

Post #13 of 27 (2215 views)
Permalink
RE: Standard Authentication Query [In reply to]

>-----Original Message-----
>From: owner-spf-discuss [at] v2
>[mailto:owner-spf-discuss [at] v2]On Behalf Of David MacQuigg
>Sent: Tuesday, March 29, 2005 4:10 PM
>To: spf-discuss [at] v2
>Subject: RE: [spf-discuss] Standard Authentication Query
>
>
>At 02:38 PM 3/29/2005 -0500, Scott Kitterman wrote:
>
>> >A typical top record might look like this one for rr.com:
>> >v=spf1
>> >m=24.30.203/24,24.28.200/24,24.28.204/24,24.30.218/24,24.93.47/24,2
>> >4.25.9/24,
>> >65.24.5/24,24.94.166/24,24.29.109/24,66.75.162/24,24.24.2/24,65.32.
>> >5/24 ... -all
>> >The ... redirects and such might never be needed if rr.com
>decides it can
>> >clean out the zombies in each of those /24 blocks.
>
>Which, according to Todd, is already done.
>
>> >
>> >-- Dave
>> >
>>For SPF checking libraries that don't implement the mask (currently all of
>>them), that record would parse as:
>>
>>v=spf1 -all
>
>That should be "v=spf1 ... -all". The ... was intended to include all the
>usual complexities for those checkers that don't understand the new mask
>notation.
>
>>The mask only has potential to help once it's deployed and senders modify
>>their policies to use it.
>
>Both methods have to be deployed before they can help. Either of these
>will have to be built into the compiler. ( I hope you are not suggesting
>that we teach users to write the "not.me" syntax. We'll have to put Frank
>on the help desk. :>)
>
>>Regardless of the potential for increased effeciency, I think that a
>>significant change like this is going to have a hard time getting traction
>>in the market. If this sort of approach will appeal to people,
>then perhaps
>>we ought to concentrate in the near term on selling Frank's slightly less
>>efficient approach since it's fully compatible with the current syntax.
>
>The masks will be generated automatically by a compiler. The
>compiler will
>get market traction because it is easier and more fun than
>creating records
>with a text editor, and it will be a webtool or a free download, not
>requiring any DNS patches, etc.
>
>The "include:not.me" syntax, as I understand it, can never provide a
>one-shot DNS response, and once people start using it, we will never get
>rid of it.
>
>Spammers are not going to give up their lucrative business without a
>fight. I can easily imagine them turning up the volume by a factor of 10
>or even 100. I like the idea of having as the final defense, a
>"one-query"
>mode where 90% of the legitimate mail gets through, and the spammers are
>rejected at a cost not much more than they spend in sending their sh*t.
>
>-- Dave
>
Maybe the compiler could have an option to spit out either m= or
"include:not.me".

"include:not.me" can be deployed today.

Most of the people that come to spf-help or send e-mail that ends up on the
spf help rt have rather simple records. In fact, most of them need simpler
records than they think they do based on the wizard. Updating the wizards
to lead people towards tighter records would be a good thing to do too (I
see of lot of records with ptr in it that don't need it).

As one of the people active in both those venues, if someone will write the
compiler/script to produce the "include:not.me" record, I'll support and
push it.

No matter how wonderful m= is, it can't be used until it's deployed. If we
had a decent script, we could start doing "include:not.me" today.

Scott Kitterman

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


radu at ohmi

Mar 29, 2005, 1:54 PM

Post #14 of 27 (2215 views)
Permalink
Re: Standard Authentication Query [In reply to]

Todd Herr wrote:
> On Tue, 29 Mar 2005, at 12:25, David MacQuigg wrote:
>
>
>>I can even see a large ISP clustering all their servers so their SPF record
>>might be nothing but a few masks. As long as spammers can't get access to
>>the addresses within the mask blocks, the masks alone are good enough.
>>
>>A typical top record might look like this one for rr.com:
>>v=spf1
>>m=24.30.203/24,24.28.200/24,24.28.204/24,24.30.218/24,24.93.47/24,24.25.9/24,
>>65.24.5/24,24.94.166/24,24.29.109/24,66.75.162/24,24.24.2/24,65.32.5/24 ...
>>-all
>>The ... redirects and such might never be needed if rr.com decides it can
>>clean out the zombies in each of those /24 blocks.

I have two points to make:

1. Masks are only useful for records that *must* span multiple TXT
records any way. Otherwise, for single-record policies, they will *not*
be added.

2. Only a compiler should be trusted to make best use of the available
number of bytes for a mask. If a policy compiles to 600 bytes of IPs, it
must therefore span 2 packets, which leaves 300bytes available for a
mask in the first record. (assuming 450-bytes payload per packet). Only
a compiler should be trusted to use any balanced-binary-tree algorithms
necessary to find the best mask.


Let's pick a more realistic example. I picked the rr.com SPF record:
compiling it without masks gives:

rr.com 300 TXT "v=spf1 ip4:24.30.203.0/24
ip4:24.28.200.0/24 ip4:24.28.204.0/24 ip4:24.30.218.0/24
ip4:24.93.47.0/24 ip4:24.25.9.0/24 ip4:65.24.5.0/24
ip4:24.94.166.0/24 ip4:24.29.109.0/24 ip4:66.75.162.0/24
ip4:24.24.2.0/24 ip4:65.32.5.0/24 ip4:66.75.160.130
ip4:66.75.160.136 ip4:66.75.160.12 ip4:66.75.160.13
ip4:65.24.7.10 ip4:65.24.7.11 ip4:65.24.7.12 ip4:65.24.7.13
ip4:66.75.160.128 ip4:66.75.160.129 ip4:65.32.1.38 ip4:65.32.1.42
ip4:65.32.1.49 redirect=_s0.%{o}"

_s0.rr.com 300 TXT "v=spf1 ip4:24.28.193.148
ip4:24.28.193.149 ip4:24.30.200.18 ip4:24.29.99.40
ip4:24.29.99.41 ip4:24.92.226.25 ip4:24.92.226.31
ip4:24.92.226.159 ip4:24.92.226.164 ip4:24.94.163.190
ip4:24.94.165.190 ip4:24.93.40.210 ip4:24.93.40.211
ip4:24.93.40.212 ip4:24.93.40.214 ip4:24.25.4.95 ip4:24.25.4.96
ip4:24.25.4.97 ~all"

Note that my compiler does not yet sort the IP entries. When I add the
masks, sorting will make a huge difference. Then all the one-off IP
addresses will be put at rr.com, and all the addresses that are clumped
closely will be left for the second record, as that will make the mask
even more narrow.

In the above output, the first record has 443 bytes. The second has 336
bytes. Thus, the mask-capable compiler would move approx 114 bytes from
the first record to the second (_s0.rr.com).

Then, it would have 121-bytes available in the firs record for a mask to
represent an approximation of the second record.

For instance, without the shuffle, the second record's mask might be:

m=~24.24/14,24.92/14

In practice, it will be more narrow, as the above didn't use close to
the 121 bytes available for a better mask.

So, with only 20 bytes, the compiler communicated that all the addreses
in _s0.rr.com pertain to a range of addresses of only 2^19. Compared to
the total IP space of 2^32, this represents 0.0122% of the total
available IP space. This means that for a complex record like RR's, The
mask saves the second query 99.988% of the time. In actuality, the
savings will be even more impressive, if the compiler would use the
entire available 121 bytes to specify the most narrow mask possible.

There's no reason to worry about the argument that the routable IP space
is actually 2^32-2^23-2^16. The percentages would not change much.

At the same time, the mask has communicated that the second record ends
with ~all.

Radu.

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


radu at ohmi

Mar 29, 2005, 2:00 PM

Post #15 of 27 (2214 views)
Permalink
Re: Standard Authentication Query [In reply to]

Mark Shewmaker wrote:
> On Tue, Mar 29, 2005 at 12:25:24PM -0700, David MacQuigg wrote:
>
>>Also, I suspect the guardians of DNS at the IETF will be unhappy
>>that no changes were made to address their concerns.
>
>
> Given that there have been extensive discussions with DNS folks
> over the years, can you provide links to actual concerns that
> they have voiced that continue to not be addressed and that you
> think should be addressed?
>
>
>>A typical top record might look like this one for rr.com:
>>v=spf1
>>m=24.30.203/24,24.28.200/24,24.28.204/24,24.30.218/24,24.93.47/24,24.25.9/24,
>>65.24.5/24,24.94.166/24,24.29.109/24,66.75.162/24,24.24.2/24,65.32.5/24 ...
>>-all
>
>
> I could have sworn that the last few times this came up that
> "ip4:1.2.3/24" was valid syntax. I now see that the phrasing "It is not
> permitted to omit parts of the IP address instead of using CIDR
> notations. That is, use 10.23.45.0/24 instead of 10.23.45." still means
> that it's not completely clear whether or not "ip4:1.2.3/24" is valid.
>
> I'm biased on saying that it should be valid, (I'll look into the
> archives tonight), but either way, that wording should be clarified.

It's not the archives that make it invalid, it's the current draft and
the fact that all existent implementations would report a syntax error
if we suddenly start publishing mechanisms with the new syntax.

The bottom line is that the current syntax must not change.

Radu.

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


dmquigg-spf at yahoo

Mar 29, 2005, 3:12 PM

Post #16 of 27 (2215 views)
Permalink
RE: Standard Authentication Query [In reply to]

At 02:42 PM 3/29/2005 -0500, Todd wrote:

>On Tue, 29 Mar 2005, at 12:25, David MacQuigg wrote:
>
> > I can even see a large ISP clustering all their servers so their SPF record
> > might be nothing but a few masks. As long as spammers can't get access to
> > the addresses within the mask blocks, the masks alone are good enough.
> >
> > A typical top record might look like this one for rr.com:
> > v=spf1
> >
> m=24.30.203/24,24.28.200/24,24.28.204/24,24.30.218/24,24.93.47/24,24.25.9/24,
> > 65.24.5/24,24.94.166/24,24.29.109/24,66.75.162/24,24.24.2/24,65.32.5/24 ...
> > -all
> > The ... redirects and such might never be needed if rr.com decides it can
> > clean out the zombies in each of those /24 blocks.
>
>Our servers already _are_ clustered in the /24s we list; we list so
>many /24s because we have our servers located in nine different
>geographically dispersed data centers stretching from New York to
>California, and the rules of the game as they apply to routing and
>so forth do not allow us to put all nine data centers into that
>many fewer /24s than what we have listed. The first four /24s
>listed above are all in one geographic location, but in-house
>political reasons do not allow them to be collapsed into one
>/24.
>
>The /24s in our SPF record are reserved for data center usage;
>servers, network gear, etc. No customers are put in those /24s.
>The zombies that are on our network are not in the /24s listed in
>our SPF record. Zombies that are configured to route their spew
>from the infected host through the smarthost configured on the
>infected host's mail client will be rate limited, as a matter of
>policy, to 1,000 messages per day.

This is good policy. Do you have any numbers on how well it is
working? AOL claims to have *no* outgoing spam. I checked their claim
with a sample of reports from SpamCop, and it looks good. See my chart
Domain Ratings at http://purl.net/net/edatools/email It looks like AOL is
100X better than Charter or Sprint. Unfortunately, I can't bug my contact
for any more data, and I don't know how to extract it from any public
reports. This is a very small sample, and I'm not even sure if the
"methodology" is correct. Seems like SpamCop can't make any distinction
between an authorized sending IP and one which is merely in your address
space. If we are going to promote SPF as having a benefit to email
*senders*, we need to not ding them for anything other than the spam coming
from their authorized servers.

>Note too that our SPF record currently ends in ~all, not the -all
>you listed here. Unless and until our AUP changes (and there's
>no promise that it ever will), our SPF record will likely never
>end in -all. We have customers who wish to run their own mail
>servers in our residential space, and some of them even send
>email from their $foo.rr.com addresses; we currently allow this
>practice and make no promises that we will ever change this.

If the /24 blocks above are *exclusively* for your own servers, and
*cannot* contain a customer IP, then there should be no problem with
zombie-generated spam spoiling the reputation of rr.com. As long as they
can't hijack an authorized server, they can't claim to be sending on behalf
of rr.com (at least to anyone who bothers to check your SPF record).

One thing that isn't clear to me, and perhaps someone else can comment,
what happens if the spammer has an IP assigned by rr.com AND a *subdomain*
from rr.com? My guess is the subdomain will inherit the reputation of
rr.com, and will also have the opportunity to ruin it. It seems like
rr.com would be wise to put these residential mail servers under a
different name, maybe rrhome.com, or if they are a serious business, have
them use their own name.

-- Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


william at elan

Mar 29, 2005, 9:07 PM

Post #17 of 27 (2200 views)
Permalink
Re: Standard Authentication Query [In reply to]

On Tue, 29 Mar 2005, David MacQuigg wrote:

> I'm just going by what I have read on this list. As I understand it, the
> objections to SPF at the vote on the last draft had to do with DNS loading.

It has to do with problems in design and higher dns load is just a
visible end-result of those. Particularly various IETF people and those
involved in dns have problems with:
1. (Ab)use of of TXT record
2. Use of dns for what amounts to general-purpose email policy database
3. Structure of SPF is not properly layered and technically wrong.
What may seem like a convinience to some of yoy as far as being
able to define both hosts with "a" and "mx" operators and ip
addresses directly with "ip4" is not correct way to do such design
(and that is obvious to almost every serious protocol engineer).
It should first be layer listing hosts/networks authorized to act
on behalf of given domain and then those hosts ip addresses may be
further looked (if this is needed, which is not necessary if host
is already verified in some other way) in dns. Basicly RMX
or Paul Vixie's MAIL-FROM is a lot more cleaner design...
4. This structure of many spf operators and macros may cause high dns
load and this load is not always easy to predict and because of
the incorrect layered design there is possibility of loops and
security issues that otherwise could be taken care of easily.

> If we can address those concerns by something as simple as adding a modifier
> that doesn't break anything, I would say go for it.

You can't address major concerns with simple modifier.

> I don't usually like "adding features" in a situation like this, but I think
> of masks as a counter to some features that were added without much thought
> as to abuse. The purpose is not to add new conveniences, but limit abuse.
...
> I think Radu addressed this point yesterday. As I understand it, we are free
> to define any syntax we want within the string on the right side of m=.
> Maybe to avoid confusion we should write the compact notation as
> 24~24.30.203.

The purpose of spf-classic draft is to document current use of SPF and you
can't go walking around with major change to syntax that would not be
undertood by current SPF clients as many people pointed before. If you are
interested in contributions and changes to syntax, those would need to go
to next step in development of SPF (likely SPF3 as SPF2 has been
"contaminated" by MARID experience and further anauthorized use for
so-called SenderID drafts). There are many things to talk about for next
SPF and I was hoping the formation of the council would have helped to
quickly resolve SPF1 issues and move those along and that now we'd be well
on the way of working on UnifiedSPF and next version of SPF record.
Unfortunetly SPF council has been slow and UnifiedSPF has not been
mentioned in almost 4-6 months...

--
William Leibzon
Elan Networks
william [at] elan

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


therr at security

Mar 30, 2005, 8:02 AM

Post #18 of 27 (2213 views)
Permalink
RE: Standard Authentication Query [In reply to]

On Tue, 29 Mar 2005, at 16:12, David MacQuigg wrote:

> At 02:42 PM 3/29/2005 -0500, Todd wrote:
>
> >The /24s in our SPF record are reserved for data center usage;
> >servers, network gear, etc. No customers are put in those /24s.
> >The zombies that are on our network are not in the /24s listed in
> >our SPF record. Zombies that are configured to route their spew
> >from the infected host through the smarthost configured on the
> >infected host's mail client will be rate limited, as a matter of
> >policy, to 1,000 messages per day.
>
> This is good policy. Do you have any numbers on how well it is
> working? AOL claims to have *no* outgoing spam. I checked their claim

We make no such claims; we have outgoing spam, and neither SPF
nor any of the competing technologies will solve that problem
for us.

[snip]

> >Note too that our SPF record currently ends in ~all, not the -all
> >you listed here. Unless and until our AUP changes (and there's
> >no promise that it ever will), our SPF record will likely never
> >end in -all. We have customers who wish to run their own mail
> >servers in our residential space, and some of them even send
> >email from their $foo.rr.com addresses; we currently allow this
> >practice and make no promises that we will ever change this.
>
> If the /24 blocks above are *exclusively* for your own servers, and
> *cannot* contain a customer IP, then there should be no problem with
> zombie-generated spam spoiling the reputation of rr.com. As long as they
> can't hijack an authorized server, they can't claim to be sending on behalf
> of rr.com (at least to anyone who bothers to check your SPF record).

The likelihood of any legitimate mail with a sender whose address
ends in @rr.com approaches zero so rapidly as to almost be
non-existent, regardless of the SPF record we publish. We have
seized upon SPF as a standards-based framework for providing the
answer to the human-to-human question that we sometimes receive,
mostly from other ISPs; mainly, "Tell us where your outbound
servers are so that we may identify traffic from them as opposed
to the rest of your space". The naming schemes we have used for
our servers, and the domains in which the PTR records for their
IP addresses reside, have caused some confusion over the years
with those who maintain lists of dynamic space, and some of our
servers have been incorrectly listed as being in dynamic space
from time to time. SPF gives us an easy way to address this
problem in a language that is easily understood, and provides us
a way to provide the answer to anyone who wants it, so long as
they have the ability to issue a simple DNS query.

All that aside, the ~all bit in our SPF record means "SPF
Neutral", as I understand it. This means, as I understand
things, that Road Runner neither confirms nor denies that a
given IP not explicitly mentioned in our SPF record can be a
legitimate source of mail from Road Runner. The receiving
domain doing the SPF checking can either accept or reject email
from an IP not explicitly mentioned in our SPF record, and both
decisions would be correct, as I understand things.

>
> One thing that isn't clear to me, and perhaps someone else can comment,
> what happens if the spammer has an IP assigned by rr.com AND a *subdomain*
> from rr.com? My guess is the subdomain will inherit the reputation of
> rr.com, and will also have the opportunity to ruin it. It seems like
> rr.com would be wise to put these residential mail servers under a
> different name, maybe rrhome.com, or if they are a serious business, have
> them use their own name.
>

I'm not clear on what you mean when you say, "what happens if the
spammer has an IP assigned by rr.com AND a *subdomain* from
rr.com?". In lieu of my understanding what you mean, and given
that Road Runner's reputation in the anti-spam community is mixed
at best, let me describe the reality of the Road Runner customer
and DNS names associated therewith.

Any customer IP assigned by Road Runner in our residential space
will soon have a PTR record ending in 'res.rr.com'; we're
transitioning all of our residential space to this naming scheme,
and expect to be finished shortly.

What this means is that Joe, a Road Runner customer of the
Milwaukee, WI, Time Warner Cable division, who has IP address
69.76.120.59, will have the following information "associated"
with him:

email address: joe [at] wi
PTR record for cable modem: CPE-69-76-120-59.wi.res.rr.com

(Prior to the res.rr.com migration, Joe's IP address would've had
a PTR record of CPE-69-76-120-59.wi.rr.com.)

We do not provide non-default names for residential customers.
No customer will ever have an email address ending in
'res.rr.com'.

The only subdomains of rr.com are names used to indicate either a
Time Warner Cable division or some other Road Runner-specific
indicator; there is no possibility of a name such as
"joesgarage.rr.com" existing, ever.

Business Class customers are given IP addresses whose default PTR
records resolve to one of the following eight patterns, assuming
IP address A.B.C.D:

rrcs-A-B-C-D.central.biz.rr.com
rrcs-A-B-C-D.ma.biz.rr.com
rrcs-A-B-C-D.midsouth.biz.rr.com
rrcs-A-B-C-D.nyc.biz.rr.com
rrcs-A-B-C-D.nys.biz.rr.com
rrcs-A-B-C-D.se.biz.rr.com
rrcs-A-B-C-D.sw.biz.rr.com
rrcs-A-B-C-D.west.biz.rr.com

For those Business Class customers who have their own domains and
wish to have non-default PTR records, we provide that service,
but again, the PTR record would not be "joesgarage.biz.rr.com";
rather, it would be "joesgarage.com", "www.joesgarage.com",
"mail.joesgarage.com", and the like.

Hopefully, that clears things up for you.

--
Todd Herr
Senior Security Policy Specialist/Postmaster V: 703.345.2447
Time Warner Cable IP Security M: 571.344.8619
therr [at] security AIM: RRCorpSecTH

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


spf2 at kitterman

Mar 30, 2005, 8:21 AM

Post #19 of 27 (2213 views)
Permalink
RE: Standard Authentication Query [In reply to]

>-----Original Message-----
>From: owner-spf-discuss [at] v2
>[mailto:owner-spf-discuss [at] v2]On Behalf Of Todd Herr
>Sent: Wednesday, March 30, 2005 11:02 AM
>To: spf-discuss [at] v2
>Subject: RE: [spf-discuss] Standard Authentication Query
snip

>All that aside, the ~all bit in our SPF record means "SPF
>Neutral", as I understand it. This means, as I understand
>things, that Road Runner neither confirms nor denies that a
>given IP not explicitly mentioned in our SPF record can be a
>legitimate source of mail from Road Runner. The receiving
>domain doing the SPF checking can either accept or reject email
>from an IP not explicitly mentioned in our SPF record, and both
>decisions would be correct, as I understand things.
snip

?all = neutral
~all = softfail

From http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-00.txt

2.5.2 Neutral

The domain owner has explicitly stated that doesn't know whether the
IP is authorized or not. A Neutral result MUST be treated exactly
like the None result.

i.e. do the same thing you would do if there was no SPF record.

2.5.5 SoftFail

A SoftFail result should be treated as somewhere between a Fail and a
Neutral. The domain believes the host isn't authorized but isn't
willing to make that strong of a statement. Receiving software
SHOULD NOT reject the message based on this result, but MAY subject
the message to closer scrutiny.

Since the domain has discouraged the use of this host, receivers MAY
try to inform either the sender or the recipient of the e-mail. As
examples, the recipient's MUA could highlight the SoftFail status.
Or the MTA could give the sender a message using a technique called
"greylisting" where by the MTA can issue an SMTP reply code of 451
(4.3.0 DSN code) with a note the first time the message was received,
but accept it the second time.

Based on the latest draft, the should not reject either, but particularly in
the case of a SoftFail, may do some extra processing on it. It sounds to me
like what is in your current record (SoftFail) is actually what you want.

Scott Kitterman

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


therr at security

Mar 30, 2005, 8:51 AM

Post #20 of 27 (2214 views)
Permalink
RE: Standard Authentication Query [In reply to]

On Wed, 30 Mar 2005, at 11:21, Scott Kitterman wrote:

>From: owner-spf-discuss [at] v2
>[mailto:owner-spf-discuss [at] v2]On Behalf Of Todd Herr
>
> >All that aside, the ~all bit in our SPF record means "SPF
> >Neutral", as I understand it. This means, as I understand
> >things, that Road Runner neither confirms nor denies that a
> >given IP not explicitly mentioned in our SPF record can be a
> >legitimate source of mail from Road Runner. The receiving
> >domain doing the SPF checking can either accept or reject email
> >from an IP not explicitly mentioned in our SPF record, and both
> >decisions would be correct, as I understand things.
> snip
>
> ?all = neutral
> ~all = softfail
>
> >From http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-00.txt
>
[snip]
>
> Based on the latest draft, the should not reject either, but particularly in
> the case of a SoftFail, may do some extra processing on it. It sounds to me
> like what is in your current record (SoftFail) is actually what you want.

I think you're right; thanks for the clarification.

--
Todd Herr
Senior Security Policy Specialist/Postmaster V: 703.345.2447
Time Warner Cable IP Security M: 571.344.8619
therr [at] security AIM: RRCorpSecTH

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


dmquigg-spf at yahoo

Mar 30, 2005, 10:32 AM

Post #21 of 27 (2217 views)
Permalink
RE: Standard Authentication Query [In reply to]

At 11:02 AM 3/30/2005 -0500, Todd wrote:
>On Tue, 29 Mar 2005, at 16:12, David MacQuigg wrote:
> >
> > One thing that isn't clear to me, and perhaps someone else can comment,
> > what happens if the spammer has an IP assigned by rr.com AND a *subdomain*
> > from rr.com? My guess is the subdomain will inherit the reputation of
> > rr.com, and will also have the opportunity to ruin it. It seems like
> > rr.com would be wise to put these residential mail servers under a
> > different name, maybe rrhome.com, or if they are a serious business, have
> > them use their own name.
>
>I'm not clear on what you mean when you say, "what happens if the
>spammer has an IP assigned by rr.com AND a *subdomain* from
>rr.com?". In lieu of my understanding what you mean, and given
>that Road Runner's reputation in the anti-spam community is mixed
>at best, let me describe the reality of the Road Runner customer
>and DNS names associated therewith.

You gave the example earlier of allowing a residential customer to send
mail from $foo.rr.com, and I assumed you were assigning lots of $foo
subdomains to whoever wanted one. That could result in mistrust of any
subdomain under rr.com. The policy you describe below is much different
than my assumption.

>Any customer IP assigned by Road Runner in our residential space
>will soon have a PTR record ending in 'res.rr.com'; we're
>transitioning all of our residential space to this naming scheme,
>and expect to be finished shortly.
>
>What this means is that Joe, a Road Runner customer of the
>Milwaukee, WI, Time Warner Cable division, who has IP address
>69.76.120.59, will have the following information "associated"
>with him:
>
> email address: joe [at] wi
> PTR record for cable modem: CPE-69-76-120-59.wi.res.rr.com
>
>(Prior to the res.rr.com migration, Joe's IP address would've had
>a PTR record of CPE-69-76-120-59.wi.rr.com.)
>
>We do not provide non-default names for residential customers.
>No customer will ever have an email address ending in
>'res.rr.com'.
>
>The only subdomains of rr.com are names used to indicate either a
>Time Warner Cable division or some other Road Runner-specific
>indicator; there is no possibility of a name such as
>"joesgarage.rr.com" existing, ever.
>
>Business Class customers are given IP addresses whose default PTR
>records resolve to one of the following eight patterns, assuming
>IP address A.B.C.D:
>
> rrcs-A-B-C-D.central.biz.rr.com
> rrcs-A-B-C-D.ma.biz.rr.com
> rrcs-A-B-C-D.midsouth.biz.rr.com
> rrcs-A-B-C-D.nyc.biz.rr.com
> rrcs-A-B-C-D.nys.biz.rr.com
> rrcs-A-B-C-D.se.biz.rr.com
> rrcs-A-B-C-D.sw.biz.rr.com
> rrcs-A-B-C-D.west.biz.rr.com
>
>For those Business Class customers who have their own domains and
>wish to have non-default PTR records, we provide that service,
>but again, the PTR record would not be "joesgarage.biz.rr.com";
>rather, it would be "joesgarage.com", "www.joesgarage.com",
>"mail.joesgarage.com", and the like.
>
>Hopefully, that clears things up for you.

Yes, and thank you. This is a good description of how mail servers can be
properly organized for a large, geographically distributed ISP. Putting
all the residential customers under res.rr.com is simple and clear, and you
might even want to add an SPF record for that subdomain "v=spf1 -all",
assuming you really intend that residential customers be not authorized to
operate public mail servers.

One thing I'm not clear on is whether an address like
CPE-69-76-120-59.wi.res.rr.com can be SPF-blocked at the res.rr.com level,
or whether you need to have SPF records for all the subdomains below
that. I wish I knew more about DNS.

Another question is whether there might be "cross-pollution" between the
different biz.rr.com subdomains. Ideally, each should have its own
reputation to gain or lose, but there may be a problem with how many names
a reputation service is willing to keep track of. If they just provide one
rating for all of biz.rr.com, then one spammer.biz.rr.com could ruin the
whole group. You might want to say any business that wants to operate its
own public mail server should do like joesgarage.com and get their own
name. Then you can SPF-block the entire biz.rr.com subdomain, and be done
with it.

-- Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


dmquigg-spf at yahoo

Mar 30, 2005, 10:36 AM

Post #22 of 27 (2214 views)
Permalink
Re: Standard Authentication Query [In reply to]

At 09:07 PM 3/29/2005 -0800, William Leibzon wrote:
>On Tue, 29 Mar 2005, David MacQuigg wrote:
>
>>I'm just going by what I have read on this list. As I understand it, the
>>objections to SPF at the vote on the last draft had to do with DNS loading.
>
>It has to do with problems in design and higher dns load is just a visible
>end-result of those. Particularly various IETF people and those involved
>in dns have problems with:
> 1. (Ab)use of of TXT record
> 2. Use of dns for what amounts to general-purpose email policy database
> 3. Structure of SPF is not properly layered and technically wrong.
> What may seem like a convinience to some of yoy as far as being
> able to define both hosts with "a" and "mx" operators and ip
> addresses directly with "ip4" is not correct way to do such design
> (and that is obvious to almost every serious protocol engineer).
> It should first be layer listing hosts/networks authorized to act
> on behalf of given domain and then those hosts ip addresses may be
> further looked (if this is needed, which is not necessary if host
> is already verified in some other way) in dns. Basicly RMX
> or Paul Vixie's MAIL-FROM is a lot more cleaner design...
> 4. This structure of many spf operators and macros may cause high dns
> load and this load is not always easy to predict and because of
> the incorrect layered design there is possibility of loops and
> security issues that otherwise could be taken care of easily.

As I understand it, these all relate to DNS loading. In other words, if
loading were not a concern, these flaws in design would be a minor issue.

>>If we can address those concerns by something as simple as adding a
>>modifier that doesn't break anything, I would say go for it.
>
>You can't address major concerns with simple modifier.

If we could limit DNS queries to one per email (even just in a special
"defense mode") would that not address the major concerns? My expectation
is that mail system admins would invoke this "defense mode" for only a few
hours, until the DoS storm subsided, and 90% of the legitimate mail would
get through, even during the most intense parts of the storm.

Think positive!! We have a problem with the potential abuse of DNS. How
would you solve this problem, if you really wanted to?

>>I don't usually like "adding features" in a situation like this, but I
>>think of masks as a counter to some features that were added without much
>>thought as to abuse. The purpose is not to add new conveniences, but
>>limit abuse.
>...
>>I think Radu addressed this point yesterday. As I understand it, we are
>>free to define any syntax we want within the string on the right side of
>>m=. Maybe to avoid confusion we should write the compact notation as
>>24~24.30.203.
>
>The purpose of spf-classic draft is to document current use of SPF and you
>can't go walking around with major change to syntax that would not be
>undertood by current SPF clients as many people pointed before.

I don't know the history, but it is my understanding that we need to
address the DNS loading issue in SPF1. Maybe the council could give us
some guidance on that. I don't see the m= proposal as a "major change in
syntax". Using the "unknown modifier" is extending the syntax in a way
that was anticipated. Current SPF clients will simply ignore it.

>If you are interested in contributions and changes to syntax, those would
>need to go to next step in development of SPF (likely SPF3 as SPF2 has
>been "contaminated" by MARID experience and further anauthorized use for
>so-called SenderID drafts). There are many things to talk about for next
>SPF and I was hoping the formation of the council would have helped to
>quickly resolve SPF1 issues and move those along and that now we'd be well
>on the way of working on UnifiedSPF and next version of SPF record.
>Unfortunetly SPF council has been slow and UnifiedSPF has not been
>mentioned in almost 4-6 months...

I expect at some point there will be a unified standard allowing
interoperability of the most prevalent methods. This could
include methods as different as SenderID/SPF and DomainKeys. I'll be
happy to participate in that development.

-- Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


dmquigg-spf at yahoo

Mar 30, 2005, 10:53 AM

Post #23 of 27 (2213 views)
Permalink
RE: Standard Authentication Query [In reply to]

At 04:32 PM 3/29/2005 -0500, Scott wrote:

> >>Regardless of the potential for increased effeciency, I think that a
> >>significant change like this is going to have a hard time getting traction
> >>in the market. If this sort of approach will appeal to people,
> >then perhaps
> >>we ought to concentrate in the near term on selling Frank's slightly less
> >>efficient approach since it's fully compatible with the current syntax.
> >
> >The masks will be generated automatically by a compiler. The
> >compiler will
> >get market traction because it is easier and more fun than
> >creating records
> >with a text editor, and it will be a webtool or a free download, not
> >requiring any DNS patches, etc.
> >
> >The "include:not.me" syntax, as I understand it, can never provide a
> >one-shot DNS response, and once people start using it, we will never get
> >rid of it.
> >
> >Spammers are not going to give up their lucrative business without a
> >fight. I can easily imagine them turning up the volume by a factor of 10
> >or even 100. I like the idea of having as the final defense, a
> >"one-query"
> >mode where 90% of the legitimate mail gets through, and the spammers are
> >rejected at a cost not much more than they spend in sending their sh*t.

>Maybe the compiler could have an option to spit out either m= or
>"include:not.me".

Feels like a kludge, especially if it encourages people to start writing
masks manually.

>"include:not.me" can be deployed today.

The "not.me" syntax will need a few months to write, test, and deploy the
compiler. The m= syntax might take a little longer for SPF checkers to be
upgraded. The not.me syntax requires a minimum of two queries. The m=
syntax can provide a one-query authentication check in the critical
situation, a DoS attack. So we need to weigh the urgency of getting this
widely deployed vs a better long-term solution.

I'm leaning toward the better long-term solution. I don't see the urgency
for deployment. It will be a long time before the whole world is using
SPF. I do see some urgency in responding to the DNS worries, and getting
this into the draft.

We could also respond by formalizing the "one-query defense mode" for
receivers, and urge all senders to reduce their SPF records to one
query. The example of rr.com shows how even a really large, geographically
dispersed domain can do this. Any domain that has a more-than-one-query
record might get some temporary failure notices during a DoS attack on one
of their recipients or forwarders.

Do we need both a defense mode and an m= shortcut? I guess that depends on
how many domains truly need more-than-one-query SPF records.

-- Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


Webmaster at Commerco

Mar 30, 2005, 12:47 PM

Post #24 of 27 (2215 views)
Permalink
RE: Standard Authentication Query [In reply to]

Dave,

At 11:32 AM 3/30/2005, you wrote:
>At 11:02 AM 3/30/2005 -0500, Todd wrote:
>>On Tue, 29 Mar 2005, at 16:12, David MacQuigg wrote:
>> >
.. snip ..
>One thing I'm not clear on is whether an address like
>CPE-69-76-120-59.wi.res.rr.com can be SPF-blocked at the res.rr.com level,
>or whether you need to have SPF records for all the subdomains below
>that. I wish I knew more about DNS.

I think the short answer is yes. Another question to consider might be how
best to implement such a solution.

I can think of two ways:
1) Have a TXT record set up for each zone A entry (Ugly without automation
and makes for bigger zone files).
2) Use DNS wildcard capability and point the TXT record on wildcard sub
zones back to
a common entry. For example:
$ORIGIN sub1.suba.domain.tld.
* 86400 IN A nnn.nnn.nnn.nnn
* 86400 IN TXT "v=spf1 redirect=_spf.suba.domain.tld"
would point all entries under sub1.suba.domain.tld back to the suba SPF
rules TXT at _spf.suba.domain.tld

Depending upon the environment, one would probably make more sense than the
other. Using DNS wildcard tends to require a bit more management.

>Another question is whether there might be "cross-pollution" between the
>different biz.rr.com subdomains. Ideally, each should have its own
>reputation to gain or lose, but there may be a problem with how many names
>a reputation service is willing to keep track of. If they just provide
>one rating for all of biz.rr.com, then one spammer.biz.rr.com could ruin
>the whole group. You might want to say any business that wants to operate
>its own public mail server should do like joesgarage.com and get their own
>name. Then you can SPF-block the entire biz.rr.com subdomain, and be done
>with it.

Not sure this would be a problem, think about some of the international
country TLDs that break out domains into tertiary and further zone splits.

>-- Dave
>************************************************************ *
>* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
>* IC Design Engineer phone: USA 520-721-4583 * * *
>* Analog Design Methodologies * * *
>* 9320 East Mikelyn Lane * * *
>* VRS Consulting, P.C. Tucson, Arizona 85710 *
>************************************************************ *

Best,

Alan Maitland
WebMaster [at] Commerco
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2


spf2 at kitterman

Mar 31, 2005, 8:15 AM

Post #25 of 27 (2224 views)
Permalink
RE: Standard Authentication Query [In reply to]

>-----Original Message-----
>From: owner-spf-discuss [at] v2
>[mailto:owner-spf-discuss [at] v2]On Behalf Of David MacQuigg
>Sent: Wednesday, March 30, 2005 1:53 PM
>To: spf-discuss [at] v2
>Subject: RE: [spf-discuss] Standard Authentication Query
>
>
>At 04:32 PM 3/29/2005 -0500, Scott wrote:
>
>> >>Regardless of the potential for increased effeciency, I think that a
>> >>significant change like this is going to have a hard time
>getting traction
>> >>in the market. If this sort of approach will appeal to people,
>> >then perhaps
>> >>we ought to concentrate in the near term on selling Frank's
>slightly less
>> >>efficient approach since it's fully compatible with the current syntax.
>> >
>> >The masks will be generated automatically by a compiler. The
>> >compiler will
>> >get market traction because it is easier and more fun than
>> >creating records
>> >with a text editor, and it will be a webtool or a free download, not
>> >requiring any DNS patches, etc.
>> >
>> >The "include:not.me" syntax, as I understand it, can never provide a
>> >one-shot DNS response, and once people start using it, we will never get
>> >rid of it.
>> >
>> >Spammers are not going to give up their lucrative business without a
>> >fight. I can easily imagine them turning up the volume by a
>factor of 10
>> >or even 100. I like the idea of having as the final defense, a
>> >"one-query"
>> >mode where 90% of the legitimate mail gets through, and the spammers are
>> >rejected at a cost not much more than they spend in sending their sh*t.
>
>>Maybe the compiler could have an option to spit out either m= or
>>"include:not.me".
>
>Feels like a kludge, especially if it encourages people to start writing
>masks manually.
>
>>"include:not.me" can be deployed today.
>
>The "not.me" syntax will need a few months to write, test, and deploy the
>compiler. The m= syntax might take a little longer for SPF checkers to be
>upgraded. The not.me syntax requires a minimum of two queries. The m=
>syntax can provide a one-query authentication check in the critical
>situation, a DoS attack. So we need to weigh the urgency of getting this
>widely deployed vs a better long-term solution.
>
>I'm leaning toward the better long-term solution. I don't see the urgency
>for deployment. It will be a long time before the whole world is using
>SPF. I do see some urgency in responding to the DNS worries, and getting
>this into the draft.
>
I see it as a chicken and the egg problem. Which comes first? Until m= is
deployed among SPF checkers, it has no benifit and will make records longer
(more bandwidth, potentially more queries). So there is no incentive for
domain owners to put m= in their records (and some dis-incentive). I
haven't heard SPF checking program writers, other than Radu, leap up to say
they would implement this. Until m= starts appearing in records, there
really isn't a benifit to adding it.

If SPF wasn't already significantly deployed, I might be inclined to agree
with you, but I just don't see m= getting traction. If we had a script to
produce the "include:not.me" record in conjunction with the SPF record
compiler, we could use it to evangelize the few domains that have records so
complex that they would actually require this. If, in the mean time, m=
makes progress, they can switch.

SPF is in many respects a kludge (see Frank's DNS layering discussion for
example), but it's one that works reasonably well and is deployable today.
Periodically, people show up on this list and say, "No, don't use SPF, SPF
is bad. Use .... instead", but when I go figure out how to set up ...., I
find it isn't quite ready for a "Vanity" domain owner like me.

"include:not.me" may be a kludge too, but the fact that it can be used now
with no programs that need to be upgraded on anybody's mail servers is a
huge advantage. If you want to wait for the real deal, you wait may be very
long.

Scott Kitterman

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

First page Previous page 1 2 Next page Last page  View All SPF discuss RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.