ietf-openproxy
[Top] [All Lists]

RE: SMTP filtering use case

2003-02-17 11:45:06


-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com] 
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
(management(_at_)company(_dot_)com) that SMTP server expands into unfiltered
bob(_at_)company(_dot_)com and filtered rob(_at_)company(_dot_)com(_dot_) 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

<Prev in Thread] Current Thread [Next in Thread>