----- Original Message ----- From: "Stephen Farrell" <[EMAIL PROTECTED]> To: "Michael Thomas" <[EMAIL PROTECTED]>
> 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
