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