9.4 Processing incoming messages

 < Day Day Up > 



Messages can arrive into an Exchange server through a variety of different routes. The initial submission mechanism and processing performed to get the message into the system is different for each route, but they all come together when messages arrive at the categorizer.

9.4.1 SMTP messages

SMTP servers act as clients to other SMTP servers when they transmit messages. Clients submit messages to port 25, one of the ports monitored by IIS. The SMTP service creates a thread to process the new message. Protocol events might fire before a message is fully accepted. For example, the SMTP service may need to check the sender of the message with a DNS lookup to ensure that the sender comes from a valid server in an attempt to defeat spammers. If valid, the SMTP service can accept the message and the transaction continues.

The Routing Engine fires a Store driver event when it accepts a message. Currently, Exchange uses an enhanced version of the standard Windows NTFS Store driver to access NTFS files instead of a driver that accesses the Store directly using ExIFS. The developers took a deliberate decision not to use ExIFS to avoid creating a dependency on the Store service or, more specifically, to attempt to access a folder in a database that the Store might not have mounted when a message arrives. NTFS is always available when a server is running, and the drop directory is available if the disk where it is located is mounted. In addition, directing messages into an NTFS folder rather than the Store avoids problems that might occur when administrators move or delete Mailbox Stores.

The new message goes onto the OnSubmission queue, which fires an event. If an error occurs at this point (e.g., the SMTP service receives a badly formed SMTP message or an unauthorized source attempts to relay through the server), a failure DSN message (a nondelivery notification) is generated and sent back to the originator. If Exchange cannot generate the DSN, perhaps because the sender is unknown, the message goes into the badmail directory (typically \exchsrvr\mailroot\badmail). The message also ends up in the badmail directory if Exchange rejects the DSN message or cannot deliver it. If you leave your server available as an open SMTP relay, spammers can use it to "inject" messages and send them around the world. Spammers address messages to lists that they assemble, and the nature of the beast is that a lot of spam goes to invalid recipients and ends up by generating NDRs. If Exchange cannot deliver the NDRs, they may end up in your badmail directory and steadily absorb disk space until you close off the open relay. This is one reason why you should always check Exchange servers for open SMTP relays.

You can change the location of the badmail directory through the "Mes- sages" property page for the SMTP virtual server, as shown in Figure 9.7. The fired event then causes the transport core Store driver to create a special object called an ImailMsg and then populate the structure with various properties extracted from the incoming message. Similar to an X.400 message, the ImailMsg structure divides into two main parts. A set of properties such as the sender, subject, and recipients composes the message envelope, while a file on disk in the Queue directory holds the message body and any attachments. The transport core Store driver returns the pointer to the file created on disk and inserts this pointer into the ImailMsg structure.

click to expand
Figure 9.7: SMTP VS "Messages" properties (Exchange 2003).

After the ImailMsg structure is fully populated, the SMTP service returns it to the Advanced Queuing component, which then places the message in the Pre-Categorizer queue. If an error occurs at any point while the transport core is processing an incoming SMTP message, it is removed from the queue and dumped into the badmail directory, as described previously. (See Figure 9.8.)

click to expand
Figure 9.8: SMTP messages that cannot be processed.

If the queuing engine determines that the message is for local delivery, it must insert the message into the Store. To do this, IIS obtains a file handle to a virtual file and writes the incoming data directly into the file through ExIFS. ESE provides data in 2-MB contiguous chunks to ExIFS when it requests space, which then becomes "reserved space" until it is finally used. New messages are written into a set of pages in the reserved space. After it receives each message, ExIFS returns the list of pages the message was written to and its properties are promoted into the EDB database. The message transaction is logged into the current transaction log, and, after this occurs, the pages in the streaming file are deemed to be committed and are moved out of the reserved set. Outgoing messages are handled the same way, being read out by IIS from the Store via ExIFS.

9.4.2 MAPI messages

MAPI clients do not travel via an IIS protocol stack. Instead, MAPI clients make a direct connection to the Store and submit messages in much the same manner as Exchange 4.0. The notable difference is that submission is no longer the point at which Exchange generates nondelivery notifications or delivery receipts. After a message is accepted, the Store puts the message into a special folder called "SendQ" and fires an event to notify the transport core Store driver that a new message is waiting. The transport core Store driver then processes the MAPI content and builds an ImailMsg structure for submission to the Advanced Queuing component.

MAPI messages sent between Exchange servers are rendered in Transport Neutral Encapsulated Format (TNEF). TNEF is a format that Exchange can very quickly transform back into MAPI properties and content, so this is a low-overhead method to transport MAPI messages across SMTP. The messages are formed from an RFC 822-compliant header and an application-specific MS-TNEF MIME bodypart. Exchange servers communicate together using SMTP, which implies that the TNEF content needs to be rendered into MIME before it can be transported. Exchange solves the problem by transporting the messages as if they were binary content, so they do not need to be converted. Messages that are destined outside the organization are converted into MIME using the Base64 coding scheme, so they end up being between 25 percent and 30 percent larger.

9.4.3 HTTP messages

OWA clients generate and send messages over HTTP-DAV; these messages arrive into the Store through a direct connection similar to MAPI.

9.4.4 X.400 messages

The MTA handles all inbound X.400 messages, but it does not attempt to perform any routing or assessment of addresses, such as distribution list expansion. After the message is accepted by the MTA, it is simply put into the MTA Out folder within the Store, from where the message is then placed on the OnSubmission queue before it is fetched by the transport core Store driver and given to the Advanced Queuing component. It is then sent on to the Pre-Categorizer queue.

9.4.5 Foreign connectors

Any connector that attaches to Exchange maintains its own MTS Out folder in the Store. It is the responsibility of the connector to process incoming messages and ensure that they are validly formed and ready for further processing. When the connector is satisfied, it places the message in the MTS Out folder, which causes the transport core Store driver to move the message to the OnSubmission queue for processing by the Advanced Queuing component.[5]

[5] . A problem with the Lotus Notes connector is that it does not operate correctly in a routing group that contains mailbox servers. You therefore need to create a special routing group to host the Lotus Notes connector, which should run on a server that has no mailboxes. The problem is fixed in Exchange 2000 SP1.



 < Day Day Up > 



Microsoft Exchange Server 2003
Microsoft Exchange Server 2003 Administrators Pocket Consultant
ISBN: 0735619786
EAN: 2147483647
Year: 2003
Pages: 188

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net