[ietf-dkim] Re: Domain Ownership
2005-11-23 11:58:47
On Nov 23, 2005, at 1:03 AM, Hector Santos wrote:
This is long, but I will try to be brief.
The only reason the so call "freedom" exist is simply because there
was no controls in place before, hence the major exploitation and
abuse of the domains.
You are describing current practices, permitting the operation of
list-servers for example, as abusive.
You are trying to remove all rights to control the domain owner's
property and you really haven't consider the idea the email service
may not want to get involved in allowing blatant fraudulent usage
of restricted domains.
As the true source of an email-address can not be verified, the email-
service (signing-domain, client IP-address, or host-name) must be
held accountable for abuse. The email-service provider should find
methods to restrict abuse before being accepted under their auspices.
Just because these email-service identifiers are not apparent to the
recipient, this does not justify shifting the burden of
accountability onto the email-address domain owner. If the desire is
to hold the email-address domain owner accountable, then a different
model like S/MIME or OpenPGP would be appropriate.
You are making an incorrect assumption that services will want this
FREEDOM without any sort of verification.
When acceptance is based upon the DKIM signature, the signature
itself acts as a means for verification of the entity that _must_ be
held accountable.
Even then, DKIM/SSP allows for 3rd party signing, if this what the
email service wants to offer.
This is a dubious claim that third-party signing will be allowed,
when authorization misuse shifts accountability to the email-address
domain owner and is already prevalent.
I took a quick survey of my customers a few weeks ago and BY FAR,
all of them wanted control of the usage of their domains by their
users. They want the flexibility on a security group profile
(domain) basis. Some want to allow the freedom for some domains,
for other domains they do not.
A method to indicate a desired constraint may be appropriate, at this
time, for transactional email. There are alternative ways to signal
this desire while also avoiding unfair treatment and the overhead
incumbent with an authorization record. The alternative is needed to
ensure a mode of use remains available that supports current
practices. As it happens, the alternative also offers improved
spoofing protections.
Not every ISP service is a PUBLIC service bureau Doug. A good
example, off hand, is ISP for car dealerships, each with a domain
reflecting the car dealership. They don't want spam just like the
next guy and they don't want these "high-value" domains exploited
externally.
The integrity of delivery is important across the entirety of email-
address domain owners. Cached assertions contained within signatures
may not offer prohibitions without a prior correspondence, but then
the DKIM signature will still act as a touchstone, and improve the
accuracy of filters. Without a prior exchange with an entity, being
asked to update your account will stand-out like a sort thumb.
Binding advice offers better protections from look-alike domains,
which is already the next move in this game.
Your solution KEEPS the doors open to status quo exploits across
the board. Your solution would prevent the controls of restrictive
domains across the board. The core signature is NOT enough, with or
without OPID. A SSP is essential to obtain optimal benefits.
The alternative to SSP would be more effective at abating more types
of exploits. The obvious domain poaching spoof would be abated, and
the look-alike spoof would also be made much more obvious to the
recipient. In addition, current practices would not be affected.
Just consider even if you had a OPID concept. You would still need
a deterministic control to validate its usage.
I assume you mean the opaque-identifier _option_. Indeed, the
signing-domain should signal when this option may improve upon the
isolation of the message's author from within the signing-domain.
This information could be derived from a Radius server, for example.
Keep in mind, the signing-domain establishes the trust. Should the
signing-domain becomes known for messing up O-IDs, then not mandating
an association between the signing-domain and the email-address
domains offers greater independence for the email-address domain
owner. They could send a message that they are about to change
providers, and then simply change providers.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-dkim] SSP security relies upon the visual domain appearance, (continued)
- Re: [ietf-dkim] SSP security relies upon the visual domain appearance, Dave Crocker
- Re: [ietf-dkim] SSP security relies upon the visual domain appearance, Douglas Otis
- Re: [ietf-dkim] SSP security relies upon the visual domain appearance, Dave Crocker
- Re: [ietf-dkim] SSP security relies upon the visual domain appearance, Hector Santos
- Re: [ietf-dkim] SSP security relies upon the visual domain appearance, Douglas Otis
- Re: [ietf-dkim] SSP security relies upon the visual domain appearance, Hector Santos
- Re: [ietf-dkim] SSP security relies upon the visual domain appearance, Douglas Otis
- Re: [ietf-dkim] SSP security relies upon the visual domain appearance, Arvel Hathcock
- Re: [ietf-dkim] SSP security relies upon the visual domain appearance, Douglas Otis
- [ietf-dkim] Domain Ownership, Hector Santos
- [ietf-dkim] Re: Domain Ownership,
Douglas Otis <=
- Re: [ietf-dkim] Re: Domain Ownership, Arvel Hathcock
- Re: [ietf-dkim] Re: Domain Ownership, Douglas Otis
- [ietf-dkim] Re: Domain Ownership, Frank Ellermann
- Re: [ietf-dkim] Re: Domain Ownership, Douglas Otis
- Re: [ietf-dkim] SSP security relies upon the visual domain appearance, Scott Kitterman
Re: [ietf-dkim] SSP security relies upon the visual domain appearance, Hector Santos
|
|
|