RE: change of version string

> -----Original Message-----
> From: Douglas Otis
> Sent: Thursday, August 19, 2004 3:54 PM
> To: Scott Kitterman
> Cc: MARID
> Subject: RE: change of version string
>
> On Thu, 2004-08-19 at 09:32, Scott Kitterman wrote:
> > On Wed, 2004-08-11 at 5:59, william(at)elan.net wrote:
> >
> > > Perhaps it would be usefull if we allow one type of SPF record to
> > > reference (include, refer to) another type of SPF record, this would
> > > eliminate duplication problems in case of long records and avoid
> > > issues with large dns packet (because of multiple large txt records)
> > > as well.
> > Or perhaps we could say that mail receivers MAY use an v=spf1
> records if no
> > SPF2 record is returned.  As I understand it, any query for a TXT record
> > will return all TXT records for the domain, so if the TXT
> version of SPF2 is
> > queried for, the v=spf1 record will be returned if it exists.
> >
> > I understand that some are concerned with the difference between 2821
> > mail.from and 2822 PRA.  I've read all the drafts and as nearly as I can
> > tell, the mechanisms defined in my v=spf1 record will work
> perfectly well
> > for Sender-ID.
> >
> > For those, like me, for whom the records would be the same, allowing for
> > backward use of the earler SPF records would simplify things
> considerably.
> > It would also allow for Sender-ID checks to be usefully evaluated much
> > sooner since a large body of v=spf1 records is already published.
> >
> > For those who are concerned about the distinction, but want to
> use v=spf1,
> > if they publish an SPF2 record, then they can define that distinction.
> >
> > The change I am proposing would be to Page 5 of The Sender-ID
> Record: Format
> > and Interpretation, draft-ietf-marid-protocol-02.
> >
> > Change:
> >
> >    A Sender-ID compliant MTA MUST look up SPF2 RR type, it MAY lookup
> >    TXT record at the same time, or wait for negative answer.  SPF2 type
> >    SHOULD be used if available.
> >
> > To:
> >
> >    A Sender-ID compliant MTA MUST look up SPF2 RR type, it MAY lookup
> >    TXT record at the same time, or wait for negative answer.  SPF2 type
> >    SHOULD be used if available.  If a v=spf1 record is returned from
> >    the TXT record lookup, it MAY be used if and only if no SPF2 (SPF2
> >    RR or SPF2 TXT) record is returned.
> >
> > I believe that would make life simpler for many of us without undue
> > complication for others.
> There should be a concern doing this.  Those that published v=spf1
> records were intending this record to be applied to their RFC2821 MAIL
> FROM mailbox.  This would allow _any_ RFC2822 mailbox to be used.  Those
> publishing this record may have fully expected to retain this freedom,
> which now you feel obliged not to respect out of expediency.
>
> This lack of respect seems to extend to the use of SPF2, as the
> identifier for Sender-ID.  Why not fully depart, instead of this half
> measure which only seems to obfuscate the fact these algorithms and
> mechanisms are entirely different.  Sender-ID is not even better in many
> respects.
>
> -Doug
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.  That's an effective
opt-out of Sender-ID.  While I agree that the records for SPF Classic and
Sender-ID may be different in some cases, I expect that will be the
exception.  For the bulk of cases, I believe that the same record can be
accurately parsed for both.  I definitely believe that to be the case for
mine.

Having one record where one record will do while still allowing for two
records where necessary will make life easier for domain owners trying to
support one or both efforts.  One could also, in theory, say that in the
absence of an v=spf1 record, use the SPF2 record if present.  Since there is
a significant fielded code base of v=spf1 parsers in use, I think that it
would make more sense to have Sender-ID parsers use either record when they
are deployed.

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.

As far as what you call it, I don't care.  I just use what's in the drafts.
Myself, I wouldn't make any arguements in favor of Sender-ID over classic
SPF, but Sender-ID is what's on the table, so that's what I'm trying to
address.

Scott Kitterman