On Mon, 1 Aug 2005, Jim Fenton wrote:
- As a business model, ISPs might consider message signing to be a premium
service, for which they either charge extra or vet their customers more
thoroughly. "Free" accounts might not get their mail signed or might get it
signed by some key with a potentially more dubious reputation.
You're conflicting signing and acreditation. When to get a signature
somebody has to be accredited and verified it is a different service.
And offering mta signing as premium service - I really hope it does not
come to that and this is available to everyone and not just to select few.
- Operationally, DKIM might be used with other mechanisms (SenderID/SPF or
CSV for example) and an affirmative result from both would probably be a
better indication that a replay attack is not taking place. Messages which
pass DKIM but fail the other mechanism might be subject to additional
scrutiny.
Don't confuse one mechanism with another. Different email security systems
operate on different identities and you can not assume that CSV (HELO
identity) and SPF (RFC2821 MAILFROM identity) would match the same time as
email signature on "from" header field would. And of your listed "other
mechanisms" (SenderID, SPF, CSV) not operate on same identity as DK and
so results of those checks should be completely independent. Additionally
path authentication systems and cryptographic systems fail under different
conditions and again making assumption that if one passed another one
should have as well is bad idea. I talk about all of that (identites and
how different authorizations systems operate on them) in my paper:
http://www.metasignatures.org/path_and_cryptographic_authentication.htm
Do we care? Is this acceptable to the operations communities?
I care. This is an example of where signature-based mechanisms aren't
perfect, but nothing is.
"Nothing is perfect" is an excuse to not look at the issue. That you
know there is a problem in proposal should mean you should try to
improve it or consider alternatives that have the issue addressed.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net