It sounds like you have it all worked out. Can we call it DOUP? Doug Otis
Utopian Protocol? <g>
2822 DKIM + Opaque-Ident - SSP
2822 Modified MUAS
and with all the above, the email problem is solved and DOUP will work with
tranparency for the entire mail infrastructure.
Could DOUG replace current systems? Like RBL, SPF or CBV?
What happens if one part of DOUG is broken? Can CSV trump all others? Can
DNA trump all others?
You mentioned CSV can return DKIM information. Cool. That means if the
PAYLOAD is not signed, then I can reject it. Then I would black list the
CSV machine for blasting it over and over.
But of course, I like efficiency, so I will delay the high overhead
open-ended HELO/EHLO CSV lookup until the RCPT TO forwarding address is
If RCPT TO is valid, then I will check the MAIL FROM with my CBV or BATV? to
make sure the BOUNCE address is valid.
If MAIL FROM is valid, I will then do the CSV client domain lookup.... no,
wait, I need to wait to see if a ESMTP AUTH session is started because our
policy is that ESMTP AUTH trumps everything. You never did work out the
double EHLO required for TLS with CSV did you? Should I use the first
client domain name or the second one, in case it was changed?
Anyway, CSV tell me DKIM is being used, so not I check DNA for any bad
reputation. Whick DNA should I used? Will MAPS be ready? Do I need a LIST
of DNS domains to lookup? Or this DOMAIN come from the CSV record? What if
the DNA service is down?
Anyway, I expect DOUP to be a good system, and I trust the DNA provider,
after all, I cam going to make good service I'll prefer to pay a premium for
such service. So the DNA provides a BAD reputation. Cool, I can reject the
mail for the user. If it provides a GOOD reputation, I will now accept the
payload after the series of checks is done:
RCPT TO - Local DB lookup
MAIL FROM - CBV
EHLO/HELO - CSV
AFTER CSV - DNA
DKIM was expected and DKIM domains do not match. Can I reject the message?
I'm scrathing my head. If CSV provided a valid IP::DOMAIN association
meaning the CHAIN of TRUST was intact, DNA said the domain is ok. Why
boither with the PAYLOAD analysis? How can you get a bad payload if
everything is ok?
I'm trying to find a scenario where this is possible? A compromised
CSV-ready SENDER machine? By why would the payload be bad then if the CSV
and DKIM signing machine is within the same network?
Hector Santos, Santronics Software, Inc.
----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: "Scott Kitterman" <ietf-dkim(_at_)kitterman(_dot_)com>;
Sent: Wednesday, November 02, 2005 9:01 PM
Subject: Re: [ietf-dkim] SSP acceptance chart
On Nov 2, 2005, at 4:14 PM, Hector Santos wrote:
This is indeed a common refrain. Until MUAs are modified, DKIM
offers no such protection however.
You are limiting your scope to offline world. What about the online
The majority of users see only the pretty-name and are enticed by the
HTML content of the message itself. Depending upon a From matching
some signing-domain will not offer much protection, as abusers will
provide an endless stream of messages meeting these requirements. As
counter-intuitive as this may seem, assurances offered by SSP of a
domain matching are risky, and authorizations only expose the email-
domain owner to added risks when unfairly held accountable. SSP
actually hurts more than it helps. SSP also takes away an ability to
send messages to list-servers or to use email-addresses at different
providers by making it impractical to allow independent signing-domains.
When MUAs are modified, the signing-domain should be made
visible in some manner.
In the perfect world of "chain of trust", the users just wants to see:
If you want to authenticate the author independently from that of the
transport, then the OpenPGP model would be a far better choice. This
would return control to the domain owner where there would not be
risks associated with authorization schemes and possible provider
If the domain offering the transport is to be held accountable by
DKIM, then there is a "connecting piece" missing when the signing-
domain and the email-address are not the same. Even Mark suggested
there is a desire to allow the signing-domains and email-address
domains to differ at times. Making allowances for these two domains
to be different is needed when not disrupting existing email services
and practices. Perhaps people wish to use their alma mater domain
from their local provider. Perhaps people want to be able to
understand who is speaking on a list-server. The connecting piece
could be an opaque-identifier that extends the chain of trust
uniquely from the author, over the transport, to the recipient. Of
course, the opaque-identifier would not be needed in those cases
where the domains are not different, and the email-address is limited
to the author.
This could by done when an initial message is received, where
the user is asked to approve these identifiers.
Why can't his ISP do it for him?
In some cases, this would be possible. If the signature indicated
that the email-address domain must always match the signing-domain,
and that the email-address (for a class of keys) always applies
uniquely to the author, then this could be could be done
automatically by the MDA or MUA by initially capturing this assertion
from an initial message. When the email-address and the signing-
domain differ, it would be better to let the recipient decide on a
case-by-case basis. This would not require endless requests of the
provider to create hopelessly complex "third-party" authorizations
where there would be endless lookups groping for all the possible
relationships. Double yuck.
Anytime an identifier appears to have changed, or another
message looks like a message with retained identifiers,
they should be alerted.
Why bother and confuse the user at all?
People change providers, but wish to retain use of an email-address.
This is a normal process. People could be alerted to these changes
ahead of time, so that when the change appears, it is readily
accepted. I use SSH, where it is common for me to accept the
certificate details of the server. Sometimes these certificates
change and I am alerted to this change, and once again asked to
review the details. Other than that, there would not be much
bother. Establishing a database of prior correspondent identifiers,
that may include pretty-names for example, would allow a program a
simple basis of when to alert the user to a clever spoof attempt.
In that case, there would no need for an SSP scheme.
I love your ethusiam. But its not doing it for me. Sorry.
You represent the typical provider.
This could be enhanced by offering recommendations
contained directly within the signature on the scope
of identifier needed to isolate the author.
Is this at the 821 level?
This would be at the 2822 level and affected by the class of key. If
there were binding assertions made or captured that were in conflict,
the identifiers would likely be a combination of <email-
domain>:<signing-domain>, or <email-address>:<signing-domain>, or
<email-address>:<O-ID>:<signing-domain>. This enhanced MUA should be
able to highlight possible conflicts, were the related bindings could
be exposed by a click.
ietf-dkim mailing list