[ietf-dkim] DKIM on envelope level
doug.mtview at gmail.com
Sat Oct 31 13:36:26 PDT 2009
On 10/31/09 5:41 AM, hector wrote:
> Doug Otis wrote:
>> Any effort at imposing ridge rules will lower the reliability of email,
>> while also increasing support costs. As such, absolute policy
>> assertions are likely to prove useful in only a few cases. Nevertheless,
>> the TPA-Label scheme offers a significant level of flexibility that does
>> not require any coordination between the involved parties. After all,
>> such coordination will never scale.
> I generally work on the basis that steady state operations do scale and
> operate efficiently and smoothly under a common protocol expectation
> with parts that fit under a standard tolerance levels.
> However, when we have relax provisions, pars that don't fit, it promote
> complexity, ambiguity, overhead, additional patch work, relief values,
> more wrapper layers and overall higher cost to manage, this continues to
> place more pressure on the system with all kinds of potential leaks in
> the network.
When "steady state" includes dropping suspicious messages, or the
performing of challenge response checks, then there is an area that a
reduction in process and/or ambiguity would help.
> Whether its DKIM itself, ADSP, undefined reputation schemes, TPA, DSAP,
> this subject topic SMTP level DKIM header signature proposal, there is
> something fundamentally wrong with the work if we have a set of
> documents that specifically targets mitigating exploits, yet we have
> other docs that basically offers relax provisions that essentially
> conflict with these protections. I find it very hard to come up with a
> working solution or compromise. Clear and consistent functional
> specifications are required first.
Since no change ever occurs at once, there will remain areas where
handling is less certain. However, the sender is still able to offer
information that has been made more trustworthy as a result of DKIM.
This information might affirm relationships between the signing domains
and a different domains contained within Mail From or EHLO, for example.
Perhaps this information might lessen the likelihood of the sender
then receiving a challenge response check, or of having their message
dropped without issuance of a DSN.
> For this topic, to me, the fundamental question is whether a SMTP
> transaction can be rejected with a new SMTP level DKIM-related algorithm
> before DATA is reached or partially read.
You are on the right track. IMHO, name based acceptance will soon be
how SMTP EHLO acceptance is achieved, where relational information
offered from trusted DKIM domains can assist in amending this
information. There can never be any definite rules in how this is done,
since all rules will be gamed. When decisions change from "unknown" or
"bad-actor", to "unknown" or "good-actor", the process is less easily
gamed, and tighter thresholds in determining behavior permit maintenance
of "acceptance list" with minimal exposure.
There would be two aspects of this list. Domain to domain relationships
that might entail a few hundred million out of which good actor domains
need to be identified. And then good actor SMTP hostnames with their
related IP addresses which will entail a few million. Hints given by
SPF are often overly broad and are easily gamed. IMHO, this information
should be ignored. To prevent gaming, receivers should track "actual"
use. The amount of information involved with "good actors" is actually
fairly small, so this is not a difficult problem. Once a receiver has
been "seeded" with reasonably complete information, amending the
information on a trial basis with information of affirmed relationships
should prove practical.
> Any current plug and play 2822/5322 technology trials at SMTP requires
> the entire payload to be read first. So there is no payoff on minimizing
> data reception. The only payoff is SMTP level rejection.
There are other payoffs as well. Avoiding challenge response, or dropped
messages without DSN would represent other payoffs.
> However, under DKIM, with remailers being exempt to not pay too much
> attention to original domain intentions, this SMTP level rejection has
> its risk.
When there are hundreds of thousands of domains indicating that
"mailing-list-r-us" should be trusted, then how they go about handling
their lists with respect to DKIM is less of a concern. Of course, it
would help greatly for them to add their own DKIM signature.
> So IMV these SMTP/DKIM handling engineering issues need to be settled
> before any wrapper technology can even get a chance at Proof of Concept.
Dave insists that transfer by reference is off the table. IMHO, SMTP
and DKIM unchanged can be made to work as described.
More information about the ietf-dkim