Rand,
Hmm, in addition to working with a number of globally large
enterprise customers, Sendmail also represents a huge
number of those individual domain holders (I for one manage
a "vast number" of individual domains in my spare time ;) I
haven't seen much that presents a problem deploying to
sub-domains. In fact, our operational experience with
DomainKeys so far has shown using a whole separate
sub-domain namespace gives you a tremendous amount of
flexibility in both record depth and server deployment.
I should have been clearer. Web hosting services offer sub
domains. However, there is a threshold cost involved, which
can sometimes be an incremental amount on a monthly basis.
The catch? Pay the cost only to find the particular sender
authentication scheme does not work when implemented on a
large scale.
This is not meant as a specific criticism of Sender-ID, but
rather an expression of general concern.
The real world concerns you are raising are extremely
valid.
Perhaps it is my innate sense of irony. Here we are, 4 days
into last call, when someone like yourself comes in from
the field and says hey guys "she just don't fit." :-)
It just makes me a bit jittery. At the same time, given the
time constraints everyone is working under, perhaps it is a
function of the beast.
... the universal core concern for the large enterprises
I've talked to (the ones whose customers are targets of
phishing campaigns) are as follows:
- Firstly, to provide end-users the information to protect
themselves by authenticating something the end user will see
These statements raise fundamental questions. It strikes me
there are two underlying issues:
* Implementation of one or more methodologies which can aid
in thwarting volume senders of unwanted email from hiding
identity.
Here it would seem we require a solution which protects one
or more delivery channels through authentication,
(thwarting the hiding of identity) plus reputation
(allowing the sorting of good from bad mail) and
accreditation for those who would otherwise be grey listed.
* Whether the correct response to phishing, which is
spoofed domains, forged header and message content, along
with the use of fake web sites is authenticating the domain
in the message from line and requiring the upgrading of
email client software across the board, so end user's can
see the result.
To respond to this specific form of crime, would it be more
efficient and focused to allow the end user to authenticate
the sender's message content through some form of light
weight cryptographic scheme?
- Secondly, to ensure reliable delivery of their customer
relationship email
This is a concern across the board, with the present state
of email delivery, due in large part to coping with ever
spiralling levels of unsolicited bulk mail.
In making these comments, I am not attacking the Sender-ID
design. It is as you point out a response in part to very
specific complaints.
I am simply suggesting the concern you raise of
over-running of TXT data space in FQDN is valid. On
balance, the use of sub-domains may well be a practical
solution to the specific issue as raised. But, given some
of the side effects to the vast numbers of others involved
with email perhaps the issue highlights a more fundamental
concern.
Whether the financial institutions' design criteria, which
I gather from your comments has stamped the creation of
certain key aspects of Sender-ID is the right approach to
dealing with the phishing problem?
Answering this question may lead to a better answer to the
key practical concerns you raise.
John
John Glube
Toronto, Canada
The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004