Subject: RE: SMTP filtering use case

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 17 Feb 2003 10:44:54 -0800

-----Original Message-----
From: Alex Rousskov [mailto:[email-masked]] 
Sent: Monday, February 17, 2003 10:44 AM
To: OPES WG (E-mail)
Subject: Re: SMTP filtering use case

Martin,

	We are on the same page, I think. I am not sure a single SMTP
message can have multiple true recipients because SMTP clients I have seen
would usually send multiple copies, one to each To:/Cc: address. (SMTP gurus
please correct me). Fan out is possible when recipient is an alias
([email-masked]) that SMTP server expands into unfiltered
[email-masked] and filtered [email-masked]. As far as I can see, that
expansion can happen at the OPES client or at the OPES server (in theory),
but the difference is minor.

Obviously, this optimization feature complicates the protocol. Special care
needs to be taken to insure that all expanded recipients get the message
even if, for example, the OPES server goes down in the middle of the
processing, after sending the first (marked, unfiltered) response to the
first group of recipients. This complicates client-server negotiations: they
need to agree on how many responses and to what recipients there will be so
that OPES client can take over if OPES server fails (and save the messages
to yet unprocessed recipients, for example).

Do you think the optimization is worth the complexity? Can you think of
other, non-SMTP related uses where multiple responses to a single OPES
request would be useful?

[RP] Hummm...I guess whenever the subscriber identity/preferences are
blurred by network devices/applications, i.e, you have a M:N relationship
between recipients of a message/packet and services. Wouldn't this happen
with RTP streaming reflector and multicast? 

Regards,

Reinaldo

N.B. A third way to implement what you want is to allow multiple "recipient"
addresses in an OPES request to mean that there are actually multiple
requests, _without_ duplicating the request on the wire. Same for responses.
This approach could be called a "lazy copy" optimization. The difference is
subtle, but it causes fewer protocol complications than allowing (at the
protocol level) multiple responses to a single request.

Thank you,

Alex.

On Mon, 17 Feb 2003, Martin Stecher wrote:

>
> Hi Hilarie and Alex,
>
> I think that we are not talking about the same SMTP filtering 
> scenario. Let me build on the virus filtering example and describe a 
> concrete use case:
>
> There is a SMTP MTA dealing as the incoming mail server of a company. 
> It is OPES enabled and uses a callout service to do virus filtering on 
> all the incoming messages. Every individual in the company can select 
> his/her preference: Infected messages can either be replaced by an 
> alert message or can be repaired. This property is kept in a directory 
> service for the company. The OPES SMTP device is a general 
> implementation which is not aware of virus scanning techniques and 
> especially not on the user preferences, it does not access the 
> directory service at all, but the callout service does.
>
> Now the OPES device receives an email messsage containing a virus 
> which is sent to 20 recipients within the company. It is a single 
> message!
>
> The OPES client forwards this one message to the callout service. That 
> one looks up the AV filter preference in the company's directory 
> service. The callout service detects the virus and sees that 18 
> recipients want to have the message repaired and 2 recipients prefer 
> to get the virus replaced by an alert.
>
> From this point on two copies of the SMTP message are required with 
> different content. One to be sent to 18 recipients the other to the 
> other 2.
>
> How could this be solved?
> - By enabling the OPES protocol to return two copies of an application
>   message in response to one filtering request
> - By requiring that the OPES edge device ensures to pre-generate copies
>   of the application message where each copy guarantees to result in
>   only a single response.
>
>
> Martin
>

---

From: "Abbie Barbir" <[email-masked]>
Date: Mon, 17 Feb 2003 14:01:33 -0500

Oskar,

good point(s)

abbie

> From: Oskar Batuner [mailto:[email-masked]] 
> Sent: Monday, February 17, 2003 1:46 PM
> To: OPES WG (E-mail)
> Subject: RE: SMTP filtering use case
> 
> 
> 
> Martin,
> 
> I believe OPES protocol should work in this kind of scenario by 
> applying it's own transaction boundaries. Being application 
> agnostic callout protocol does not provide one-to-one mapping 
> between callout protocol messages and application messages.  
>  
> In this scenario single OPES transaction may encapsulate 
> multiple response message instances generated by the server. 
> OPES client by its nature is application specific, so 
> in this case it should expect that a single application message 
> included in OPES request may result in multiple application 
> response messages included into the OPES response, together 
> with - again, application-specific - information how to use 
> each application-level response message. 
> 
> Keeping OPES transaction context independent from the 
> application semantics helps to ensure service 
> reliability: OPES client can detect situation when the 
> request processing was not completed and take the appropriate 
> steps.
> 
> - Oskar
> 
> > From: [email-masked] 
> > [mailto:[email-masked]]On Behalf Of 
> Martin Stecher
> > Sent: Monday, February 17, 2003 4:45 AM
> > To: OPES WG (E-mail)
> > Subject: SMTP filtering use case
> > 
> > 
> > 
> > Hi Hilarie and Alex,
> > 
> > alert message or can be repaired.
> > This property is kept in a directory service for the company.
> > The OPES SMTP device is a general implementation which is 
> not aware of
> > virus scanning techniques and especially not on the user 
> preferences,
> > it does not access the directory service at all, but the callout
> > service does.
> >

