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