Collection: Exchange 2007 Mail Transport Query (2)

Troubleshooting Edge Transport Server Queues That Contain Mail Destined to a Hub Transport Server

This topic explains how to resolve issues where messages queue on a Microsoft Exchange Server 2007 Edge Transport server that are destined for delivery to an internal Exchange Hub Transport server. In the Queue Viewer, these messages display the error message 451 5.7.3 "Cannot achieve Exchange Server authentication".

This issue occurs when both Transport Layer Security (TLS) and Exchange Server Authentication are not configured on the default Receive connector of the receiving Exchange Hub Transport server. Therefore, you can resolve this issue by enabling TLS and Exchange Server Authentication on the default Receive connector.

   Procedure

 To use the Exchange Management Console to configure authentication to allow an Edge server to transfer mail to Exchange Hub Transport servers

1. Open the Exchange Management Console and navigate to Server Configuration\Hub Transport.
2. Select the default Receive connector for the Hub Transport server that you want to configure to receive mail from the Edge Transport server.
3. Right-click the default Receive connector, and then select Properties.
4. Select the Authentication tab.
5. Check the Transport Layer Security (TLS) check box.
6. Check the Exchange Server authentication check box.
7. Click Apply.
8. Click OK.
9. Force EdgeSync synchronization

Event Similar to Event ID 9514 May Be Logged in the Application Log

This topic explains how to use the Active Directory Service Interfaces (ADSI) Edit snap-in to change the proxy address of one of the objects specified in Event ID 9514.

An event that resembles the following event may be logged in the Application log on a computer that is running Microsoft Exchange Server 2007:

Event Type: Warning Event Source: MSExchangeIS Event Category: General Event ID: 9514 Computer: Exchange_Server_Name Description: Two objects in the directory have the same proxy - dc=com/dc=domain/ou=OU_Name/cn=Object1 and dc=com/dc=domain/ou=OU_Name//cn=Object2

You may receive this warning if you have two identical proxy addresses in your organization. This issue may occur if one or more objects are updated simultaneously from different management consoles that connect to different domain controllers. Additionally, mail flow to the objects that are specified in the event description may be disrupted.

 Resolution

To resolve this issue, use ADSI Edit to change the proxy address of one of the objects specified in the event description.

 Before You Begin

To perform this procedure, the account you use must be delegated the following:

• Exchange Organization Administrator role and local Administrators group for the target server

ADSI Edit can be run from a client computer or server. The computer does not have to be a member of a domain, but the user must have the rights to view and edit the Active Directory directory service domain to which the user is connecting.

Important:

If you use ADSI Edit or any other Lightweight Directory Access Protocol (LDAP) version 3 client, and you incorrectly modify the attributes of Active Directory objects, serious problems may occur. These problems may require you to reinstall Windows Server 2003, Microsoft Exchange 2007, or both Windows Server 2003 and Exchange 2007. Microsoft cannot guarantee that problems that occur if you incorrectly modify Active Directory object attributes can be solved. Modify these attributes at your own risk.

 Procedure

 To use ADSI Edit to change the proxy address of one of the objects specified in the event description

1. Install ADSI Edit.
2. Launch ADSI Edit. Click Start, click Run, type adsiedit.msc in the text box, and then click OK.
3. Expand Domain, expand DC=Domain_Name,DC=Domain, and then expand the organizational unit (OU) container that contains the user object that is specified in the event description.
4. Right-click the user object, and then click Properties.
5. On the Attribute Editor tab, click proxyAddress in the Attributes list, and then click Edit.
6. In the Value to add box, type a unique Simple Mail Transfer Protocol (SMTP) address for the user object, click Add, and then click OK.
7. Click OK, and then close ADSI Edit.

How to Export E-Mail Messages from a Queue to Replay Them Later in Exchange 2007

This topic describes how to use the Exchange Management Shell in Microsoft Exchange Server 2007 to export e-mail messages from a message queue.

You may experience a situation in which an Exchange server that is configured as an open relay has been used to send unsolicited commercial e-mail (UCE), also known as spam, to the Internet. In this scenario, you may have to deal with the following issues:

• You have a message queue that is filled with legitimate e-mail messages together with hundreds, thousands, or even hundreds of thousands of spam messages.
• You cannot continue typical operations because the server will forward the spam messages to the Internet.
• You must clear the message queues so that you can restore e-mail functionality to your organization as quickly as possible.
• You must retain the e-mail messages from the queues so that you can later replay legitimate e-mail messages back into your messaging environment.

