RFC 4496
Open Pluggable Edge Services (OPES) SMTP Use Cases
Open Pluggable Edge Services (OPES) SMTP Use Cases 💌
okay bestie, this is RFC 4496 🎀 (part 1 of 3!). It's an Informational doc, so it's just sharing info for the Internet community and isn't a standard. It's dated May 2006 and written by M. Stecher from Secure Computing and A. Barbir from Nortel 🧚. The title block doesn't list anything it obsoletes or updates, so it's a totally standalone vibe ✨.
Status of This Memo 📜
this memo is giving "info only" energy 🦋. It doesn't specify an Internet standard of any kind, and distribution is unlimited, so share it wherever you want 💅.
Copyright Notice ©️
The Internet Society owns the copyright, and it's 2006 💜.
Abstract 🌸
the OPES framework is application agnostic, which just means it doesn't care what the app is 👑. The app-specific bits are the adaptations that extend it. This doc walks through OPES SMTP use cases and deployment scenarios to get ready for SMTP adaptation with OPES 📧✨.
Table of Contents 🗂️
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Brief Overview of SMTP Architecture .............................3
3.1. Operation Flow of an OPES SMTP System ......................4
3.1.1. OPES SMTP Example ...................................5
4. OPES/SMTP Use Cases .............................................6
4.1. Security Filters Applied to Email Messages .................6
4.2. Spam Filter ................................................7
4.3. Logging and Reporting Filters ..............................8
4.4. Access Control Filters .....................................8
4.5. Secure Email Handling ......................................8
4.6. Email Format Normalization .................................8
4.7. Mail Rerouting and Address Rewriting .......................9
4.8. Block Email during SMTP Dialog .............................9
4.9. Convert Attachments to HTTP Links ..........................9
5. Security Considerations ........................................10
6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................10
Acknowledgements ..................................................111. Introduction ✨
okay so the OPES architecture [1] lets cooperative app services (called OPES services) work together between a data provider, a data consumer, and zero or more OPES processors 🫶. These services look at application-level messages swapped between the provider and consumer, and they might change them too 💖. The OPES processor can share the work by teaming up with one or more remote callout servers 🌈.
Those services run based on a set of rules installed on the OPES processor 📋. When the rules get evaluated, they can kick off service apps that live locally on the OPES processor or on a remote callout server 🔥.
Use cases for OPES based on HTTP [8] are covered in [2] 🌸. This work is all about OPES for SMTP [7] use cases, and it adds extra use cases plus upgrades to the kinds of OPES services defined in [2] 💅.
In SMTP, the OPES processor can be any agent that takes part in SMTP exchanges. That includes a Mail Submission Agent (MSA), a Mail Transfer Agent (MTA), a Mail Delivery Agent (MDA), and a Mail User Agent (MUA) 🧚. This document focuses on the case where the OPES processor is an MTA 💌.
SMTP is store-and-forward, which is kinda iconic 📮. Current email filtering systems either run during the SMTP exchange, or they work on messages that have already arrived after the SMTP connection closed (like in an MTA's message queue) 🙈.
This work focuses on SMTP-based services that want to change command values or block SMTP commands 🎀. To block a command, the service gives an error message that the MTA should use in response to the command it got 🚫. An OPES MTA gets involved in SMTP command modification and command satisfaction, which is basically the SMTP version of request modification and request satisfaction from HTTP [8] ✨.
2. Terminology 📚
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are read as described in [6] 💜. When they're used with their normative meanings, they'll be all uppercase 🔠. Lowercase versions of these words are just normal everyday prose with no normative implications, so don't panic 🫶.
3. Brief Overview of SMTP Architecture 🦋
the SMTP design, taken from RFC 2821 [7], is shown in Figure 1 🌸. When an SMTP client has a message to send, it sets up a two-way transmission channel to an SMTP server 💖. The client's job is to transfer mail messages to one or more SMTP servers, or to report that it failed to do so 📬.
+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Client |Commands/Replies| Server |
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
SMTP client SMTP serverFigure 1: SMTP Design 🎀
sometimes the domain name(s) passed to the SMTP client, or figured out by it, are the final destination(s) for the mail 🏁. Other times the domain name it finds is just an intermediate stop where the mail gets relayed through 🔁.
An SMTP server can be the ultimate destination, or it can be an intermediate "relay" or "gateway" 🌉. (That means it might forward the message on using some protocol other than SMTP, or use SMTP again and act as an SMTP client itself 🔄.)
SMTP commands come from the SMTP client and get sent to the SMTP server 📤. The SMTP server sends responses back to the client in reply to those commands 📥. Message transfer can happen over one connection between the original sender and the final recipient, or it can happen over a bunch of hops through intermediary systems 🛤️. Clients and servers trade commands and responses, and eventually the mail message body goes across too 💌.
Figure 2 zooms in on the mail flow in an SMTP system 🔍. You can find more about how email architecture works on the Internet in [9] 🌐.
+-------+ +---------+ +---------+ +--------+ +-------+
|mail M| |M mail M| SMTP |M mail M| SMTP |M mail M| |M mail |
|clnt U|--|S srvr T|------|T gway T|------|T srvr D|--|U clnt |
| A| |A A| |A A| |A A| |A |
+-------+ +---------+ +---------+ +--------+ +-------+Figure 2: Expanded SMTP Flow 💖
in this work the OPES processor can be any agent taking part in SMTP exchanges, like an MSA, MTA, MDA, or MUA 🧚. But this document zeroes in on use cases where the OPES processor uses the SMTP protocol, or one of the protocols derived from SMTP Message Submission (SUBMIT) [10] and the Local Mail Transfer Protocol (LMTP) [11]) 🎯.
3.1. Operation Flow of an OPES SMTP System 🌊
in this work an MTA is the OPES processor device that sits right in the data stream of the SMTP protocol 🌈. The OPES processor gets an upgrade with an OCP (OPES callout protocol) [3] client, which lets it vector data out to the callout server 🚀. The filtering functionality lives on the callout server 🧠.
a client (a mail user) starts out with an email client program (MUA) 💌. The user sends email to an outgoing email server 📤. On that email server there's an MSA (mail submission agent) waiting to receive email from the user 👀. The MSA uses an MTA inside the same server to forward the user's email to other domains 💨. (Communication between the MUA and MSA can happen via SMTP, SUBMIT [10], or something else like MAPI 🫧.)
The MTA on the user's email server might contact the recipient's email server directly, or it might go through other intermediate email gateways 🌉. The sending email server and all the intermediate gateway MTAs usually talk to each other using SMTP 💬. Talking to the destination email server usually uses SMTP or its derivative, LMTP [11] 📮.
On the destination email server, a mail delivery agent (MDA) can deliver the email to the recipient's mailbox 📥. The recipient's email client might use a different protocol (like the Post Office Protocol version 3 (POP3) or IMAP) to get into the mailbox and fetch and read the messages 👑.
+-------+ +---------+ +---------+ +--------+ +-------+
|mail M| |M mail M| SMTP |M mail M| SMTP |M mail M| |M mail |
|clnt U|--|S srvr T|------|T gway T|------|T srvr D|--|U clnt |
| A| |A A| |A A| |A A| |A |
+-------+ +---------+ +---------+ +--------+ +-------+
| | |
| OCP | OCP | OCP
| | |
+----------+ +----------+ +----------+
| callout | | callout | | callout |
| server | | server | | server |
+----------+ +----------+ +----------+Figure 3: OPES SMTP Flow 🌸
looking at Figure 3, the MTA (the OPES processor) is either receiving or sending an email (or both) inside an email server or gateway 💞. An OPES processor might be the sender's SMTP server, the destination SMTP server, or any intermediate SMTP gateway 🧚. (Which building block belongs to which authoritative domain is an important question, but the answer is different from deployment to deployment 🔐.) Figure 3 shows several OPES deployment options in a typical chain of mail servers and gateways with different MSA, MTA, and MDA roles 🎀. The OPES standard case, though, only has a single OPES processor and a single callout server in the message flow 🦋.
3.1.1. OPES SMTP Example ✨
okay so here's a typical (minimum) SMTP dialog between two OPES SMTP processors (MTA) 💌 (C: is the client, S: is the server):
S: 220 mail.example.com Sample ESMTP MAIL Service, Version: 1.2
ready at Thu, 20 Jan 2005 11:24:40+0100
C: HELO [192.0.2.138]
S: 250 mail.example.com Hello [192.0.2.138]
C: MAIL FROM:<steve@example.org>
S: 250 2.1.0 steve@example.org....Sender OK
C: RCPT TO:<paul@example.com>
S: 250 2.1.5 paul@example.com
C: DATA
S: 354 Start mail input; end with "CRLF"."CRLF"
C: From: steve@example.org
C: To: sandra@example.com
C: Subject: Test
C:
C: Hi, this is a test!
C: .
S: 250 2.6.0 "MAIL0m4b1f@mail.example.com" Queued mail for
delivery
C: QUIT
S: 221 2.0.0 mail.example.com Service closing transmission channelSo the client (C:) is sending SMTP commands 📮 and the server (S:) is firing back responses. Every response starts with a status code and then some text 🎀. At minimum you need 4 commands to send an email, and all the commands and responses together for one email are what we call "the dialog" 🦋. The mail message body is whatever gets sent after the DATA command. An OPES processor could look at that and see it as command modification 👀.
If a callout service wants to adapt the email message body, it's mainly obsessed with this part 💅:
From: steve@example.org
To: sandra@example.com
Subject: Test
Hi, this is a test!The callout service might also need to look back at values from earlier commands in the same dialog 🕵️♀️. Like, it needs to check the RCPT value (it's paul@example.com), which is NOT the sandra@example.com the email client shows in the visible "To" field 😭. That's a huge deal for filters like spam filters (Section 4.2) 🚩.
4. OPES/SMTP Use Cases 🌸
honestly? basically all the filtering that gets deployed at SMTP gateways today and tomorrow counts as a use case for OPES callout filtering 💖. An OCP/SMTP callout protocol lets an SMTP gateway vector out (parts of) an SMTP message, or parts of the SMTP dialog, to a callout server that then does stuff on the gateway's behalf ✨. (OCP/SMTP would be a profile defined for OCP, kind of like the OCP/HTTP profile [4] that came before it 🧚.)
Here's a collection of some typical use cases, each describing a different filtering area and the different actions those filters trigger 🍓.
4.1. Security Filters Applied to Email Messages 🔐
these filters focus on the email message body and usually go through the email sections one by one 🔍. Email sections (attachments) that break the security policy (for example, because they contain a virus or an unwanted mime type) are an event that can kick off a combo of different actions 💀:
- The attachment is replaced by an error message.
- The email is marked by inserting a warning into the subject or the email body.
- An additional header is added for post-processing steps.
- The email storage is advised to put the email into quarantine.
- Notifications are sent to sender, recipients, and/or administrators.
- The incident is reported to other tools such as intrusion detection applications.
these kinds of filters usually don't need to touch anything in the SMTP dialog other than the email message body 🙈. The one exception is mapping email senders and recipients to different security sub-policies for a particular message. So a security filter might need the RCPT TO and MAIL FROM commands handed over as meta data along with the email body it's checking 🫶.
4.2. Spam Filter 🗑️
next to security filters, spam filters are probably the most wanted filtering app right now 🔥. Spam filters use several methods. They focus mostly on the email message body (which also includes the email headers), but a lot of them also care about the values of the other SMTP commands 👀, so they can compare the SMTP sender and recipients with the visible From/To fields. They might even want the source IP of the connected SMTP client as meta info, so they can check it against lists of open relays, known spammers, and so on 🕵️♀️.
these are typical actions that could be taken once a message has been classified as spam 🚫:
- Add a mark to the subject of the email.
- Add an additional header for post-processing steps.
- The email storage is advised to put the email into a spam queue.
- The email is rejected or returned to the sender.
4.3. Logging and Reporting Filters 📝
these filters aren't here to modify the email message 🙅♀️. Depending on what's being logged or reported, the filter might need access to any part of the SMTP dialog. The most wanted info is sender and recipient information 💌. Depending on how well the OPES processor can pre-calculate and transfer info about the message body, the callout filter might want the email message body itself, or just that meta info, like the email size 📏. This is typical logging and reporting info that's easy for the SMTP gateway to calculate, even though it isn't a direct parameter of the SMTP dialog ✨. Transferring the complete email message body just so the callout server can work out its size would be a total waste of network resources 😤.
4.4. Access Control Filters 🚪
these filters operate on the values of the MAIL FROM and RCPT TO commands in the SMTP dialog 💅. They run an access control policy to decide whether a sender is currently allowed to send a message to the given recipients. The values of HELO/EHLO, AUTH, and STARTTLS commands may also get applied. The result of this filter directly influences the SMTP response the OPES processor has to send to its peer for the filtered SMTP command 🫢.
4.5. Secure Email Handling 🔑
these filters can help an email gateway centrally encode and decode email, and set and verify email signatures 🦋. They modify the email message body to encrypt, decrypt, verify, or sign the message. They can also use an action as specified in the "Security Filter" (Section 4.1) section if decryption or signature verification fails 🚨.
Sending the SMTP sender and recipient info to these filters as meta data is mission critical 😭, because these filters may not trust the information in the header section of the email message body 🙅♀️.
4.6. Email Format Normalization 🧹
SMTP messages can be sent with an illegal or uncommon format 🤢. This might be a buggy SMTP application, or it might be on purpose, to exploit vulnerabilities in other products. A normalization filter can correct the email format ✨. The correction can be done for the email body and for the values of other SMTP commands. An example of a body format fix would be a weird length of UUencoded lines or unusual names of MIME sections 🎀. Command values can be analysed against buffer overflow exploits. A rewrite won't always be possible in this case (you can't simply rewrite an email address that's super long), so instead the callout server needs to tell the OPES processor to send an error response in reply to that command 💀.
4.7. Mail Rerouting and Address Rewriting 📬
a corporation with multiple locations might want a central gateway that receives all email messages for all employees, then figures out which location the employee's mail storage is at 🏢. The callout server will need the RCPT TO command value, and it'll look up the location in the corporate directory service 🔍. Then it either tells the OPES processor where the next SMTP server is (i.e., the next SMTP server to connect to), or it rewrites the recipient address 🪄. In the first case, the SMTP servers at the different locations accept emails for the same domain as the central gateway does. In the second case, the other locations will probably use the sublocation of the original domain (joe@example.org -> joe@fr.example.org or joe@de.example.org) 🌈.
4.8. Block Email during SMTP Dialog 🛑
in a first step, the callout server checks the sender and recipient info that was sent during the SMTP dialog 🕵️♀️. That info maps to a policy that will deny all messages from that sender or to that recipient. Or, it checks the body of the email and classifies it (maybe just by looking for some words in the subject, or by doing in-depth content analysis), which can also lead to denying the message 🙅♀️.
Unlike the earlier examples, this use case wants to deny the email while the SMTP dialog is still active, i.e., before the OPES processor finally accepts the message 😱. Depending on the exact policy, the error response should then be sent in reply to the MAIL FROM, RCPT TO, or DATA command 🚫.
4.9. Convert Attachments to HTTP Links 🔗
this use case only modifies the email message body and doesn't affect the SMTP dialogs, mail routing, or anything else 🧚. Larger sections (attachments) are removed from the email, and the content is stored on a web server 🌐. A link to that new URL is then added into the text of a first section that's likely to be displayed by an email client 💖. Storing the attachments on the web server is out of scope for the OPES/SMTP scenario, so the callout server needs to implement that part 🫶.
5. Security Considerations 🚨
Application-independent security considerations are documented in application-agnostic OPES specifications [5]. This document contains only use cases and defines no protocol operations. Security considerations for protocols that show up in these use cases are documented in the corresponding protocol specifications 📜.
⚠️ "Secure Email Handling" (Section 4.5) is the special one here 😭. It requires extending the end-to-end encryption model and handling private cryptographic keys securely when creating digital signatures or decrypting messages. Both of those are out of scope for OPES protocol specifications. Implementing a service like this raises security issues (such as the availability and storage of cryptographic keys) that must be addressed, whether the implementation lives inside an MTA or inside an OPES callout server 🔐.
6. References 📚
6.1. Normative References
[1] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004.
[2] Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H., and R. Penno, "Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios", RFC 3752, April 2004.
[3] Rousskov, A., "Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core", RFC 4037, March 2005.
[4] Rousskov, A. and M. Stecher, "HTTP Adaptation with Open Pluggable Edge Services (OPES)", RFC 4236, November 2005.
[5] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H. Orman, "Security Threats and Risks for Open Pluggable Edge Services (OPES)", RFC 3837, August 2004.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
Okay, bestie, now we're at the "for more reading" list 📚🎀 These are the extra references the document points to but doesn't depend on to work.
[7] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. 📮
[8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 🌐
[9] Crocker, D., "Internet Mail Architecture", Work in Progress, March 2005. 🧩
[10] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998. 💌
[11] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996. 🦋
Acknowledgements ✨
Huge thank-yous to everyone who helped with the use case examples, namely jfc and Markus Hofmann 🫶 Thanks also to everyone who joined the discussion and gave feedback on the OPES mailing list. You're all iconic 👑
Authors' Addresses 🖋️
Here are the authors' contact details, formatted exactly as they appear in the original:
Martin Stecher
Secure Computing Corporation
Vattmannstr. 3
33100 Paderborn
Germany
EMail: martin.stecher@webwasher.com
URI: http://www.securecomputing.com/
Abbie Barbir
Nortel
3500 Carling Avenue
Ottawa, Ontario
CA
Phone: +1 613 763 5229
EMail: abbieb@nortel.comFull Copyright Statement 💜
Legal time, but make it cute 🌸 This document is protected by the copyright of The Internet Society, and the 2006 copyright belongs to them.
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈
Intellectual Property 🔥
The IETF doesn't take a side on whether any intellectual property rights someone might claim over this technology are valid, how far they reach, or whether a license for them is available. It also doesn't say it has searched for those rights on its own. If you want the details on how rights work for RFC documents, look at BCP 78 and BCP 79 📖
Copies of IPR disclosures made to the IETF Secretariat, along with any assurances of licenses to be made available, or the results of any attempt to get a general license or permission to use such proprietary rights by implementers or users of this specification, can be found in the IETF online IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Send that information to the IETF at ietf-ipr@ietf.org 🦋
Acknowledgement 🌈
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 💖
📦 where this page comes from
- ietf: rfc4496 2006-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms