On 6/18/2013 6:32 PM, Murray S. Kucherawy wrote:
On Tue, Jun 18, 2013 at 7:59 AM, Dave Crocker <dcrocker(_at_)bbiw(_dot_)net
On 6/18/2013 7:18 AM, Tony Hansen wrote:
> I always thought it would be a nice follow-on to DKIM to provide
> for a site to specify how that site was using i=; that is, to
> some clarity and comprehension for that value. For example, our
> implementation placed the authenticated userid into i=. I know
> site that appears to use a hash of the authenticated userid.
John L says
> his site uses "how the mail was injected (submit, webmail,
> who the user was if it knows". When there is a deterministic
> used to create i=, and the mechanism is known, then it is
> additional logic to be added to the receiving side as well.
It would also have to be something trustable. Otherwise, why should
you believe the party making such a statement? A bad guy will put any
value there that increases the likelihood of making it to the inbox,
whether it's true or not.
Absolutely. This really has nothing to do with increasing or decreasing
the likelihood of a message making it to the mailbox. It has to do with
being able to make additional positive value judgements about messages
that *have* made it to your inbox. People keep incorrectly conflating
the making of positive statements about a message with trying to keep
messages from the inbox; such thinking is what leads to such erroneous
documents as "dkim-is-harmful".
DKIM shines with telling you positive verifiable statements about an
email message and its attributes. It's the messages that pass those
positive verifications that I'm interested in for such additional tests.
Consider combining the reputation of the domain with the verification of
the sending domain with the verification of the authenticated user who
sent the message. I feel that a message passing those tests can lead to
a *stronger* positive statement about the message than one not having
any information about the authenticated user. If the sending mailhost is
one that has a good reputation, and the sending mailhost chose to use i=
in a way that allowed me to make additional checks about the user, I
think I would be better off.
I'm sure Tony already knows this, but just to make sure it's part
Anyone can define a value-added protocol layer on top of
can define all sorts of additional semantics.
It needs a method of declaring its presence, such as an extra
header field or a special external query, but after that, it's free to
define anything it wants, including a public meaning for i=
ATPS did exactly this. It may be a poor example in that it has seen
approximately zero uptake due to lack of demand, but it does
demonstrate the mechanism Dave's describing here.
Both ADSP (not ATPS) and DMARC define a value-added protocol layer on
top of DKIM, and are attacking complementary issues. I won't got into
reasons I think ADSP has gotten no traction.
NOTE WELL: This list operates according to