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