On Thu, 26 Aug 2004, John Glube wrote:
My view from a security perspective is that the best
approach is to not rely on either one approach or one data
set, but to do both message and channel authentication
using a variety of data sets.
I totally agree. It has been Sendmail's stated belief for quite some time
that multiple technologies will arise to address these issues and it is
our intention to support those that work best to meet the needs of the
Internet community at large.
* Whether within Sender-ID it made more sense to go with
the same version of records as SPF.
You have raised a catch 22 problem for larger organizations
with complex records. Going the sub-domain route raises
catch 22 problems for the vast number of individual domain
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
* How would the FTC view what is decided given the FTC
mandate to protect the US consumer's interest, ensure
competition and protect against unfair trade?
Not speaking for the FTC, but the universal core concern for the large
enterprises I've talked to (the ones whose customers are targets of
phishing campains) are as follows:
- Firstly, to provide end-users the information to protect themselves by
authenticating something the end user will see
- Secondly, to ensure reliable delivery of their customer relationship
Because of these dual requirements -- and because of the already
well-publicized recommendations by many large receivers that volume
senders publish one/the other/both -- senders are going to deploy records
for Sender ID /and/ for SPF, and almost all of them are looking at what
its going to take to put a cryptographic signer in place in the future as
My whole point of this thread is to point out the real-world deployment
issues that utlizing the top-level FQDN TXT space is going to pose. I
fully support making some type of indication of what records apply to what
message addresses, I'm looking for different alternatives.