This topic is intended to help address these issues.

 Before You Begin

To perform the following procedures, the account you use must be delegated the following:

• Exchange Server Administrator role and local Administrators group for the server

Additionally, there are certain things to consider when you perform the procedures that are described in this document.

• You can export messages from the Exchange queues for later playback into Exchange. However, you cannot export messages from the Submission queue. To work around this issue, you can pause the Microsoft Exchange Transport service. This action allows the Submission queue to empty. However, depending on how many messages are queued, emptying the Submission queue could take a long time.
• The procedure to extract legitimate e-mail messages from the message queue assumes that most of the spam messages are not addressed to recipients in your organization or are not from recipients in your organization. Therefore, the filters that are used to extract the messages are based on the domain or domains that your organization hosts. If spam messages are directed to or from your domains, you will export some spam messages together with legitimate e-mail messages.

 Procedures

To export e-mail messages from the Exchange 2007 queues, follow these general steps. (Each of these general steps is described in more detail later in this topic.)

1. Pause the Microsoft Exchange Transport service.
2. Suspend, and then export legitimate e-mail messages. To do this, use the following command:
   

Get-Message <filter> | Suspend-Message | Export-Message -path <path>

3. Stop the Microsoft Exchange Transport service.
4. Rename the Queue folder.
5. Start the Microsoft Exchange Transport service.
6. Copy the exported messages into the Replay folder.

To pause the Microsoft Exchange Transport service

1. Click Start, click Run, type services.msc, and then click OK.
2. In the Services MMC snap-in, click Microsoft Exchange Transport, and then click Pause.
3. Start the Exchange Management Console, and then click Toolbox.
4. Under Mail Flow Tools, double-click Queue Viewer.
5. Click the Queues tab, and then note the value that appears in the Message Count column for the Submission queue.
6. Allow sufficient time for the message count to reach zero (0).

To suspend and then export legitimate e-mail messages

1. Use Windows Explorer to create a destination folder for the exported e-mail messages. This folder must be created before you can export the messages successfully. The folder may be on a local hard disk drive or on a shared network drive.
2. Start the Exchange Management Shell.
3. At the shell prompt, export messages that have your domain specified in the From field. To do this, run the following command:

Get-Message | where{$_.FromAddress -like "*@contoso.com"} | Suspend-Message | Export-Message -path <path>

In this command, replace contoso.com with the appropriate domain and replace <path> with the path to which you want to export the messages, such as c:\export.

4. At the shell prompt, export messages that have your domain specified in the To field. To do this, run the following command:

Get-Message -IncludeRecipientInfo | where{$_.Recipients -like "*@contoso.com"} | Suspend-Message | Export-Message -path <path>

5. Follow steps 2 through 3 for each domain for which your organization handles e-mail.

To stop the Microsoft Exchange Transport service

1. Click Start, click Run, type services.msc, and then click OK.
2. In the Services MMC snap-in, click Microsoft Exchange Transport, and then click Stop.

To rename the Queue folder

1. Start Windows Explorer, and then locate the Queue folder. By default, this folder has the following path:

C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue

2. Right-click Queue, and then click Rename. Use a descriptive name, such as spam-Queue, to rename the folder.
3. Start the Microsoft Exchange Transport service. The Microsoft Exchange Transport service automatically creates a new Queue folder together with the following files:
• mail.que
• tmp.edb
• trn.chk
• trn
• trnres00001.jrs
• trnres00002.jrs
• trntmp

Mail flow should now be successfully restored in the organization.

To replay the exported messages

1. Use Windows Explorer to locate the Replay folder. By default, this folder has the following path:

C:\Program Files\Microsoft\Exchange Server\TransportRoles\Replay

2. Copy the messages that you exported earlier to the Replay folder.

Incoming Messages to Edge Server Fail with 550 5.7.1 NDR

This topic explains how to resolve issues related to inbound messages not being delivered from external domains to a server that is running Microsoft Exchange Server 2007 with the Edge Transport server role installed. Inbound e-mail messages are rejected with a non-delivery report (NDR) similar to the following being returned to the sender:

• postmaster@domain.com
  ftr-van-exfe.domain.com #550 5.7.1 External client does not have permissions to submit to this server ##

