----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Michael Thomas" <mike(_at_)mtcc(_dot_)com>
My impression is that there's no requirement for a comprehensive
analysis (of possible actions following receipt) at this stage, but
more for something with just a bit more coverage than an existence
proof (that there's at least one set of actions that make sense).
So the "reasonable set of possible actions" isn't meant to be
a very onerous target, or at least that's how I interpret it.
At a later stage someone could think of making up a BCP, but
like you said, that's a good bit down the road.
My concern is that we will end up with legacy DKIM issues in the same vain
as SMTP where process entities are not required to be verified.
In my technical assessment, we are not going to get another high interest
revamping opportunity again for another long time. The last revamp, switch
to the internet, it was pretty much a done deal - SMTP was already set in
stone with is relaxed provisions and known possible exploits, but exploits
DEEMED to be insignificant. The attitude was written in stone:
From RFC 2821, 7.1 Mail Security and Spoofing
This specification does not further address the authentication issues
associated with SMTP other than to advocate that useful functionality
not be disabled in the hope of providing some small margin of
protection against an ignorant user who is trying to fake mail.
We don't want to repeat this mistake with DKIM. It is best we "Get this
right, the first time."
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org