ietf-openproxy
[Top] [All Lists]

Making Progress on OCP/SMTP Work Item

2005-12-13 13:55:29

Folks,

as agreed upon in Vancouver, we now must focus on the "tracing" and "bypass" issue in order to make progress on the OCP/SMTP work item.

We must get consensus on what "tracing" and "bypass" means in the email context. E.g., do the IAB considerations on tracing/bypass apply unmodified to email or are there reasons to consider them differently? How would one trace/bypass in the email world?

In order to get a discussion going, let me repeat from an earlier email from Martin.

===== email from Martin from 10/26/2005 ====

In former drafts we concentrated on classic client-sends-request-to-server-which-replies-with-a-response environments. Here and there, we have indications that other application protocols exist, for example: RFC3914: "Moreover, some application protocols may not have explicit responses..."

In SMTP tracing information for the email recipient is trivial. But
reliable notifications for the email sender are a problem (a general
problem with SMTP not only for OPES). How does that correspond to the IAB considerations? What do you think about DSN (RFC1891) and Message Tracking (RFC3885) to build on for OPES/SMTP?

Bypass is the other way arround. OPES bypass is usually client controlled. Does that mean email recipient controlled? It is hard to check the client's bypass requests in a sender centric OPES system.
What do you think about the bypass section in draft-ietf-opes-smtp-00?
Does that work or do we need an out-of-band solution?


===== end email from Martin =====

Any thoughts? We must make progress on this front, first.

Thanks,
  Markus

<Prev in Thread] Current Thread [Next in Thread>
  • Making Progress on OCP/SMTP Work Item, Markus Hofmann <=