This issue commonly occurs when the Edge Transport server role is deployed in a perimeter network configuration and the Internet Protocol (IP) address of the internal firewall is blocked by the Edge Transport server. This issue can also occur in a non-perimeter network scenario if one or more Hub Transport server IP addresses are blocked by the Edge Transport server.

You can confirm that this situation is occurring by running the Get-IPBlockListEntry cmdlet on the Edge Transport server and then examining the output for the IP address of the internal SMTP server or the internal firewall's IP address. Then, you can resolve this issue by modifying the internal SMTP servers list and then removing the blocked IP from the IP block entry list.

 Before You Begin

To perform this procedure, the account you use must be delegated the following:

• Membership in the local Administrators group
• Exchange Organization Administrator role

For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007, see Permission Considerations.

 Procedure

 To use the Exchange Management Shell to identify blocked IP addresses and modify the internal SMTP servers list on an Edge server

1. Start the Exchange Management Shell.
2. Run the Get-IPBlockListEntry cmdlet and then locate the IP address of the internal SMTP server or internal firewall's IP address that is being blocked. Note the line number of the blocked IP.
3. Run the Set-TransportConfig cmdlet as follows:

set-TransportConfig -InternalSMTPServers <IP address of Hub Transport server to be added>

4. Run the Start-EdgeSynchronization cmdlet to force replication.
5. Confirm that the Hub Transport server IP address you added has been replicated by running the Get-TransportConfig cmdlet.
6. Inspect the Get-TransportConfig output and confirm that the IP address you added in step 3 is shown.
7. Run the Remove-IPBlockListEntry cmdlet as follows:

Remove-IPblockListEntry -Identity <line #>

Note:

Replace <line #> with the line number that you noted in step 2 identifying the blocked IP address when Get-IPBlockListEntry was run.

8. Send a test message to confirm that message traffic is flowing correctly.

Using Pipeline Tracing to Diagnose Transport Agent Problems

Pipeline tracing is a diagnostic feature in Microsoft Exchange Server 2007 that enables you to capture diagnostic information about e-mail messages as they encounter transport agents registered on Simple Mail Transfer Protocol (SMTP) events in the transport pipeline. Exchange captures verbose information about the changes that each transport agent applies to messages in the transport pipeline in message snapshot files. If transport rules are configured, Exchange Server also records any actions that each transport rule takes on these messages.

Pipeline tracing is configured per server in your organization and can be enabled on computers that have the Hub Transport server role and the Edge Transport server role installed.

When you enable pipeline tracing and use the default location of the pipeline tracing log file, the C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing is created. This directory contains the MessageSnapshots directory and the RulesTracking directory.

 Implementing Pipeline Tracing

Pipeline tracing is designed to log messages that are sent only from a specific sender's SMTP e-mail address. The sender's SMTP address can be a mailbox that is inside or outside your Exchange organization. Before you enable pipeline tracing, you must specify a sender SMTP address for pipeline tracing. You can configure the sender SMTP address for pipeline tracing by using the PipelineTracingSenderAddress parameter on the Set-TransportServer cmdlet.

After you configure the sender SMTP address for pipeline tracing, you can modify the location of the pipeline tracing log files if you want. You must put the pipeline tracing log files on the local computer. You can't use Universal Naming Convention (UNC) file paths or mapped drives.

Caution:

Pipeline tracing copies the complete contents of e-mail messages that are sent from the sender's e-mail address. To avoid unwanted exposure of confidential information, you must set appropriate security permissions on the location of the pipeline tracing log file.

Caution:

Do not enable pipeline tracing for long periods of time. Pipeline tracing creates verbose log files that can accumulate quickly. Always monitor available disk space when pipeline tracing is enabled.

You can configure the location of the pipeline tracing log files by using the PipelineTracingPath parameter on the Set-TransportServer cmdlet. For more information, see Set-TransportServer.

For more information about how to enable pipeline tracing and configure the sender address for pipeline tracing, see How to Enable Pipeline Tracing.

 Message Snapshot Files

Message snapshots are files that capture the exact changes, if any, transport agents make to a message. By examining the contents of the message snapshot files, you can determine whether the transport agents have applied the changes to the messages in the transport pipeline that you expected. If you are troubleshooting a problem, you should determine which transport agent is at fault. Then you can focus your troubleshooting efforts on that agent to resolve the problem. You can then view the message snapshot files again to verify that your solution is successful.

