[ietf-dkim] "I sign everything" yes/no
dotis at mail-abuse.org
Tue Nov 21 15:45:45 PST 2006
On Nov 21, 2006, at 3:02 PM, J.D. Falk wrote:
> Imagine, if you will, that I'm a big ISP with lots and lots and
> lots of consumer type end users who prefer to stay clueless about
> the intricacies of e-mail.
> A message comes in which claims to be from the First Amalgamated
> Bank of Example. An entirely separate, unrelated mechanism has
> already told me that example.com really is the domain name used by
> the First Amalgamated Bank of Example, and that they're a real bank
> with tellers and vaults and bulletproof glass and all that fun stuff.
> But this message isn't signed (and/or the signature is invalid,
> which base says is the same thing.) How do I find out whether or
> not the First Amalgamated Bank of Example thinks that they sign all
> of their messages? That should be a simple, binary operation,
> right? I really don't care about anything else the sender may want
> to assert.
Why should an email provider care whether a banks sign all of their
Why should an email-provider care whether first-amalgamated-bank-of-
example.com or 1st-amalgamated.com is their real domain?
To thwart phishing with millions of possible look-alike and cousin
domain attacks, the clueless recipient must have a mail-user-agent
that can determine whether a signed domain is found in their address-
book. When the domain is not in their address-book, the signature
should not be checked as this leaks valuable information to bad
actors. Just annotate those messages that are signed and found in
their address book. Do that and you can stop worrying.
Walking up label trees in response to each and every possible spoof
received is not a good or safe choice. Marking messages as being
compliant with some self-asserted requirement is not a good or safe
choice either. In other words, the last thing an email provider
should be doing is looking for authorization schemes.
Depending upon an authorization scheme to block phish attempts risk
of making those messages still accepted look even more official.
This would represent an extremely poor trade-off. Don't go looking
for no stinkin' authorization!
> Should that be in SSP?
> Should it be in something else?
> Should I encourage all of the banks to use a non-standardized
> external mechanism while y'all argue?
No. Develop tools that confirm a signing domain is associated with
an email-address found within the recipient's address-book. This
effort does not require anything more from financial institutions
beyond simply signing their messages. This approach also allows
them to continue to contribute to mailing lists as well. An
authorization scheme represents an extremely poor choice that is only
likely to create excessive traffic and further mislead the clueless.
To better serve those wishing to utilize the Yahoo signature, develop
a simple association technique that allows autonomous management of
other domain's relationships with Yahoo without exchanging private
keys, CNAMEs, or delegating DNS zones.
To better protect the Yahoo signatures being used for white-listing,
develop a similar technique that associates with SMTP clients. When
an association is not found, the signature should not be used for
white-listing. This would absolutely prevent the likely replay abuse
of the Yahoo signature.
To better protect the DSNs, develop a similar technique that
associates with the MAILFROM with the signing domain.
More information about the ietf-dkim