[ietf-dkim] Collection of use cases for SSP requirements
dotis at mail-abuse.org
Wed Nov 8 09:54:55 PST 2006
On Nov 8, 2006, at 7:55 AM, Steve Atkins wrote:
> On Nov 8, 2006, at 4:24 AM, Charles Lindsey wrote:
>> On Wed, 08 Nov 2006 04:46:08 -0000, wayne <wayne at schlitt.net> wrote:
>> I think some site like a Bank, that is heavily phished, might go
>> so far as to declare "I sign all mail. Please delete/reject/drop/
>> whatever (perhaps even silently) all messages that fail to verify".
>> That site would have to be pretty confident that the genuine mail
>> it sent out was 100% clean, but it might well decide that it was a
>> lesser risk to have some genuine messages dropped than to let
>> phishes go through.
>> BTW, are there any plams to have keywords for some of the various
>> policies that might be declared, so that verifiers (or rather
>> their policy modules) could recognize them and adjust their policy
> I do have to point out that SSP will not affect phish emails
> noticeably, after a very short transition period.
Validity and trustworthy assertions allow message annotation based
upon either out-of-band trusted email-addresses or trusted domains.
This annotation approach provides formidable protection against look-
> So if a bank were to do this it would mean 1) phishing mails won't
> be affected and 2) legitimate mail from the bank is likely to be
> So... what's the _real_ use case, again?
The DOSP proposal solves several use cases:
Validation of disparate rfc2821.MailFrom is accomplished within a
single small DNS transaction. This association is not prone to the
many problems associated with address path registration. Address
path registration breaks with forwarding. The size of a data-set
needed for address path registration also leads to serious DDoS
Protect DKIM white-listing:
Validation of disparate SMTP clients is accomplished within a single
small DNS transaction. The association can utilize either address-
literals or host names and assumes the EHLO has been validated prior
to accepting the message.
Simplify provider designation:
A designation scheme can be accomplished within a single
transaction. This eliminates the need to exchange private keys,
delegate DNS zones, or establish CNAMEs where the provider creates
your private keys and only shares the public version. These
arrangements will be difficult to scale increasing cost and will
likely lead to higher rates of invalid signatures due to
configuration errors. These arrangements will impede consumer's
choice of providers. A provider using their customers keys and
domains also means forgoing valuable abuse feedback.
Support annotation constructs that utilize the recipient's address-
book or a list of trusted domain.
The different DNS checks (and even DKIM validation) should only be
done when there is a direct benefit. It remains doubtful that there
is benefit hunting for policy that indicates a message should be
signed. The annotation strategy prevents such messages from spoofing
More information about the ietf-dkim