On Jan 25, 2006, at 2:13 PM, Stephen Farrell wrote:
http://www.ietf.org/internet-drafts/draft-otis-dkim-options-00.txt
Should be:
: Although the submission of messages may be prior to the application
: of a message signature, submissions are commonly authenticated
: internally within the AdmD by mail submission agents. By including
: a persistent identifier within the signature, a substantial source
: for email abuse can be abated with the use of DKIM. The identifier
: itself can be block-listed by the sending domain immediately
: without requiring the expiry of a key TTL. Defense against bad
: actors is also improved with the proper use of firewalls and OS
: maintenance.
That text is a somewhat overblown IMO and has some errors.
- "within the signature" - unless you're planning to advocate we
use a signature scheme with message recovery I expect you mean
"with the signature".
- As I pointed out previously, your O-ID is basically a message-set
revocation scheme (which may be a valid approach, but its nothing
really new sharing most characteristics with CRLs)
- I've no idea how you'd justify "substantial"
This is a real concern largely due to compromised systems.
Unfortunately, an area difficult to control with a block-list would
be a large domain, as this may impact millions of users. Adjusting
for the overall traffic is fair. The problem this creates is that
once all other sources are blocked, these sources then become a
growing and significant share of what is left.
- "immediately" is pure sales-talk, every revocation scheme involves
inherent delays
While indeed any revocation scheme would incur delay, when compared
to key revocation, there is no additional self imposed delay waiting
for a TTL to timeout in the recipient's cache.
- presumably you meant to say "black listed"
No block-listed is a safer term from a liability perspective, and
terminology accepted by the ASRG.
I expect if you were willing to rephrase along those lines you
might end up with something more people would buy into, or maybe
not, but I'm pretty sure the more sales-talk, the less likely
something is to get agreed.
<rant>
If there was a real desire to clean up the mess, it would have
happened years ago. Much of this revolves around whether the scheme
at hand holds the administrator accountable. CSV and a PTR RR is
able to verify succinctly both the EHLO and the MAILFROM in as little
as 1 or maybe 2 lookups at the most, even with millions of machines
within a common domain. This would eliminate complex scripts,
includes, redirects, macro-expansion, CDIR notation, three flavors of
acceptance, and a possible need to perform 112 lookups that may still
fall short or prematurely timeout. The problem with the CSV approach
is that it clearly holds the administrator accountable by identifying
the culpable machine, rather than the hapless email-address domain
owner. : (
The administrator can take both swift and effective action when abuse
is reported, but this may cause costly support. There are always
administrators looking for schemes, no matter how complex, to hold
the email-address domain owner accountable instead. The email-
address domain owner will likely remain clueless and frustrated when
told the reason for their messages being deleted was due to _their_
neglect in using the wrong provider. The open-ended policies of SSP
represent new avenues where problems may be placed unfairly onto the
email-address domain owner at the hands of the administrators. There
are many subtle ways for this to happen, and the report vector
missing from the signing domain suggests this concern is not all that
unfounded. The email-address domain owner will likely not have the
necessary resources at their disposal to correct problems, or even
understand the source of the problem. Publishing any policy is risky
business, and open-ended policies will likely represent the means for
the wrong party to be unfairly held accountable.
</rant>
Lastly, just to note in passing that even if the threats draft were
to say "using such-and-such might be a potentially useful counter
measure" that does not mean that the WG will arrive at consensus to
actually include mechanism that in the protocol - that latter being
a discussion for another day.
Understood.
Amended Should be:
: Although the submission of messages may be prior to the application
: of a message signature, submissions are commonly authenticated
: internally within the AdmD by mail submission agents. By including
: a persistent identifier within the signature header field, a
: substantial source for email abuse, that still remains after the
: application of block-lists, can be abated with the use of
: DKIM. The identifier itself can be block-listed quickly by the
: sending domain without requiring the expiry of a key TTL. Defense
: against bad actors is also improved with the proper use of firewalls
: and OS maintenance.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org