In the MessageSnapshots directory, Exchange creates one directory for each message that flows through the transport pipeline when pipeline tracing is enabled. Each directory is created by using the GUID that is assigned to the message as the directory name by the computer that is running Microsoft Exchange. If pipeline tracing is enabled on more than one Exchange server, a different GUID is assigned to the message on each Exchange server.

In each message directory, Exchange creates several message snapshot files that have .eml extensions. These message snapshot files contain the contents of the message as it encounters each event and transport agent.

Exchange creates message snapshots for agents that are registered on the four following events:

• OnEndofData
• OnEndOfHeaders
• OnSubmittedMessage
• OnRoutedMessage

If a transport agent is registered to an event, Exchange creates a message snapshot of the message before the message encounters any transport agents. This gives you a copy of the message before the message encounters transport agents that are registered on that event. Then, a new message snapshot is created for each transport agent that the message encounters, regardless of whether a transport agent modifies the contents of the message. However, if no agents are registered on an event, Exchange doesn't create any messages snapshots for that event.

For example, if three agents are registered on the OnEndofData event but only two of the transport agents modify a message, four message snapshots are created. The first message snapshot captures the message as it encounters the OnEndofData event before any modifications that are made by the transport agents that registered on that event. Then, one message snapshot is created for each transport agent regardless of whether a transport agent modifies the message.

The following list is an example of the files that can be created in a default installation of an Edge Transport server role:

• Original.eml   This file contains the original unmodified contents of the e-mail message before it encounters any events or transport agents. If no transport agents are configured on any events, only this file is created.
• SmtpReceive0001.eml to SmtpReceive0009.eml   These files contain the contents of the e-mail message as it encounters the OnEndofData and OnEndOfHeaders events and transport agents that are registered on those events in the SMTP receive part of the transport pipeline.
• Routing0001.eml and Routing0002.eml   These files contain the contents of the e-mail message as it encounters transport the OnSubmittedMessage and OnRoutedMessage events and transport agents that are registered on those events in the categorization part of the transport pipeline.

You can open the message snapshot files by using a text editor, such as Notepad.

Each message snapshot file starts with headers that are added to the message contents and list the SMTP event and transport agent that the message snapshot file relates to. These headers start with X-CreatedBy: MessageSnapshot-Begin injected headers and end with X-EndOfInjectedXHeaders: MessageSnapshot-End injected headers. These headers are replaced in each message snapshot file by each subsequent transport agent. The following is an example of the headers that are added to an e-mail message that is processed by the Connection Filter agent on the OnEndOfHeaders event:

X-CreatedBy: MessageSnapshot-Begin injected headers

X-MessageSnapshot-UTC-Time: 2006-07-31T23:18:55.972Z

X-MessageSnapshot-Protocol-Id: 08C87FF14CCC969C;2006-07-31T23:18:53.408Z;1

X-MessageSnapshot-Source: OnEndOfHeaders,Connection Filtering Agent

X-Sender: david@nwtraders.com

X-Receiver: chris@contoso.com

X-EndOfInjectedXHeaders: MessageSnapshot-End injected headers

Underneath the message snapshot headers are the contents of the message including all the original message headers. If a transport agent modifies the contents of the message, the changes appear integrated with the message. As the message is processed by each transport agent, the changes that are made by each agent are applied to the message contents. If a transport agent makes no changes to the message contents, the message snapshot that is created by that agent will be identical to the message snapshot created by the previous transport agent.

 Reading the Rules Tracking Files

The rules tracking file captures the result of each transport rule as it is applied to a message that encounters the Transport Rules agent on a Hub Transport server or Edge Rules agent on an Edge Transport server. The results that are captured by the rules tracking file indicate whether a transport rule took an action against a message. If the transport rule took an action, the rules tracking file indicates what action was taken. The rules tracking file contains the following fields in the comma-separated value (.csv) format:

