ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] RFC4871bis

2009-01-27 12:04:13
[Changing subject as per Dave's request]

I've thought about just sort of passively watching UAID values and
building heuristics to guess whether they are worth assessing or not.
It might be really useful, or it might just be a complete waste of
resources.  There's no good way to know for sure without doing the
research first.

That said, I plan to do the research at some point in the (hopefully
near) future.  So long as the spec accounts for experimentation and
doesn't forbid it, I think we'll be fine.

-----Original Message-----
From: Jeff Macdonald [mailto:jmacdonald(_at_)e-dialog(_dot_)com] 
Sent: Tuesday, January 27, 2009 11:50 AM
To: Suresh Ramasubramanian
Cc: Adkins, Michael; dcrocker(_at_)bbiw(_dot_)net; DKIM IETF WG
Subject: Re: [ietf-dkim] draft Errata on RFC 4871

On Tue, Jan 27, 2009 at 09:31:51PM +0530, Suresh Ramasubramanian wrote:
The few large cases are

1. Exceptions to the general rule

2. Useful only when backed with some out of band discussion about
these .. I trust you to know that when you sign email as good (or bad)
it probably is that . but how much would I trust other providers?  Or
suppose a sender signs his mail streams as "transactional", "coi",
"soi", it entirely depends on how much I trust their assessment, and
in some cases whether the sender is actually emitting "coreg",
"leads", "harvested"

That kind of corner case often involves a judgement call on the part
of the admin, and a shared understanding of the i= notation, and of
the underlying reputation model.

ah, I think I understand now. This is simply a mechanism to limit the
amount of potential i= values. If d= is in a some sort of list, then
i= would be included the reputation model.

I'd still think even given that model, you'd let the actions of the i=
determine the trustworthness of the steam independent of what the owner
of d= claims.


-- 
Jeff Macdonald
jmacdonald(_at_)e-dialog(_dot_)com


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