RE: change of version string

> -----Original Message-----
> From: Douglas Otis
> Sent: Friday, August 20, 2004 2:38 PM
> To: Scott Kitterman
> Cc: MARID
> Subject: RE: change of version string
> On Thu, 2004-08-19 at 14:57, Scott Kitterman wrote:
> > Douglas Otis wrote:
> > > On Thu, 2004-08-19 at 13:17, Scott Kitterman wrote:
> > >
> > > > Anyone who doesn't want their v=spf1 record used for Sender-ID
> > > > checks can publish an SPF2 record that says spf2.0/pra +all.
> > > Why not wait for them to opt-in to Sender-ID?  You want mail
> > > rejected as a result of this usurping of the record?  There may be
> > > many that feel Sender-ID records of any kind are not safe, as they
> > > rely upon the RFC2822 content, but there is no means for this
> > > content to be assured. Blacklisting could make _any_ records for
> > > Sender-ID perilous. They may have felt SPF was relatively safe, but
> > > feel Sender-ID is not.  You offer no recourse as a result of this
> > > expediency taken.  They may have been expecting to use differing
> > > access with this RFC2822 From address you destroy without risking
> > > the publishing of Sender-ID records.
> > >
> > > > That's an effective opt-out of Sender-ID.
> > > That is asking for their DNS to be bombarded with Sender-ID spam
> > > exploits.  That is also asking for their domain to be blacklisted.
> > > Some opt-out. :(
> > Actually, now that I think about it, spf2.0/pra ?all would be a much
> > safer opt out.  Shouldn't get blacklisted over that one any more than
> > you would by publishing nothing.
> If there is a filtering advantage for referencing a Sender-ID record,
> even an '?' "open" record, then this type of record becomes a means for
> spam exploits.  This also puts the DNS server at risk of being
> overloaded.  Regardless of the scenario, publishing an "open" record of
> _any_ type is not without risk.  It could also lead to this Sender-ID
> domain becoming blacklisted, if this record is abused.  An "open" record
> can easily be abused.  Such "open" lists should be struck as offering an
> irresponsible option, once repudiation is considered being done either
> through rejection or filtering.  Filtering is much more insidious. :(
> > > > They key point is to make it easier for domain owners to
> > > > publish.  Getting a critical mass of domain owners with records is
> > > > essential to escape the catch 22 of receivers not checking because
> > > > no one publishes records and no one publishing records because no
> > > > one checks.  Since there is a significant base of v=spf1 records
> > > > published, we can gain a lot of momentum by leveraging off of the
> > > > SPF classic community.  Finally, they are generally technically
> > > > aware early adopters who can reasonably be expected to understand
> > > > the impacts of 2821 versus 2822 checking and its effect on them.
> > > This still does not provide a suitable option for saying "Leave me out
> > > of Sender-ID!"
> > Of course, being left out of both SPF and Sender-ID is trivial.
> > Continue to not publish a record.  Yes, it does make it harder to get
> > out of Sender-ID, but not out of SPF.  I think that spf2.0/pra ?all
> > would be close enough.
> This is not the same as no record.  This is saying, "Anyone and
> everyone, use this record if you wish to claim my domain in your mailbox
> address as having Sender-ID '?' status."  This could be worse than no
> record, as it implies acceptance of this "open" Sender-ID record status.
Upon reflection, I think that Wayne's proposal is better.  It meets my goal
of only having to publish one record without the downsides that you point
out here.  Being able to only publish one record (what I proposed) would be
great.  Being able to publish one record the describes what scope it is
intended for is better.  It will take a little longer since the currently
deployed SPF parsers will have to be upgraded to read the new record type,
but I suspect the advantages are worth it.

Scott Kitterman