| 1-1: Virus checking |
| Proposed by Martin Stecher on 10/22/2004 |
| Replaces infected attachments with an virus alert. |
| 1-2: Other security policies (e.g. forbidden attachment types) |
| Proposed by Martin Stecher on 10/22/2004 |
| Replaces or removes unwanted attachment types |
| 1-3: Content Analyzes (classify content into categories, search for forbidden content) |
| Proposed by Martin Stecher on 10/22/2004 |
| 1-4: Translation of message text |
| Proposed by Martin Stecher on 10/22/2004 |
| 1-5: Format Verification |
| Proposed by jfc on 11/13/2004 |
| 1-6: Format Conversion |
| Proposed by jfc on 11/13/2004 |
| For example XLM to ASN.1 |
| 1-7: Filter Spam |
| Proposed by Martin Stecher on 10/22/2004 |
| Pure content adaption may just mark the message, for other actions see section 3 |
| 1-8: Transform content to make it better readable on special mail clients |
| Proposed by Martin Stecher on 10/22/2004 |
| For example Blackberries |
| 1-9: Encrypt emails or verify signature. |
| Proposed by Martin Stecher on 10/22/2004 |
| 1-10: Addition of prioritized reading depending on content, previous mails, etc. |
| Proposed by jfc on 11/13/2004 |
| 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-1: Validate "MAIL FROM" |
| Proposed by Martin Stecher on 7/14/2004 |
| In the "MAIL FROM:" command it gets the sender's email address. Before replying to this command (allow/deny) it sends an OCP request to an OPES service that checks in the corporate directory service whether that employee is allowed to send mails to the Internet. Depending on the OCP response the MTA replies in the SMTP dialog with allow or deny. |
| 2-2: Validate "RCPT TO" |
| Proposed by Martin Stecher on 7/14/2004 |
| Opposite case of 2-1. The MTA sends OCP requests for all "RCPT TO:" commands for incoming messages and asks the OPES service whether the recipient exists and is allowed to receive email. |
| 2-3: Sender validation via IP, HELO, SenderID, etc. |
| Proposed by Martin Stecher on 7/14/2004 |
| Sender validation via OPES. OPES service checks sender IP, HELO command, resolves the sender address etc. This may tell the MTA not to accept the message for delivery. Could even be done asynchronously for some parts, i.e. sending the OCP request after HELO or MAIL FROM and continuing to handle recipients and to receive the mail body. The response then needs to be there before the message gets finally accepted. |
| 2-4: Resolve distribution lists |
| Proposed by Martin Stecher on 10/22/2004 |
| 2-5: Multilingualism : check availability of language aliasing names |
| Proposed by jfc on 11/13/2004 |
| 2-6: Hide/change header elements |
| Proposed by jfc on 11/13/2004 |
| 3-1: Delay a message of a certain size or content |
| Proposed by Martin Stecher on 10/22/2004 |
| 3-2: Send virus notifications to others when virus has been detected |
| Proposed by Martin Stecher on 10/22/2004 |
| 3-3: Move email to a special queue (e.g. Spam queue) |
| Proposed by Martin Stecher on 10/22/2004 |
| 3-4: Drop a (spam) message |
| Proposed by Martin Stecher on 10/22/2004 |
| 3-5: Drop, move - this is reroute possibility. |
| Proposed by jfc on 11/13/2004 |
| 3-6: Copying alternative mailbox upon management rules (for example: mails received during the night being copied to an operator on duty) |
| Proposed by jfc on 11/13/2004 |
| 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. |
| 3-7: Out of office replies |
| Proposed by Martin Stecher on 10/22/2004 |
| 3-8: Convert attachments into HTTP links |
| Proposed by Markus Hofmann on 10/22/2004 |
| Stripping of large attachments from emails, putting them on a Web server, and replace the attachment in email with a URL to that server file |
| 3-9: Preventing mail to cross some areas of the network. |
| Proposed by jfc on 11/13/2004 |
| 3-10: Mail Anonymizing |
| Proposed by jfc on 11/13/2004 |
| This is a feature provided in some mailing list. The problem is that it only anonimizes the header. If the mail is a reply-to, the name of the replier is often in the return formula "at 16:24 etc. John Doe etc". |
| 3-11: Language analysis to accept or reroute a mail |
| Proposed by jfc on 11/13/2004 |
Back to homepage