The discourse into other services Keith and I engaged in
notwithstanding, I think that, if your draft is going to go
anywhere, it will need at least two things that are not there at
present:
(i) Either
--a requirement that the approach not be used with
authentication of the source and a description of the nature
of or conditions for that authentication (and, in Keith's
model, authorization to present a particular priority). Or
--an analysis of why originator authentication is not needed.
OK - so would expanding the security section help? I don't want to be
prescriptive, as there are a lot of different cases that might make
sense. But a discussion on what an implementor might want to consider
for various possible cases could be included there. Is that the sort
of thing you are after?
If so - I'll draft some text and send it out.
(ii) An analysis of how this would interact with intermediate
MTAs (e.g., the targets of lower-preference MX records that
happened to be picked up as well as any submission MTA used by
the initial (originating) MUA. Or, again, an analysis of why
that isn't a problem. For example, you could try to insist
that the option not be used where intermediate MTAs are present,
but that involves other issues. And, if you assume that
intermediate MTAs might be present, note that their presence may
have some implications for the trust relationships associated
with originator authentication and authorization.
Ummm - I think you lost me here... I'm not sure what you are asking or
suggesting. The extension is meant to be used on a hop by hop basis,
and should be used regardless of what the hop type is. Is there some
similar extension that does this that I could refer to. In my mind,
this draft shares a lot of common ground with the SIZE extension.
Julian.