RE: [draft-ietf-opes-smtp-use-cases-01]

jfcm <[email protected]> Thu, 20 Jan 2005 01:19:37 +0100
Newsgroups gmane.ietf.opes
Message-ID <[email protected]>
At 00:16 20/01/2005, The Purple Streak, Hilarie Orman wrote:
>I wonder if it is worthwhile noting a particular kind of non-symmetry
>that is common today.  Most people run SMTP on their local machine in
>order to send messages, but they do not run SMTP to receive messages;
>that is done by a remote server, and the user runs a different
>protocol (a Mail Retrieval Client?) to fetch the mail.  That means
>that and OPES server that is closest to the user will probably be
>acting as an SMTP relay, while that same server will be an SMTP
>endpoint for messages destined to that user.  Hope that's clear :-)

It is very clear. However please note that MTA cascade on the mail path and 
that we consider OPES on MTA (not on UA), so we do not really know where 
the user end is. Since we are to deal with SMTP and we want to stay with 
MTA only we can say that the end to end finishes at the last MTA?

The full symetry I documented is not for us to document it as symetric and 
to take care of MDA and MSA, but to understand what are the impacts the 
agents sequence implies and where the OPES should return even if we only 
care about MTA.

>Parts of the document are difficult to understand, particularly
>the part about referring to earlier commands.  What is that about?
>
>Some of the content adaptation use cases seem at odds with the earlier
>part of the document that say that these are part of the "mail
>delivery agent" which is NOT part of the MTA.  So I'd have expected
>those use cases to be out-of-scope.  What am I misunderstanding?

I understood it as the MTA output to the MDA?
This is why I put an OPES filter in each MTA filter.

>I can see "response modification" use cases that attempt to
>deal with "recipient unknown", for example.  It would be a way
>of implementing a "universal identity" on a incremental basis.
>If delivery fails, you consult the universal identity for
>an alternative delivery method.  Yes, the MDA or the MUA could
>do it, but it's a nice "in-the-network" kind of service.

Are some others not too? I objected a lot to the MTA location on this very 
ground because the charter permits it. I repeated it is what I call ONES 
and not what IAB calls OPES.

>Yes, I think that operating on the DATA portion fits into the
>architecture without the need for special consideration.

I am not sure I understand this. I need a example. Let say I have in the 
text something a filter should accept as "disregard the rules to apply 
because of the header" or to change the header, etc. Is that supported?

jfc