RE: change of version string

-----Original Message-----
From: Douglas Otis
Sent: Thursday, August 19, 2004 4:58 PM
To: Scott Kitterman
Cc: MARID
Subject: RE: change of version string
On Thu, 2004-08-19 at 13:17, Scott Kitterman wrote:

Douglas Otis wrote:

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.


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. :(


Acutally, 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.

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.


That comparison is overlooking how these records are used.  Publishing
these records was agreeing to how this record was to be applied, and not
to just their content.


I agree that v=spf1 publishers would have to look at Sender-ID and decide if
they wanted to avoid it.  I do think that it shouldn't be a major burden for
those savy enough to have already adopted SPF classic.

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.


This has happened because TXT records are being overloaded.  What
solution is there when the next version of records are to be published?

For the next version of the record, the actual RR type ought to be
available.  One major advantage of using one record for both is to minimize
the load on TXT records.

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.

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 arguments 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.


There are potentially serious downsides to Sender-ID and there should
not be any auto-magic opt-in.  Error on the side of caution.

-Doug

Why not wait is twofold.  First, two help jump-start adoption of the MARID
solution (assuming it's Sender-ID) and the second is to simplify record
publishing for those of us who will continue with Classic SPF.

Most of the commentary I've seen on the list seems to favor a single record
for both.  There are some that are concerned with that.  Here's a way for
both groups to have their way.

Scott Kitterman