• Date-Time   This field indicates the date and time that the transport rule was run in coordinated Universal Time (UTC), or Zulu time.
• Message-Id   This field indicates the value of the MessageID: field that is located in the message header. This value is constant for the lifetime of the message and can be used with message tracking logs to track a message's path through an Exchange organization.
• Rule-Name   This field indicates the name of the transport rule run against the message.
• Details   This field indicates the values of the transport rule action applied to a message. If multiple values are set on a single transport rule action, the values are separated by semi-colons (;). If the transport rule isn't applied to a message, the string Conditions evaluated to false. Rule skipped. is inserted.
• Action   This field indicates the transport rule action that is applied to a message. If the transport rule isn't applied to a message, the string NoAction is inserted.
• From-Address   This field indicates the SMTP address of the sender of the message.
• Recipient-Address   This field indicates the SMTP address of the recipient or recipients of the message. If the transport rule action is applied to a message sent to multiple recipients that match the transport rule conditions, the recipients are separated by semi-colons (;).

Each transport rule action that is applied to a message is written to a separate line in the rules tracking file. For example, if a transport rule has three actions, the result of each transport rule action is written to a separate line in the rules tracking file.

If more than one recipient is included on an e-mail message, but not all recipients meet all the transport rule conditions, the recipients that don't meet the transport rule conditions are separated out and written to a separate line.

Troubleshooting the Microsoft Exchange Transport Service When It Fails to Start on an Exchange 2007 Hub Transport Server with Event ID 1032 or 1036

This topic provides information about how to troubleshoot the Microsoft Exchange Transport service if it fails to start on a Microsoft Exchange Server 2007 Hub Transport server with Event ID 1032 or 1036.

If this error occurs, event log errors are generated with the following information:

Event ID: 1032 Event Source: MSExchange TransportService Event Type: Error Description: Socket Access Denied. Binding: 0.0.0.0:25.

Event ID: 1036 Event Source: MSExchange TransportService Event Type: Error Description: Failed to open one or more bindings. The service will be stopped.

This issue occurs when the Internet Information Services (IIS) Simple Mail Transfer Protocol (SMTP) service has been installed on the server and is running.

 Resolution

To resolve the problem, remove the SMTP service.

 Before You Begin

To perform this procedure, the account you use must be delegated the following:

• Membership in the local Administrators group

For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007, see Permission Considerations.

 Procedure

 To remove the SMTP service

1. On the Exchange 2007 Hub Transport server, open Control Panel and click Add or Remove Programs.
2. Click Add\Remove Windows Components.
3. Select Application Server, and then select Internet Information Services (IIS).
4. Clear the SMTP Service option.
5. Click OK to accept changes and close Control Panel.
6. Restart the Microsoft Exchange Transport service.

You Cannot Send or Receive E-Mail Messages Behind a Cisco PIX Firewall

This topic provides information about how to troubleshoot the following mail flow issues when Microsoft Exchange is located behind a Cisco PIX firewall device:

• You cannot receive Internet-based e-mail messages.
• You cannot send e-mail messages that have attachments.
• You cannot establish a telnet session with the Exchange server on port 25.
• When you send an EHLO command to the Exchange server, you receive a "Command unrecognized" response or an "OK" response.
• You cannot send or receive mail on specific domains.
• You have problems with Post Office Protocol version 3 (POP3) authentication. In this scenario, you may receive a "550 5.7.1 relaying denied" error on the Exchange server.
• Duplicate e-mail messages are sent (sometimes five or six copies).
• You receive duplicate incoming Simple Mail Transfer Protocol (SMTP) messages.
• Microsoft Office Outlook clients generate error 0x800CCC79 when they try to send e-mail messages.
• You have problems with binary MIME (8-bit MIME). In this scenario, you receive the following text in a non-delivery report (NDR) delivery status notification (DSN) message: "554 5.6.1 Body type not supported by Remote Host."
• You have missing or damaged message attachments.
• You have problems with the link state routing between routing groups when a Cisco PIX firewall device is located between the routing groups.
• The X-LINK2STATE verb is not passed.
• Authentication issues occur between servers over a routing group connector.

 Cause

These issues may occur when both the following conditions are true:

• The Exchange server is located behind a Cisco PIX firewall device that has the Mailguard feature enabled.
• The Auth and Auth login Extended Simple Mail Transfer Protocol (ESMTP) commands are removed by the firewall.

Note:

In this scenario, Exchange assumes that you are relaying e-mail from a remote domain.

To determine whether Mailguard is running on the PIX firewall, telnet to the IP address of the MX resource record, and then verify that you receive a response that resembles the following:

220*******************************0*2******0*********** 2002*******2***0*00

Note:

For readability, some asterisks (*) were removed from this message.

 Earlier versions of PIX devices

