I think this was briefly discussed at the FTC email auth forum. Carl
Hutzler from AOL indicated that they would likely do HELO domain checks
using SPF records. Perhaps this is not the most ideal implementation,
sacrificing overhead, parsing complexity, and accreditation but since
SPF records seem to be getting published and checked perhaps it's worth
taking a less ideal implementation to get the major benefits that CSV
provides.
Are there reasonable algorithms to finding the layman's domain as
opposed to the machine name) For instance, Yahoo HELOs with the machine
name
HELO web14901.mail.yahoo.com
HELO web18103.mail.yahoo.co.uk
thus yahoo.com and yahoo.co.uk need to be examined.
From my POV, I'm just seeing the complementary aspects of all the
technologies. We need CSV, BATV and DK to protect each of the SMTP
commands:
- CSV protects HELO, indicating that the mail is from an administered MTA
- BATV protects MAIL FROM, identifying invalid bounces
- DK protects DATA, proving that the domain did or did not authored the
mail.
The only practical command left is QUIT -- perhaps someone can protect
that in an April 1 RFC.
miles
Matthew Elvey wrote:
I was thinking about my using SPF records idea, and noted a new hurdle.
I realized that even if we assume such records can sometimes be used as
a stand-in for missing CSA* records, we still will have no DNA* records.
Analagous records will exist if Accreditation and Reputation services
(A&R services? ARS? AR?) pop up that work with SPF records, but for good
reasons that Doug has outlined, such services are relatively infeasible,
compared to A&R services that work with CSV records, so it's no surprise
that none have popped up. There is a very large set of SPF records out
there, but AFAIK, the set of A&R services that work with SPF records is
empty.
(I'm making an implicit assumption here: A&R services can't reasonably
assign a good reputation to a bare domain; rather they can only do so to
a tuple of a domain and a scheme for Identification and Authentication.
They also can't reliably assign a bad reputation to a domain without
referencing a good scheme for Identification and Authentication. Folks
think this is a valid assumption?)
Things are awfully quiet. I guess a lot is going on in private DT
discussions and such...
*I created an acronym/Glossary at
http://wiki.fastmail.fm/wiki/index.php/ClientSmtpValidation#Acronyms .
Comments?
Please add the definition missing a term.
(Thread moved from MARID)
Matthew said:
Let's agree to disagree and move on. (Or at least let's move this
thread to
<http://mipassoc.org/ietf-clear/>) - Please reply there; I won't post
further here on this thread [assuming you do respect that request].)
_______________________________________________
ietf-clear mailing list
ietf-clear(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-clear