dkim-dev
[Top] [All Lists]

Re: [dkim-dev] dkim and email list software - potential solution

2009-09-30 16:34:01
On 9/30/09 12:46 AM, Daniel Black wrote:
Douglas,

Thanks for replying,

On Wednesday 30 September 2009 11:00:26 Douglas Otis wrote:
There are no good solutions.

which do you think is the better^Wleast bad one?

Email-addresses being used by the average users will not benefit from
an ADSP record at this time.  By just using DKIM, at least these
messages should receive better handling.  An ADSP that asserts "all"
represents the only assertion that some providers might want to try.
Unfortunately, even this setting is likely to be a cause for some
messages becoming lost.

This feature was intended to cause messages with their signatures
damaged or missing to not end up in someone's mailbox.

odd - this is not mentioned in rfc5016

You need to talk to John Levine about the motivations for the
"discardable" assertion.  This assertion was not part of the initial
plan.  Providers may have wanted to avoid compliance issues with
RFC5321 in some cases, since DKIM evaluation often occurs after message
acceptance.  Many organizations now avoid email, and use web-based
messaging instead, so perhaps "discardable" was intended to represent
"no mail" which was not within the bailiwick of DKIM.

Any domain making an ADSP discard assertion should expect the
domain will become [unusable] on mailing lists.  Such domains
should be limited to handling transactional emails. Unfortunately,
this view might lead to more phishing exploits whenever alternative
domains are then used by the same organization.

or just as likely, prevent dkim=discardable on high value domains
like irs.gov to prevent where staff use email as well as wanting to
prevent phishing associated with it.

In other words, DKIM=discardable means we don't use email, at least not
any email that matters.  DKIM=all should be enough to signal a potential
problem.

Perhaps there should be a standardization for transactional
sub-domains and stringent requirements where ADSP transactions
then become superfluous. Where subdomains like secure, or
signed.somedomain.com versus somedomain.com might be used as a way
to establish a visual convention.

I'm not sure what subdomain protection has to do with intermediaries
breaking ADSP validation.

This was questioning the rationale for making additional DNS
transactions for _EVERY_EMAIL_DOMAIN_ received when so few publish an
assertion offering something actionable.

One alternative might be to establish conventions for sub-domain labels
that indicate corresponding emails are transactional and are expected to
include DKIM signatures or better.

-Doug






_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev