AW: SMTP filtering use case

["Martin Stecher" <martin.stecher@xxxxxxxxxxxxx>]

I have a different view on this.

 
> Your filtering example is based on delivery to an SMTP server that
> knows that the recipient of the single message is actually an alias.

No, I am not talking about an alias.
It is a very common SMTP behavior that one message is sent to multiple recipients, especially if they belong to the same domain.
This happens in the SMTP dialog.
After the first HELO and MAIL FROM messages the sending MTA sends multiple RCPT TO messages which get all acknowledged one by one.
The receiving SMTP MTA keeps the list of all recipients and delivers to all of them (sometimes it needs then to create copies, sometimes not).

> The OPES service must know the expansion of the alias to the 20
> recipients (any one of which could actually be an alias for another
> list).  This means that the SMTP service and the OPES service are very
> tightly coupled.  As I said, I'd always assumed that the OPES 
> processor
> would have the user preferences, and that's the whole reason for the
> rules, etc., and for having the OPES processor be the 
> enforcement point
> for privacy policy.  But, I guess that assumption is open to debate.

I believe that there will be several implementations of OPES processors that do not want to deal with the complete user preferences and rule engine, but leave this work for the callout service.

> 
> But there's another reason that I'm still not convinced that this SMTP
> example applies to OPES.  If this service and all the user preferences
> are handled by a callout server, there's no reason that the callout
> server cannot just forward the transformed SMTP message to a real SMTP
> server for final delivery.  Because SMTP is a store-and-forward
> service, not end-to-end, this works better than OPES would - there's
> less I/O involved.

This could be done. But we will loose the biggest benefits of the callout strategy at all:
Especially for EMail no message must be lost. The OPES processor is the thing that the user trusts, that has long experience what to do with messages that cannot be delivered immediatly, how to manage queues and so on.
The callout service is "just" for filtering the messages. If it crashes or fails or has a disk crash, it does not affect all waiting messages. That's a very important point I think.

Martin