220 SMTP/cmap_____________________________________read

For more information about how to test the PIX firewall Mailguard feature, see Testing the PIX Firewall Mailguard Feature.

Note:

The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.

Note:

Other firewall products that include SMTP Proxy functionality may also generate the behavior that is mentioned in the "Introduction" section. For more information about these products, see the "For More Information" section in this topic.

 Resolution

If you have an Extended SMTP (ESMTP) server behind a PIX firewall device, you may have to turn off the PIX Mailguard feature to enable correct mail flow.

Caution:

This workaround may make your computer or your network more vulnerable to attack by malicious users or by malicious software such as viruses. Use this workaround at your own risk.

To turn off the Mailguard feature, follow these steps:

1. Log on to the PIX device by establishing a telnet session or by using the console.
2. Type enable, and then press ENTER.
3. When you are prompted, type your password, and then press ENTER.
4. Type configure terminal, and then press ENTER.
5. Type no fixup protocol smtp 25, and then press ENTER.
6. Type write memory, and then press ENTER.
7. Restart the PIX device, or reload the PIX configuration.

Cisco ASA Extended SMTP inspection improves the traditional SMTP inspection that is provided by Cisco PIX Firewall version 6.x or earlier versions. It provides protection against SMTP-based attacks by restricting the types of SMTP commands that can pass through the Cisco ASA. This also applies to several Cisco routers including the commonly used Catalyst 6500 and 7600 models.

For more information, see Cisco ASA 5500 Series Release Notes and Configuring Application and Protocol Inspection - Cisco Systems.

Note:

The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.

 For More Information

The PIX Mailguard feature (known as Mailhost in early versions) filters SMTP traffic. For PIX Software versions 4.0 and 4.1, you use the mailhost command to configure Mailguard. In PIX Software version 4.2 and later versions, you use the fixup protocol smtp 25 command.

Note:

You must also have static IP address assignments and conduit statements for the mail server.

When Mailguard is configured, it allows only the commands that form the minimum implementation of SMTP, as described in Request for Comments (RFC) 821, section 4.5.1. The seven minimum commands are as follows:

• HELO
• MAIL
• RCPT
• DATA
• RSET
• NOOP
• QUIT

For more information, see RFC821 - Simple Mail Transfer Protocol.

Other commands, such as KILL and WIZ, are not forwarded to the mail server by the PIX firewall. Early versions of the PIX firewall return an "OK" response, even to commands that are blocked. This is intended to prevent an attacker from determining whether the commands have been blocked. All other commands are rejected with the "500 Command unrecognized" response.

On Cisco PIX firewalls with firmware versions 5.1 and later versions, the fixup protocol smtp command changes the characters in the SMTP banner to asterisks, except for the "2," "0," and "0" characters. Carriage return (CR) and linefeed (LF) characters are ignored. In version 4.4, all characters in the SMTP banner are converted to asterisks.

 To determine whether Mailguard is functioning correctly

Because the Mailguard feature may return an "OK" response to all commands, it may be difficult to determine whether Mailguard is active. To determine whether the Mailguard feature is blocking commands that are not valid, follow these steps.

Note:

These steps are based on PIX software versions 4.0 and 4.1. To test later versions of PIX software, such as version 4.2, use the fixup protocol smtp 25 command together with the appropriate static and conduit statements for your mail server.

 With Mailguard Turned Off

1. On the PIX firewall, use the static and conduit commands to allow incoming traffic from all hosts on TCP port 25 (SMTP).
2. Establish a telnet session on the external interface of the PIX firewall on port 25.
3. Type a command that is not valid, and then press ENTER. For example, type goodmorning, and then press ENTER.
   
   You receive a "500 Command unrecognized" response.

 With Mailguard Turned On

1. Use the mailhost or the fixup protocol smtp 25 command to turn on the Mailguard feature on the external interface of the PIX firewall.
2. Establish a telnet session on the external interface of the PIX firewall on port 25.
3. Type a command that is not valid, and then press ENTER. For example, type goodmorning, and then press ENTER. You receive an "OK" response.

When the Mailguard feature is turned off, the mail server generates a "500 Command unrecognized" response for invalid commands. However, when the Mailguard feature is turned on, the PIX firewall intercepts the invalid command because the firewall passes only the seven minimum SMTP commands. The PIX firewall responds with "OK" whether the command is valid or not.