ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting byfirstAuthorbreaks email semantics

2008-02-01 16:22:28

On Feb 1, 2008, at 1:44 PM, MH Michael Hammer (5304) wrote:
MH Michael Hammer (5304) wrote:

By what mechanism do you know that the 4 authors (from addresses) engaged someone from domain E?

By definition (in RFC 822).

By definition you don't know. You only know that someone CLAIMS that it is on behalf of someone else. Please cite the relevant section that SHOWS the authorization - it doesn't exist. There is a presumption of goodwill in the RFC that doesn't necessarily exist in a world where 85%+ of email is abusive (reference:
http://www.maawg.org/about/MAAWG20072Q_Metrics_Report.pdf )

The spam percentages are actually worse. Metrics are limited to some extent by the detection rates. Unfortunately, a growing percentage of spam is not detected by filters. : (

We currently have no way of knowing that across domains other than the fact that the person from domain E claims it.

Yes, but you only somebody you wish to hold responsible, and if E signed it you have someone. If nobody signed it, with E's SSP saying "strict signer", you can reject it.

It's a semantical matter, do you want to protect senders (as the name SSP suggests) or authors (in conflict with e-mail practice). For the typical case one From, no Sender, there's no difference.

Sometimes semantics actually matter. You have succinctly put the question but instead of a binary (author/originator vs sender/ injector), let's phrase it slightly differently.....what are we trying to protect from? And if all we are trying to protect is the sender, why would receiving domains (or MUAs) have any incentive to use DKIM or SSP? The more likely answer is that we are trying to protect receivers.....from abuse.

How frequently do we see authors/originators abusing senders/ injectors (other than compromised accounts or compromised hosts)? The more likely (and common real world) scenario is individuals using sender to abuse from.

DKIM can make an improvement by allowing the signer to clearly indicate which identity provided the message while also indicating all messages are signed. This identity does not need to match with the entity found within the From header. Any MUA highlighted information should exclude that not included within the signature's hash and not encompassed by the key g= and t= restrictions.

The next consideration might be whether unmodified MUAs can benefit from a compliance assertion. The answer is yes, provided the identity protected by an ASP or SSP compliance assertions can be encompassed by the key used to sign the message. SSP takes this too far, and ASP does not take this far enough.

IMHO ASP is less problematic. ASP at least requires a signature by the domain asserting policy. The time for MTA validation adoption will be longer than the distribution of intelligent MUAs able to make sane presentations of which DKIM identities are being assured. : )

The SSP _requires_ identity information to be falsified or ambiguous. It is ridiculous for domains to add two signatures, one to clarify an assured identity, and another to be SSP compliant. : (

What about the cases where domain E has no reputation?

Same problem as a PASS "From: A" (no B, C, D, E).

Not quite the same problem. From claims that it comes from A. It is DKIM signed by A and the signature has been verified. As a receiver I can make a link between the message and the origination domain for the purported author. I have no conflict to consider.

Agreed. For unmodified MUA protection, one might also wish to include the g= and t= parameter information contained within the key.

I can come up with 3rd party domains all day long (ok, I better hurry before ICANN moves on kiting/tasting) to sign arbitrary messages. Without a reputation - and if this approach is used for abuse - then the likely outcome is that reputation systems will consider a domain without reputation as significantly more likely to be abusive.

Agreed.

-Doug
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

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