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. :(
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.
The burden can not be avoided, when a Sender-ID record must be published
as a means to exclude the SPF record being assumed valid for Sender-ID.
If a message is relayed to the recipient, then it could become promoted,
likely by means of a Resent-From header, that will soon become
ubiquitous at relays, as a result of Sender-ID. Some may then adopt a
evaluation strategy that attempts to deduce the original PRA identity
for assessing repudiations, as this method falls completely apart.
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.
This two record types for a set of information is bad. Already there is
a high level of DNS traffic for this scheme, and now this requires two
record paths be checked. Will the record sets always match? Could be a
means to confuse checking schemes that do not check both 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.
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.
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.
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.
There should not be any need to "jump start" a scheme that proves
effective deterring abuse. As Sender-ID does not provide an effective
or safe means for abating abuse, this is more likely the reason for
adding a grandfather clause that seeks to ignore intent of the record.
This linked DNS record scheme seems well aimed destroying both DNS and
mail. A dedicated server could offer much shorter responses than crazy
lists of DNS records. Part of a philosophy, "Break it, and you bought
it?" What is the next proprietary scheme for mail and DNS?
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.
This is still overloading records. Sender-ID will assume ownership of
TXT, regardless of wording in the standard. This is a problem already
burdened with potentially hundreds of DNS record lookups. :(
-Doug