Re: SMTP Use Cases

As you know I think that a front-end program on an MTA can be called an 
OPES. I also think that what is intended to be studied is a nearly kill for 
the IAB architecture in implementing a de facto virtual middlebox network 
layer. So, I opposed the text of the charter.

This being said, I fully support the need of the intended work. I added a 
few suggested cases to the list.

At 11:19 22/10/2004, Martin Stecher wrote:
>There are use cases for SMTP message content (1) and SMTP dialog
>adaptation (2). And there are use cases where the message content
>may have an influence on mail forwarding options or trigger
>other side effects (3).
>
>1. Examples for message content adaptation:
>
>- Virus checking
>- Other security policies (e.g. forbidden attachment types)
>- Content Analyzes (classify content into categories, search for forbidden 
>content)

Language analysis to accept or reroute a mail

>- Translation of message text

Yeap, but since this a very complex issue, some other simpler are in 
immediate need:
- format verification
- format adaptation (ex. XLM to ASN.1)

>- Filter Spam (pure content adaption may just mark the message, for other 
>actions see below)
>- Transform content to make it better readable on special mail clients 
>(e.g. Blackberries)
>- Encrypt emails or verify signature.

Addition of prioritized reading depending on content, previous mails, etc.
Putting a mail into a context - adding classification elements.
Adding notes on used words.
Parameter conversion (for example text can contain variables that will be 
entered : name, conversion rate, etc.)

>2. Short form of the examples for SMTP dialog adaptation I gave in my emai
>on July 14, plus a new one:
>
>- Validate "MAIL FROM"
>- Validate "RCPT TO"
>- Sender validation via IP, HELO, SenderID, etc.
>- Resolve distribution lists

Multilingualism : check availability of language aliasing names
Hide/change header elements

I do not know where to put that : preventing mail to cross some areas of 
the network.

>3. Examples for mail forwarding options or other side effects:
>
>- Delay a message of a certain size or content
>- Send virus notifications to others when virus has been detected
>- Move email to a special queue (e.g. Spam queue)
>- Drop a (spam) message

Drop, move - this is reroute possibility.
Copying alternative mailbox upon management rules (for example: mails 
received during the night being copied to an operator on duty)
This may create archives, permit mail tapping
They may be used for any kind of usage statistics about mailing usage, 
linguistic, rate of crypted messages, etc. for a better knowledge of 
general, national, corporate mailing usages.

>- Out of office replies

Security : spam alert.
Statistics on spam origin and spammer tracking: today anti spam systems are 
local. OPES permits to correlate their data in real time (same server), 
better react. Since spam is a favored vector for viruses, we are in the 
core of cybersecurity.



A problem we might also resolve and which is quite a problem is retrospam. 
Many servers like AOL send back the whole text of the non delivered mails. 
This is used for retrospam. An OPES could refuse error message with a long 
text, cut the text and send it back. This way the retrospamed person would 
be protected and the retrspaming server would create itself an heavy load 
incitating it to stop. This should be supported by Best Practice RFC making 
netiquette not to send back message texts (and often viruses).  This would 
be a simple way to get "OPES" (I do not think this is OPES :-) known and 
possibly get interest and funding.

The main aspect of the OPES architecture is that it can be easily deployed 
without needing the existing MTA to be modified. So they can be easily 
imposed by ISP or an anti-spam protection act. In this they can help 
setting real virtual mail fire wall (one of the application we should put 
forward for HTTP support is application firewalling).

I would be interested by comments on this point ASAP as there is a French 
Gov meeting on Spam this week, the debate on retrospam is hot and this 
could help to make our work advertised. As IAB RFC 3869 puts it, IETF needs 
Gov. subsidies. Digital Defense (Govs start seeing spam as a real threat on 
economy, cf. spam attack on Banks) is certainly a good topic in that area. 
But it need to be well documented. For example in France we have (and I 
understand there is the same approach in the US) "Dual" projects which are 
funded more easily. These are project which jointly interest commercial and 
military interests (innovation, but also standardization which permits 
military to use/protect civilian resources in case of conflict). I have an 
industrial partner who could be interested in proposing a test network of 
OPES filters supported by a few redundant OPES servers.

The debate at the WSIS starts on the role of Govs in the Internet 
Governance, I document that through "regalian services" proceeding from 
"regalian duties" (they usually are Defense, Foreign Affairs, Justice, 
Money, etc). This is the time to document that anti-virus and anti-spam 
citizen and business protection belongs to regalian duties. This kind of 
demand is illusory if it is not feasible : OPES make it feasible.

jfc