- Application Inspection and Control for SMTP
- Cisco IOS Firewall H.323 Support
- Cisco IOS Firewall Support for Skinny Local Traffic and CME
- H.323 RAS Support in Cisco IOS Firewall
- Cisco IOS Firewall: SIP Enhancements: ALG and AIC
- Subscription-based Cisco IOS Content Filtering
- Zone-Based Policy Firewall
- Finding Feature Information
- Contents
- Prerequisites for Application Inspection and Control for SMTP
- Restrictions for Application Inspection and Control for SMTP
- Information About Application Inspection and Control for SMTP
- How to Configure Application Inspection and Control for SMTP
- Configuring a Default Policy for Application Inspection
- Restricting Spam from a Suspicious E-Mail Sender Address or Domain
- Identifying and Restricting Spammers Searching for User Accounts in a Domain
- Restricting the Number of Invalid SMTP Recipients
- Specifying a Recipient Pattern to Learn Spam Senders and Domain Information
- Hiding Specified Private SMTP Commands on an SMTP Connection
- Preventing a DoS Attack by Limiting the Length of the SMTP Header
- Preventing a DoS Attack by Limiting the Length or TYPE of SMTP Command Line
- Restricting Content File Types in the Body of the E-Mail
- Restricting Unknown Content Encoding Types from Being Transmitted
- Specifying a Text String to Be Matched and Restricted in the Body of an E-Mail
- Configuring the Monitoring of Text Patterns in an SMTP E-Mail Subject Field
- Configuring a Parameter to Be Identified and Masked in the EHLO Server Reply
- Configuring a Logging Action for a Class Type in an SMTP Policy-Map
- Configuration Examples for Application Inspection and Control for SMTP
- Additional References
- Feature Information for Application Inspection and Control for SMTP
- Glossary
Application Inspection and Control for SMTP
The Application Inspection for SMTP feature provides an intense provisioning mechanism that can be configured to inspect packets on a granular level so that malicious network activity, related to the transfer of e-mail at the application level, can be identified and controlled. This feature qualifies the Cisco IOS firewall extended Simple Mail Transfer Protocol (ESMTP) module as an "SMTP application firewall," which protects in a similar way to that of an HTTP application firewall.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for Application Inspection and Control for SMTP" section.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for Application Inspection and Control for SMTP
•Restrictions for Application Inspection and Control for SMTP
•Information About Application Inspection and Control for SMTP
•How to Configure Application Inspection and Control for SMTP
•Configuration Examples for Application Inspection and Control for SMTP
•Feature Information for Application Inspection and Control for SMTP
Prerequisites for Application Inspection and Control for SMTP
Follow the appropriate configuration tasks outlined in the Zone-Based Policy Firewall module before configuring the Application Inspection and Control for SMTP feature. This module contains important information about class-maps and policy-maps and their associated "match" statements necessary for configuring an SMTP policy.
SMTP Policy Requirements
Both SMTP and ESMTP inspection provide a basic method for exchanging e-mail messages between the client and server to negotiate capabilities and use these capabilities in an e-mail transaction. An ESMTP session is similar to an SMTP session, except for one difference—the Extended HELO (EHLO) command. The EHLO command is sent by a client to initiate the capability dialogue. After the client receives a successful response to the EHLO command, the client works the same way as SMTP, except that the client may issue new extended commands, and it may add a few parameters to the MAIL FROM and REPT TO commands.
Previously, if the Cisco IOS software was configured to inspect SMTP session only, inspection was configured by entering the match protocol smtp command. This action would "mask" the EHLO command to prevent capability negotiation and cause the client to go back to the HELO command and basic SMTP.
To have a workable policy for both ESMTP and SMTP inspection, the match protocol smtp command must be configured in the top-level policy before the Application Inspection and Control for SMTP features are implemented. See the "Configuring a Default Policy for Application Inspection" section for more information.
The SMTP policy (which specifies the particular SMTP configuration) is included as a child-policy in the top-level "inspect" policy-map. See the "Top-level Class Maps and Policy Maps" section in the Zone-Based Policy Firewall module for more information.
Restrictions for Application Inspection and Control for SMTP
The Application Inspection and Control for SMTP feature has the following restrictions:
•The match cmd-line length gt command filter can co-exist only with a match cmd verb command filter in the SMTP match-all class -map (class-map type inspect smtp). Any attempt to pair the match cmd-line length gt command filter with any other filter is not allowed by the CLI.
•The alternative data transfer SMTP command extension BDAT is not supported. This command is substituted for the DATA command while the SMTP body is transferred. The BDAT command extension is used by the Cisco IOS firewall to mask the CHUNKING keyword in the EHLO response to the Application Inspection and Control for SMTP feature, preventing a client from using it.
•The "mask" action can be configured only with a class having either or both of the match cmd verb or match ehlo reply commands. This action cannot be configured with a class having any other filter.
Information About Application Inspection and Control for SMTP
The Application Inspection and Control for SMTP feature inspects SMTP in a granular way and is complemented by an intensive provisioning system to help filter e-mail.
•Benefits of Application Inspection and Control for SMTP
•Cisco Common Classification Policy Language
•Common Classification Engine SMTP Database and Action Module
Benefits of Application Inspection and Control for SMTP
The Application Inspection and Control for SMTP feature provides the following benefits:
•E-mail senders and user accounts are restricted to filter spam e-mail from suspected domains.
•An action can be specified, which occurs when a number of invalid recipients appears on an SMTP connection. This action helps identify spammers who are looking for valid user accounts.
•The number of invalid SMTP recipients can be restricted by specifying a maximum number for invalid recipients on an SMTP connection.
•A pattern can be specified that identifies e-mail addressed to a particular recipient or domain in cases where a server is functioning as a relay.
•A provisioning mechanism that provides masks specified verbs in an SMTP connection to block potentially dangerous SMTP commands.
•The maximum length value for the SMTP e-mail header can be specified to prevent a Denial of Service (DoS) attack (also called a buffer overflow attack). A DoS attack occurs when the attacker continuously sends a large number of incomplete IP fragments, causing the firewall to lose time and memory while trying to reassemble the fake packets.
•The maximum length of an SMTP command line can be specified to prevent a DoS attack.
•Multipurpose Internet Mail Extension (MIME) content file-types (text, HTML, images, applications, documents,and so on) can be restricted in the body of the e-mail from being transmitted over SMTP.
•Unknown content-encoding types can be restricted from being transmitted over SMTP.
•Specified content-types and content encoding types can be restricted in the SMTP e-mail body.
•Monitor arbitrary patterns (text strings) in the SMTP e-mail message header (subject field) or body.
•A parameter in an EHLO server reply and mask can be specified to prevent a sender (client) from using the service extension in the server reply.
•An SMTP connection can be dropped with an SMTP sender (client) if the SMTP connection violates the specified policy.
•SMTP commands or the parameters returned by the server in response to an EHLO command can be explicitly masked by specifying these SMTP commands.
•An action can be logged for a class type in an SMTP policy-map.
Cisco Common Classification Policy Language
The Cisco Common Classification Policy Language (C3PL) CLI structure is used to provision ESMTP inspection. ESMTP is provisioned by defining a match criterion on an SMTP class-map and associate actions to the match criterion defined in the SMTP policy-map. The Application Inspection and Control for SMTP feature adds new match criteria and actions to the existing SMTP policy maps that are discussed in the Zone-Based Policy Firewall module, which describes the Cisco IOS unidirectional firewall policy between groups of interfaces known as zones.
Figure 1 ESMTP Communication Between a Sender and Receiver
Common Classification Engine SMTP Database and Action Module
The Common Classification Engine (CCE) SMTP database is the site at which manually configured policy information is processed and converted into signatures. The information in these signatures is put into regular expression tables, which are then used to parse packets as they are switched by a router.
The SMTP database has two interfaces. One interface has the control plane, which is used to accept user configured policies, and the other interface has the CCE data-plane engine, which is used to classify a packet.
An action module is used as a part of the Context-Based Access Control (CBAC) SMTP inspection module to organize and trigger SMTP inspection. CBAC is used to detect and block SMTP attacks (illegal SMTP commands) and sends notifications when SMTP attacks occur.
How to Configure Application Inspection and Control for SMTP
•Configuring a Default Policy for Application Inspection
•Restricting Spam from a Suspicious E-Mail Sender Address or Domain
•Identifying and Restricting Spammers Searching for User Accounts in a Domain
•Restricting the Number of Invalid SMTP Recipients
•Specifying a Recipient Pattern to Learn Spam Senders and Domain Information
•Hiding Specified Private SMTP Commands on an SMTP Connection
•Preventing a DoS Attack by Limiting the Length of the SMTP Header
•Preventing a DoS Attack by Limiting the Length or TYPE of SMTP Command Line
•Restricting Content File Types in the Body of the E-Mail
•Restricting Unknown Content Encoding Types from Being Transmitted
•Specifying a Text String to Be Matched and Restricted in the Body of an E-Mail
•Configuring the Monitoring of Text Patterns in an SMTP E-Mail Subject Field
•Configuring a Parameter to Be Identified and Masked in the EHLO Server Reply
•Configuring a Logging Action for a Class Type in an SMTP Policy-Map
Configuring a Default Policy for Application Inspection
If no policy is configured for SMTP, then there is no application inspection for SMTP. The firewall creates a TCP session and only performs "pinholing," which allows an application to have access to the protected network. Having an open gap in a firewall can expose the protected system to malicious abuse. The steps below are used to provide minimum application inspection protections for SMTP by enforcing the EHLO and HELO SMTP commands.
SUMMARY STEPS
1. enable
2. configure terminal
3. class-map type inspect smtp class-map-name
4. match protocol smtp
DETAILED STEPS
Restricting Spam from a Suspicious E-Mail Sender Address or Domain
An e-mail sender and user accounts can be restricted to filter spam e-mail from suspected domains. Spam is restricted by using the match sender address regex command to match the parameter-map name of a specific traffic pattern that specifies a sender domain or e-mail address in the SMTP traffic. The specified pattern is scanned in the parameter for the SMTP MAIL FROM: command.
SUMMARY STEPS
1. enable
2. configure terminal
3. parameter-map type regex parameter-map-name
4. pattern traffic-pattern
5. exit
6. class-map type inspect smtp match-any class-map-name
7. match sender address regex parameter-map-name
8. exit
9. policy-map type inspect smtp policy-map-name
10. class type inspect smtp class-map-name
11. log
12. reset (optional)
DETAILED STEPS
Identifying and Restricting Spammers Searching for User Accounts in a Domain
Spammers who search for a large number of user accounts in a domain typically send the same e-mail to all the user accounts they find in this domain. Spammers can be identified and restricted from searching for user accounts in a domain by using the match recipient count gt command to specify an action that occurs when a number of invalid recipients appear on an SMTP connection.
Note The match recipient count gt command does not count the number of recipients specified in the To or Cc fields in the e-mail header.
SUMMARY STEPS
1. enable
2. configure terminal
3. class-map type inspect smtp class-map-name
4. match recipient count gt value
5. exit
6. policy-map type inspect smtp policy-map-name
7. class type inspect smtp class-map-name
8. reset
DETAILED STEPS
Restricting the Number of Invalid SMTP Recipients
If a sender specifies in an invalid e-mail recipient and SMTP encounters this invalid recipient on the SMTP connection, then SMTP sends an error code reply to the e-mail sender (client) to specify another recipient. In this case, the event did not violate the SMTP protocol or indicate that this particular SMTP connection is bad. However, if a pattern of invalid recipients appears, then a reasonable threshold can be set to restrict these nuisance SMTP connections. The match recipient invalid count gt command is used to help identify and restrict the number of invalid SMTP recipients that can appear in an e-mail from senders who try common names on a domain in the hope that they discover a valid username to whom they can send spam.
SUMMARY STEPS
1. enable
2. configure terminal
3. class-map type inspect smtp class-map-name
4. match recipient invalid count gt value
5. exit
6. policy-map type inspect smtp policy-map-name
7. class type inspect smtp class-map-name
8. reset
DETAILED STEPS
Specifying a Recipient Pattern to Learn Spam Senders and Domain Information
A nonexistent e-mail recipient pattern can be specified to learn about spam senders and their domain information by luring them to use this nonexistent e-mail recipient pattern. This pattern is a regular-expression (regex) that can be specified to identify an e-mail addressed to a particular recipient or domain when a server is functioning as a relay. The specified pattern is checked in the SMTP RCPT command (SMTP envelope) parameter to identify if the recipient is either used as an argument or a source-list to forward mail in the route specified in the list.
Note The match recipient address regex command does not operate on the To or Cc fields in the e-mail header.
SUMMARY STEPS
1. enable
2. configure terminal
3. parameter-map type regex parameter-map-name
4. pattern traffic-pattern
5. exit
6. class-map type inspect smtp class-map-name
7. match recipient address regex parameter-map-name
8. exit
9. policy-map type inspect smtp policy-map-name
10. class type inspect smtp class-map-name
11. log
12. reset
DETAILED STEPS
Hiding Specified Private SMTP Commands on an SMTP Connection
Use this task to hide or "mask" commonly encountered SMTP verbs (SMTP commands) or specified private SMTP verbs used to provision an SMTP connection.
Specified verbs, such as the ATRN, ETRN, BDAT verbs may be considered vulnerable to exploitation if seen by a sender (client). The most commonly encountered SMTP verbs are listed along with the facility to specify a private verb as a string (using the WORD option).
Note The BDAT verb (used as an alternative to DATA) is not used, so in its place, the CHUNKING keyword is masked in the EHLO response. However, if the sender (client) continues to send the BDAT command, it is masked.
Note Using the mask command applies to certain match command filters like match cmd verb. Validations are performed to make this check and the configuration is not be accepted in case of invalid combinations.
SUMMARY STEPS
1. enable
2. configure terminal
3. class-map type inspect smtp class-map-name
4. match cmd verb {verb-name | WORD}
5. exit
6. policy-map type inspect smtp policy-map-name
7. class type inspect smtp class-map-name
8. mask
DETAILED STEPS
Preventing a DoS Attack by Limiting the Length of the SMTP Header
A DoS attack (also called a buffer overflow attack) by a malicious sender (client) can cause the SMTP application firewall to lose time and memory while trying to reassemble the fake packets (large e-mail headers) associated with the e-mail. In an SMTP transaction, the header portion of an e-mail is considered part of the DATA area, which contains fields like Subject, From, To, Cc, Date, and proprietary information, which is used by a recipient's e-mail agent to process the e-mail. A DoS attack can be prevented by using the match header length gt command to limit the length of the SMTP header that can be received. If a match is found, possible actions that can be specified within the policy are as follows: allow, reset, or log (the log action triggers a syslog message when a match is found).
SUMMARY STEPS
1. enable
2. configure terminal
3. class-map type inspect smtp class-map-name
4. match header length gt bytes
5. exit
6. policy-map type inspect smtp policy-map-name
7. class type inspect smtp class-map-name
8. reset
DETAILED STEPS
Preventing a DoS Attack by Limiting the Length or TYPE of SMTP Command Line
The following task is used to limit the length of an SMTP command line to prevent a DoS attack, which occurs when a malicious sender (client) specifies large command lines in an e-mail to perform DoS attacks on SMTP servers.
SUMMARY STEPS
1. enable
2. configure terminal
3. class-map type inspect smtp {class-map-name | match-all class-map-name | match-any class-map-name}
4. match cmd {line length gt length | verb {AUTH | DATA | EHLO | ETRN | EXPN | HELO | HELP | MAIL NOOP | QUIT | RCPT | RSET | SAML | SEND | SOML | STARTTLS | VERB | VRFY | WORD}}
5. exit
6. policy-map type inspect smtp policy-map-name
7. class type inspect smtp class-map-name
8. reset
DETAILED STEPS
Examples
The following configuration has class-map c2 match when the length of the e-mail (MAIL) command exceeds 256 bytes.
When the class-map type inspect smtp match-all command statement is configured with the match cmd verb command statement, only the match cmd line length gt command statement can coexist.
class-map type inspect smtp match-all c2
match cmd line length gt 256
match cmd verb MAIL
There are no match restrictions in case of a class-map type inspect smtp match-any command statement for a class map because the class-map applies to all SMTP commands.
Restricting Content File Types in the Body of the E-Mail
The match mime content-type regex command is used to specify MIME content file types, which are restricted in attachments in the body of the e-mail being sent over SMTP. See the "Example: MIME E-Mail Format" section for more information.
SUMMARY STEPS
1. enable
2. configure terminal
3. parameter-map type regex parameter-map-name
4. pattern traffic-pattern
5. exit
6. class-map type inspect smtp {class-map-name | match-all class-map-name | match-any class-map-name}
7. match mime content-type regex content-type-regex
8. exit
9. policy-map type inspect smtp policy-map-name
10. class type inspect smtp class-map-name
11. log
DETAILED STEPS
Restricting Unknown Content Encoding Types from Being Transmitted
Unknown MIME content-encoding types or values can be restricted from being transmitted over SMTP by using one of the following parameters with the match mime encoding command.
These preconfigured content-transfer-encoding types act as a filter on the content-transfer-encoding field in the MIME header within the SMTP body. The uuencode encoding type is not recognized as a standard type by the MIME RFCs because many subtle differences exist in its various implementations. However, since it is used by some mail systems, the x-uuencode type is included in the preconfigured list.
SUMMARY STEPS
1. enable
2. configure terminal
3. class-map type inspect smtp {class-map-name | match-all class-map-name | match-any class-map-name}
4. match mime encoding {unknown | WORD | encoding-type}
5. exit
6. policy-map type inspect smtp policy-map-name
7. class type inspect smtp class-map-name
8. log
DETAILED STEPS
Specifying a Text String to Be Matched and Restricted in the Body of an E-Mail
The match body regex command can be used to specify an arbitrary text expression to restrict specified content-types and content encoding types for text and HTML in the body of the e-mail. The text or HTML pattern is scanned only if the encoding is 7-bit or 8-bit and the encoding is checked before attempting to match the pattern. If the pattern is of another encoding type (for example, base64, zip files, and so on), then the pattern cannot be scanned.
Note Using this command can impact performance because the complete SMTP connection has to be scanned.
SUMMARY STEPS
1. enable
2. configure terminal
3. parameter-map type regex parameter-map-name
4. pattern traffic-pattern
5. exit
6. class-map type inspect smtp {class-map-name | match-all class-map-name | match-any class-map-name}
7. match body regex parameter-map-name
8. exit
9. policy-map type inspect smtp policy-map-name
10. class type inspect smtp class-map-name
11. log
DETAILED STEPS
Configuring the Monitoring of Text Patterns in an SMTP E-Mail Subject Field
The match header regex command can be used specify an arbitrary text expression in the SMTP e-mail message header (Subject field) or e-mail body such as Subject, Received, To, or other private header fields to monitor text patterns.
SUMMARY STEPS
1. enable
2. configure terminal
3. parameter-map type regex parameter-map-name
4. pattern traffic-pattern
5. exit
6. class-map type inspect smtp {class-map-name | match-all class-map-name | match-any class-map-name}
7. match header regex parameter-map-name
8. exit
9. policy-map type inspect smtp policy-map-name
10. class type inspect smtp class-map-name
11. reset
DETAILED STEPS
Configuring a Parameter to Be Identified and Masked in the EHLO Server Reply
The match reply ehlo command is used to identify and mask a service extension parameter in the EHLO server reply (for example, 8BITMIME and ETRN) to prevent a sender (client) from using that particular service extension.
SUMMARY STEPS
1. enable
2. configure terminal
3. class-map type inspect smtp {class-map-name | match-all class-map-name | match-any class-map-name}
4. match reply ehlo {parameter | WORD}
5. exit
6. policy-map type inspect smtp policy-map-name
7. class type inspect smtp class-map-name
8. log
9. mask
DETAILED STEPS
Configuring a Logging Action for a Class Type in an SMTP Policy-Map
A logging action can be configured for a class type in an SMTP policy-map when conditions specified by the traffic class are met. The logging action results in a LOG_WARNING syslog message followed by the specific log message. The log message format is similar to other application firewall modules (for example, HTTP, IM, Peer-to-Peer (P2P)); session initiator/responder information, and zone-pair and class names.
Note The log action currently exists for other types of policy-maps (http, pop3).
SUMMARY STEPS
1. enable
2. configure terminal
3. class-map type inspect smtp {class-map-name | match-all class-map-name | match-any class-map-name}
4. match cmd verb {parameter | WORD}
5. exit
6. policy-map type inspect smtp policy-map-name
7. class type inspect smtp class-map-name
8. log
DETAILED STEPS
Configuration Examples for Application Inspection and Control for SMTP
•Example: Creating a Pinhole for the SMTP Port
•Example: Preventing ESMTP Inspection
Example: Creating a Pinhole for the SMTP Port
The following example shows a configuration without any Layer 7 SMTP policy that creates a pinhole only for the SMTP port. Any command sent to the server, including the EHLO command is accepted.
class-map type inspect smtp c1
match protocol smtp
policy-map type inspect smtp c1
class type inspect smtp c1
inspect
Note No SMTP policy is configured by default. If an SMTP policy is not configured, then no SMTP inspection is done by default.
Example: Preventing ESMTP Inspection
If a user decides to create a workable policy that is configured for SMTP inspection only, then it now needs to be explicitly specified in the policy.
The following example can be used to prevent ESMTP inspection:
class-map type inspect smtp c1
match cmd verb EHLO
policy-map type inspect smtp c1
class type inspect smtp c1
mask
Example: MIME E-Mail Format
The format of data being transmitted through SMTP is specified by using the MIME standard, which uses headers to specify the content-type, encoding, and the filenames of data being sent (text, html, images, applications, documents and so on). The following is an example of an e-mail using the MIME format:
From: "username2" <username2@example.com>
To: username3 <username3@example.com>
Subject: testmail
Date: Sat, 7 Jan 2006 20:18:47 -0400
Message-ID: <000dadf7453e$bee1bb00$8a22f340@oemcomputer>
MIME-Version: 1.0
Content-Type: image/jpeg;
name='picture.jpg'
Content-Transfer-Encoding: base64
<base64 encoded data for the picture.jpg image>
In the above example, the "name='picture.jpg'" is optional. Even without the definition, the image is sent to the recipient. The e-mail client of the recipient may display the image as "part-1" or "attach-1" or it may render the image in-line. Also, attachments are not `stripped' from the e-mail. If a content-type for which reset action was configured is detected, an 5XX error code is sent and the connection is closed, in order to prevent the whole e-mail from being delivered. However, the remainder of the e-mail message is sent.
Additional References
Related Documents
|
|
|
|---|---|
Cisco IOS commands |
|
Firewall commands |
|
ESMTP firewall information. |
|
Information for configuring an SMTP policy. |
Standards
|
|
|
|---|---|
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature. |
— |
MIBs
RFCs
|
|
|
|---|---|
RFC 1869 and other SMTP RFC extensions apart from RFC 821. |
SMTP Service Extensions |
Technical Assistance
Feature Information for Application Inspection and Control for SMTP
Table 1 lists the features in this module and provides links to specific configuration information.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note Table 1 lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Glossary
C3PL—Cisco Common Classification Policy Language. Structured, feature-specific configuration commands that use policy maps and class maps to create traffic policies based on events, conditions, and actions.
EHLO—Extended HELO substitute command for starting the capability negotiation. This command identifies the sender (client) connecting to the remote SMTP server by using the ESMTP protocol.
ESMTP—Extended Simple Mail Transfer Protocol. Extended version of the Simple Mail Transfer Protocol (SMTP), which includes additional functionality, such as delivery notification and session delivery. ESMTP is described in RFC 1869, SMTP Service Extensions.
HELO—Command that starts the SMTP capability negotiation. This command identifies the sender (client) connecting to the remote SMTP server by its fully qualified DNS hostname.
MAIL FROM —Start of an e-mail message that identifies the sender e-mail address (and name, if used), which appears in the From: field of the message.
MIME—Multipurpose Internet Mail Extension. Standard for transmitting nontext data (or data that cannot be represented in plain ASCII code) in e-mail, such as binary, foreign language text (such as Russian or Chinese), audio, or video data. MIME is defined in RFC 2045.
RCPT TO—Recipient e-mail address (and name, if used) that can be repeated multiple times for a likely message to deliver a single message to multiple recipients.
SMTP—Simple Mail Transfer Protocol. Internet protocol providing e-mail services.
Feedback