Doug Otis wrote:
Mailing list should HONOR it. If the abuse is so low, then it
wouldn't hurt if forwarders honored policy. But it would at least
close the loophole for the presumed "low volume" domain abuse.
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.
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.
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.
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.
However, under DKIM, with remailers being exempt to not pay too much
attention to original domain intentions, this SMTP level rejection has
its risk.
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.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html