Re: Fwd: Re: Last Call: 'Message Submission' to Draft Standard

At 14:44 16/02/2005, Tony Finch wrote:
>On Wed, 16 Feb 2005, JFC (Jefsey) Morfin wrote:
> > I have not the competence to fully understand if this concerns 
> OPES/SMTP, but
> > I think it does? John quotes OPES in the discussion.
>
>Only for comparison, since both message submission and OPES may involve
>message alteration. The main area of discussion was the introduction of a
>distinction between pure SMTP (which in principle should be a clear
>channel, but historically has not been) and message submission (which
>involves a certain amount of limited message clean-up to enforce
>standards compliance). OPES is orthogonal to this.

Dear Tony,
Again I am not an SMTP specialist and I don't want to be one (for the good 
reasons you give). But I think I know a litte about about messaging and I 
am interested in end to end results. I also know that whenever there is a 
fix, someone needs to have her special way to tune/control/implement the 
fix. This is the role of the OPES.

> > All this, together with the current IDN security debate, etc. lead me 
> to think
> > that my interest in DN massaging is a key OPES issue and that the OPES/SMTP
> > proper location is the UA "virtual" I/O, that is at the first 
> (front-end) and
> > at the last (back-end) MTA only, what simplifies our debate and makes it of
> > immediate interest?
>
>A lot of current SMTP filtering deployments occur at a site's border MTAs
>or central relays, which are often a hop or two from any UA.

Absolutely true. But you have to be clear about where the OPES process is 
introduced in all that. And how many times. With which tracability tree and 
domain definition.

>It would be foolish to limit OPES/SMTP to the submission or final delivery 
>stages.

I am afraid, from the lack of debate/work on this list, we lost focus and 
we do not know what we are supposed to talk about. OPES are related to 
"edge". I am talking about edge. I opposed the charter for that reason - I 
think OPES can only be related to UA. Once it was approved I welcame the 
work on something called "OPES/SMTP" because it is an _other_ issue than 
OPES buut of real interest to me. Now I see that proper OPES thinking, the 
way it was developped for http, does not fit with the SMTP/MTA architecture.

So, I propose to unlock our own situation in saying: let work on UA 
interfacing at MTA level since OPES are proxy functions and we said the IAB 
we wanted to work at MTA level. This is probably a clear thing this group 
can work on (not heard from Alex in nealry 3 months)? I would see a real 
deployment interest in this (in particular for considering an SMTP 
submission/delivery solution - staying compatible with current user agents 
- but not using SMTP for transport).

jfc