On Nov 2, 2005, at 8:40 PM, Hector Santos wrote:
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
known.
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?
This concern is based upon some confusion.
See section 5.1 Assessing Authorization in:
http://www.mipassoc.org/csv/draft-ietf-marid-csv-intro-02.txt
http://www.ietf.org/internet-drafts/draft-crocker-csv-csa-00.txt
The CSV-CSA record offers a means to establish name-based DoS
protections ahead the message exchange, and ahead of DKIM signature
verification. This record may also declare mandated SMTP protocol
extensions for the domain, like DKIM.
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?
Routing exploits are causing havoc on IP-address based mechanisms.
However, IP-address based mechanisms are needed to establish DoS
protections. Here CSV can provide a name-based bridge, where DoS
protections are not as easily polluted. This is a growing concern.
When the signing-domain is held accountable for abuse and is expected
to deal with compromised systems and message replay abuse, then the
burden is placed upon the provider granting initial access. Getting
at the source improves effectiveness of abatement. DKIM is useful at
arriving at the source of the problem, but only when the signing-
domain is held accountable and used as a basis for acceptance. This
detail is overlooked in your description of SSP results.
Once DKIM considers how to handle cases where the signing-domain and
email-address domains are frequently different, then opportunistic
techniques like those found in SSH look better than some complex
array of DNS records. In the odd case where a domain is being
phished, an assertion carried within the signed message can indicate
the required bindings based upon a class of keys. These captured
requirements would then block all cases where the requisite bindings
where not found. This approach can accommodate a diverse arrangement
of relationships between email-addresses and signing-domains, and yet
not require that a separate policy record be queried. SSP is not
needed!
The limitations of specifying the relationships between signing-
domains and email-address make SSP impractical. Once SSP is
attempted however, one can expect that compliance will be coerced
where everyone must give up on seeing the email-address be
independent of the signing-domain, and where many things break. I
would rather attempt to establish an opportunistic approach that
better accommodates current practices with fewer disruptions.
Opportunistically capturing broad-assertions at the MTA should
represent far less overhead than label-tree walking for every domain
without a policy. These captured assertions should also be more
secure and far more flexible. Opportunistic is better and safer than
SSP! : )
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org