---

From: "Abbie Barbir" <[email-masked]>
Date: Tue, 18 Feb 2003 04:46:35 -0500

> From: Robert Collins [mailto:[email-masked]] 
> Sent: Monday, February 17, 2003 5:50 PM
> To: Oskar Batuner
> Cc: Alex Rousskov; [email-masked]
> On Tue, 2003-02-18 at 09:17, Oskar Batuner wrote:
> 
> 
> > There may be any number of reasons for the callout processor to
> > produce multi-message response, the protocol just SHOULD 
> (MUST?) support 
> > multiple responses while preserving transactional integrity.
> 
SNIP

> To me, if user details are in a directory, detection of user 
> preferences seems to be orthogonal to the OPES transaction. 
> *Identification* of the user within the OPES transaction may 
> be useful though.
> 
> Rob
SNIP

-------- abbie 

I agree, detection of user preferences is needed. I also believe that
Identification of the user within the OPES transaction is more than useful,
it may be needed.

---

From: "Abbie Barbir" <[email-masked]>
Date: Tue, 18 Feb 2003 19:01:22 -0500

Well,

it is getting interesting.

I would like each one of us (all Protocol participant)to state what we have
agreed on so far from their point of view (from the various threads, it is
hard to figure that out). 

I would like to make a summary of yes and no and maybe's for the protocol
that could be (after further enhancements) presented in SFO.  

abbie

> Sent: Tuesday, February 18, 2003 2:19 PM
> To: The Purple Streak, Hilarie Orman
> Cc: [email-masked]
> On Tue, 18 Feb 2003, The Purple Streak, Hilarie Orman wrote:
> 
> > It's very difficult to satisfy the IAB concerns by saying 
> that callout 
> > servers will handle all policy - we aren't specifying the callout 
> > server applications.
> 
> We are specifying the protocol the OPES server MUST implement 
> to be called an OPES server. Our protocol may specify 
> requirements that can only be satisfied if OPES processor and 
> OPES server work together and do not violate each-other 
> assumptions. That approach can both satisfy the IAB concerns 
> and allow for different implementations/integrations of 
> processors and servers to exist.
> 
> In other words, ideally, we should only care about the 
> visible end-to-end effect (the black-box approach) of a compliant
> processor+server combo, not about what a particular OPES processor or
> server may end up doing to satisfy our MUSTs.
> 
> > I think that scenarios which can be satisfied by a switch are just 
> > fine, but if they can be deployed today without any new protocols, 
> > then they aren't topics for discussion in this WG, except 
> as negative 
> > examples, i.e., "you don't need OPES for that".
> 
> If they are deployed today without OPES, they will violate 
> IAB concerns/requirements. That is why we are chartered, in 
> part, to produce a new protocol that addresses IAB concerns.
> 
> Alex.
> 
>

---

From: jfcm <[email-masked]>
Date: Wed, 19 Feb 2003 18:01:34 +0100

>that could be (after further enhancements) presented in SFO.

Here is a quick dispatcher side list of questions I try to address right 
now with "C" functions and real machines in mind.  I read this list to try 
to get ideas/responses, so I have not yet formalized a list of questions to 
address, so it is only a few and in disorder. Different thninking it seems. 
If it may help?

   - is it (dispatcher) meant to be single? or to work in:
      - coordination (one is master)
      - cooperation (related egal)
      - distribution (lose equal / specialized )
      etc.

   - can it delegate the dispatching role?
      - on load
      - by default (failure)
      - on rules
      - how
      - what is the inter-dispatcher protocol
      - does it include axfr or each dispatcher is by its own?
      etc.

   - which servers does it relate with?
     - how the servers letit know they are there
     - how does it négotiate cooperation
     - how is that information memorized?
     - how is it maintained (refreshed)?
     - what are the recovery procedures
     - are there connection/task priorities supported?
     - is competing support supported?
     - are there some task recovery support?
     - type of channel/security support

- how is the user to remotely contol the ONES server
   - information it is to pass?
   - when?
   - TTL?
   - dissemination? When?
   - reporting to the user?
   - cancellation/zapping ability
   - negociations
     etc.

- how do we want to write the specifications of the protocol?
    - plain language
    - specialiized language
    - specific high level language adapted to the architecture
    - or work on the definitions as we progress
    - "C" examples as function or a reference default
       OPES dispatcher and servers.

jfc

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.454 / Virus Database: 253 - Release Date: 10/02/03