On Fri, 2004-07-02 at 11:22, Hector Santos wrote:
For what its worth, as CSV stands today, it is difficult to endorse it or
warrant any further for product consideration or implementation for the
following five (5) simple reasons:
- Potentially high (unnecessary) SMTP redesign issues,
CSV is proximal to the current use of RBL. I do not envision serious
design issues. The concerns raised are being addressed by Dave Crocker
and John Leslie. You are right in that StartTLS, as used today, is not
relevant, but to simply cover the topic of public or open authentication
and authorization techniques, these methods were mentioned. You are
right, more information is needed, and it will be forth coming.
- Has higher than required SMTP compatibility conflicts,
CSV virtually leaves SMTP unchanged. CSV requires only careful
placement in the SMTP session process of where the CSV checks are
applied. CSV makes the least change to SMTP compared to other
proposals. It does require the host name be valid, but I would not
describe that as a major change. The intent of CSV is to remove reasons
permitting this lapse in host name validation. SMTP requires the check,
it just currently forgives an unsuccessful result.
- Potential customer acceptance (PR) issue regarding fee-based service
bureaus,
Accreditation bureaus exist today and are responsible for preventing
many more times that not seen than the amount that is seen. The cost of
these services is highly dependent upon efforts needed to vet these
accreditations. In addition, use of names is a positive alternative
that will help those currently hampered using dynamically assigned
addresses. That which remains is difficult to deal with on a per
mailbox basis, but having an authorized and authenticated domain that
provided access for such user may become a powerful tool for enforcement
of criminal activity. Controlling access is the only means the mail
system will improve. SPF does not impact that aspect of the problem at
all. In fact, SPF can not assess the source of abuse, or accredit any
provider for failing to ensure security. Only through accurate
accreditation is this possible.
If you do not use any accreditation service, you still benefit. Through
third party assessment, providers learn of abuse and where security has
been violated. Again, SPF offers little or no help in this area. Do
not expect spammers to take very long to adapt to any SPF deterrent and
likely find the means to totally defeat any SPF limitation that you wish
to see imposed.
- Overall, the change vs. benefits offer no advantage over what SPF can not
offer. and
SPF will always allow spammers to leverage any domain that publishes an
"open" list, including their own domain. Those that publish such a list
may find their addresses spoofed heavily and their DNS servers
overwhelmed. Their reaction to this problem would be to either "close"
the list or remove the SPF record entirely. Those that "close" their
list may find their mail lost in transit, if it takes a path not
published, perhaps through no fault of theirs. As SPF never holds a
service provider accountable for their exercise of policy regarding
security, SPF can not ensure even those that publish a "closed" list
will stop seeing their mailbox spoofed. As SPF is very susceptible to
DDoS, it may well be disabled, leaving victims a false impression based
upon these defeated SPF assurances. Unlike CSV, SPF _DOES_ require
extensive SMTP design changes.
- You, nor Dave have never answered my comments/questions.
Remember, Dave is on vacation and much of your concerns addressed his
document which he promised to update. Perhaps you could factor that in
to your concerns. You have been prolific addressing your concerns and
my understanding is that Dave has difficulty finding reasonable
bandwidth to permit direct access to these lists. Give him a chance to
respond via the update at least.
I don't care about SRV vs. TXT, that's a DNS admin thing. But either way, I
will be looking to optimize or minimize the total number of lookups.
The TXT record examples often assumed additional lookups would be
required by simply placing a free standing a in the TXT record. On the
face of it, this may appear to be similar to the function of the SRV
record, it is not however.
-Doug