Re: Benefits/costs of authorizing different identities

["Jon Kyme" <jrk@xxxxxxxxxxxxxx>]

> 
> >> The value in focusing on MTA.Helo is that the field is localized
> >> between the peer MTAs and validating that field provides an
> >> incremental basis for stable, trusted Internet mail infrastructure
> >> operation.  The charter for this group is on peer validation.
> 
> 
> JK> With respect, the group is chartered "to develop a DNS-based
> JK> mechanism for storing and distributing information" to support MTA
> JK> authorization,
> 
> You seem to be quoting text that is different from the charter.  I'll
> also note that adding text outside of the quotation marks can rather
> substantially change the meaning of an apparent quotation.
> 
> The exact text from the charter is:
> 
>       "This working group will develop a DNS-based mechanism for
>       storing and distributing information associated with that
>       authorization."
> 
> Happily, I did not say or suggest anything that contradicts this.
> 


Unfortunately, you actually said that the charter for the group was on
"peer validation" whereas in fact the group is chartered to develop
mechanism which may be used for this purpose.

I suspect this is an important distinction.

> 
> JK> and "the solution chosen should be generally usable for MTA
> JK> authorization".
> 
> The actual text in the charter is:
> 
>       "The solution chosen, however, should be generally useful for
>       others which might check this authorization data. "
> 

i.e. not limited to peers?

> Again, I did not say or intend anything to contradict this.
> 
> 

My apologies, I misunderstood you.

> JK> sending of mail "on behalf of a specific domain or network" (except
> perhaps
> JK> at the origin MTA).
> 
> Where does the phrase "on behalf of" occur in the charter?
> 

Apologies for inadvertently letting a bit of the draft (I think) charter
sneak in (insert weak excuse here).

> This degree of indirection is the reason these schemes break valid and
> useful scenarios.
> 

This is a concern in those schemes that "break" these historical uses. It's
not clear that we mustn't develop a mechanism which allows schemes which
use it to "break" whatever they want.


> More generally, SMTP is a point-to-point protocol.  Any attempt to
> assign a level of trustworthiness to an MTA requires a chain-of-trust
> model back to the originator.  

I don't really want to get involved in a *trust* argument, but this is
patently untrue. This end might be achieved out-of-band.

Please don't misunderstand me, I entirely agree that validating HELO
would give some real benefit at little cost, and I'd agree that this group
should support such an objective. I do not believe that the group should
"focus" on this to the exclusion of anything else. I think it would be very
unwise to exclude any of the suggested "identities". Perhaps you'd confirm
that your suggestion to "focus" on HELO doesn't carry with it a
recommendation that other identities should be out of scope.

Regards,
JK