Symantec™ Security Gateways Reference Guide - Sawmill

58 Understanding accessProxiesThe SMTP proxyWhile the RTSP protocol is intentionally similar in syntax and operation to HTTP, an RTSP server needs tomaintain state by default in almost all cases, as opposed to the stateless nature of HTTP.The SMTP proxy supports transparent, bi-directional access for email connections through the securitygateway. Like other security gateway proxies, the SMTP proxy accepts or rejects delivery of email on aconnection-by-connection basis, subject to the existence of authorization rules. You can configure theSMTP proxy to check each email connection and scan for known email-based forms of attack.The SMTP proxy, however, is not a full-fledged mail system and does not store email. If you operate aninternal SMTP server, it is recommended that you configure this internal server to resolve external SMTPservers through DNS, and that you set its default route to pass through the security gateway. All that isrequired then is to create a rule to allow the traffic, letting the internal SMTP server access any SMTPservers. If you are unable to set your internal SMTP server’s default gateway to the nearest securitygateway interface, possibly due to an internal routing situation, be careful not to point to the securitygateway for any store-and-forward operations.You can also redirect internal requests to an external server by pointing the internal SMTP server to thenearest interface of the security gateway, creating a service redirect on the security gateway, and creating arule to allow the traffic. However, this approach has the drawback that if the external SMTP server fails,mail is not delivered, and more importantly, is not spooled.Note: Because the SMTP proxy does not store email, the security gateway itself is not vulnerable to emailbasedattacks.Supported commandsMost mail servers use a series of four-letter commands to send and receive email. Table 4-4 shows thesupported SMTP and ESMTP commands by the Symantec SMTP proxy.Table 4-4CommandHELOMAILRCPTDATARSETNOOPVRFYEXPNQUITSupported SMTP commandsDescriptionIdentifies the SMTP client to the SMTP server. The argument field contains the fully-qualified domainname, if one is available. This command announces that the SMTP client supports the regular SMTPcommand set.Initiates a mail transaction in which mail is delivered from the SMTP client to the SMTP server. Theargument field contains a reverse path and may contain optional parameters if ESMTP is supported.Identifies an individual recipient’s data; multiple recipients in a mail header are addressed with multipleuses of this command. The argument field contains a forward path and may contain optional parameters.Tells the SMTP recipient that what follows is data or the message body. The recipient looks for a line withonly a period on it as the signal that the data has ended.Aborts the current mail transaction. There are no arguments for this command.Specifies no action other than that the receiver should send an OK reply. Does not affect any parametersor previously entered commands.Asks the receiver to confirm that the argument identifies a user or mailbox. This command has no affecton the reverse-path buffer, forward-path buffer, or the mail-data buffer.Asks the receiver to confirm that the argument identifies a mailing list, and if so, to return membershipof that list. This command has no affect on the reverse-path buffer, forward-path buffer, or the mail-databuffer.Specifies that the receiver must send an OK reply, and then close the transmission channel.