At 17:33 02/02/2005, Martin Stecher wrote:
> I don't see how D (email body modification) "falls back" to A (command
> modification), but as long as it can be done, I don't care what letter
> gets assigned to it.
On Jan 20 you replied to an earlier message saying:
> Yes, I think that operating on the DATA portion fits into the
> architecture without the need for special consideration.
That is what I wanted to describe here again. The email message body is
the data coming after the DATA command. It can be seen also as command
modification. No special consideration necessary -> D "falls back" to A.
This is true with unstructured text. But not with structured text messages
(XML, ASN.1, proprietary formats, signals, etc.).
> I'd not thought that the OPES processor would be maintaining queues, [...]
And I assumed that most MTAs maintain something like queues in order to
store the messages they receive before they forward them (or maybe to store
if they cannot forward immediatly). But I may be wrong.
Has anybody a clear view on how many MTAs (percent of real world deployment)
can only work in a non-storing proxy mode (only accepting a message if they
already successfully forwarded to the next MTA in a parallel SMTP dialog)?
And how many MTAs do always store a message before forwarding?
And how many try a direct forward and store only if that does not work out?
This is standardizing, not market study for a type of response. Also, you
cannot consider existing systems when defining something whioch may change
their architecture. All the point I make are part of the brain storming we
make on a new (compatible) generation mail server.
jfc