ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: dkim.org (mipassoc.org/dkim) web page updated

2005-11-12 14:00:12
On Fri, 2005-11-11 at 04:12 -0500, Hector Santos wrote:
This might make it easier using this format to provide ACCEPT, REJECT, WARN
final results:

2821 =  PASS Yes/No
2822 =  PASS Yes/No

Assertions suggested in SSP such as '~' (signs some?), '-' (third-
party?) offers questionable benefit and delay.   Grading email with
respect to "partial" conformance offers a means for coercion (abusive
acceptance criteria) rather than abating abusive messages.  Either the
message is acceptable or not.  These open-ended policies are bogus.

With respect to the "spoofing" targets, examining content for links and
related text is more revealing than a From comparison when look-alike
domains and "pretty-names" are considered.

Setting up a zone such as:
 "*.<example.com>.ta-bcp.dkim.org." IN A 127.0.0.4
 "<except.example.com>.ta=bcp.dkim.org IN PTR example.com

Here an A record query resolves to domains that adhere to a set of
recommended guidelines for transactional email.  This could be setup
quickly and be independent of the DKIM base effort.  This type of
approach could offer a more powerful tool without impacting other
domains or slowing the base DKIM effort.

To check a domain in an email-address or link, a single query could be
made for the existence of a record.  When a small percentage of domains
are expected to need this policy, how this gets published and used
should be considered.

Another practical solution could be to "opportunistically" acquire this
information.  This could function as the ta-bcp.dkim.org list employing
the self-publishing of discovered bindings (domain == domain, 'w=b', ->
A, 'w=n' -> PTR)

As defined, SSP poses delay and SSP risks possible acceptance abuse by
inferring "partial" compliance criteria.  There are alternatives with
far less overhead allowing SSP to be safely removed from the charter
without loss of the desired protections.  Unencumbered independence of
the From address must be _completely_ acceptable, or current practices
are greatly disrupted which is sure to slow DKIM deployment. 

-Doug


  



_______________________________________________
ietf-dkim mailing list
http://dkim.org

<Prev in Thread] Current Thread [Next in Thread>