ESMTP Sessions

Whether or not a mail server supports SMTP service extensions, mail can generally be delivered. It is only a matter of the client determining how much work it needs to do to prepare a message for transit. This section includes two sample sessions that illustrate this principle: the first one shows an ESMTP session that uses the DSN service extension to request a return receipt of a message. The second one shows the same message being delivered without use of any service extensions.

Figure 9-2 shows an ESMTP session that uses the DSN service extension to request a return receipt of a message. The client should note upon initial connection that the server states in its banner that it supports some service extensions: it includes the string “ESMTP” in the banner. The list of service extensions is returned in the response to the client’s EHLO command.

The client follows with the use of the standard (but optional) EXPN command. This is not necessary but simply illustrates the appropriate place in the flow of a session for this type of command. The server responds with the full (expanded) addresses of all members of the “geeks” mailing list.

A HELP command is issued next with a parameter of SOML. This asks for help with the outdated SOML command. The server returns help on the command but notes that it is not implemented.

A mail transaction state is entered with use of the MAIL command. In this case, the client is using the proposed DSN service extension in the MAIL command to ask that the message headers be included in any subsequent delivery notification. The client knows that it can use this extension because the server has already stated that it supports it.

Similarly, the RCPT command makes use of a DSN extension to ask that the sender be notified only on successful delivery of the message.

A DATA command follows, with the client actually sending the outgoing message to the server. The command terminates when the client sends a CRLF.CRLF combination (a single period on a line by itself). The server accepts delivery, and the client quits.

It is instructive to look at the return receipt message resulting from the ESMTP session in Figure 9-2.

The receiving ESMTP server (that is, the mail server for the recipient) sent a message to the sender upon delivering the message to the recipient’s mailbox. This does not guarantee that the recipient will ever read the original message, but it does guarantee that it was properly delivered.

The full text of the return receipt message follows. Note that it is in three parts: the first part states that the message was delivered to the recipient’s mailbox. The second part gives envelope information for the delivered message, and the third part gives the headers of the delivered message.

If we looked at the headers of the delivered message, we would not see anything that told the receiving MTA to issue a return receipt since that information was held in the message’s envelope.

Return-Path: <[email protected]>
Received: from localhost (mail@localhost [127.0.0.1])
        by morris.staff.plugged.com.au (8.8.7/8.8.7) with ESMTP id RAA07314
        for <dwood@localhost>; Sat, 12 Dec 1998 17:00:23 +1000
Received: from mailhost.plugged.net.au
        by fetchmail-4.6.2 POP3
        for <dwood/localhost> (single-drop); Sat, 12 Dec 1998
        17:00:24 EST
Sample ESMTP session
Figure 9-2. Sample ESMTP session
Received: from loca1host (loca1host)
        by mai1host.plugged.net.au (8.8.8/8.8.8) with internal id QAA23358;
        Sat, 12 Dec 1998 16:58:51 +1000
Date: Sat, 12 Dec 1998 16:58:51 +1000
From: Mail Delivery Subsystem <[email protected]>
Message-Id: <[email protected]_net.au>
To: <[email protected]>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
        boundary="QAA23358.913445931/mailhost.plugged.net.au"
Subject: Return receipt
Auto-Submitted: auto-generated (return-receipt)
Status:
x-Mozilla-Status: 8001

This is a MIME-encapsulated message

--QAA23358.913445931/mailhost.plugged.net.au

The original message was received at Sat, 12 Dec 1998 16:58:49 +1000
from in.plugged.net.au [203.20.51.50]

   ----- The following addresses had successful delivery notifications -----
<[email protected]> (successfully delivered to mailbox)

   ----- Transcript of session follows -----
<[email protected]>... Successfully delivered

--QAA23358.913445931/mailhost.plugged.net.au
Content-Type: message/delivery-status

Original-Envelope-Id: NS40112696JT
Reporting-MTA: dns; mailhost.plugged.net.au
Received-From-MTA: DNS; in.plugged.net.au
Arrival-Date: Sat, 12 Dec 1998 16:58:49 +1000

Original-Recipient: rfc822;[email protected]
Final-Recipient: RFC822; <[email protected]>
Action: delivered (to mailbox)
Status: 2.1.5
Last-Attempt-Date: Sat, 12 Dec 1998 16:58:51 +1000

--QAA23358.913445931/mailhost.plugged.net.au
Content-Type: text/rfc822-headers

Return-Path: <[email protected]>
Received: from morris.staff.plugged.com.au (in.plugged.net.au [203.20.51.50])
       by mailhost.plugged.net.au (8.8.8/8.8.8) with ESMTP id QAA23357
       for <[email protected]>; Sat, 12 Dec 1998 16:58:49 +1000
Received: from plugged.net.au ([email protected]
        [192.168.20.61])
        by morris. staff.plugged. com. au (8.8.7/8.8.7) with ESMTP id QAA07285
        for <[email protected]>; Sat, 12 Dec 1998 16:58:48 +1000
Sender: [email protected]
Message-ID: <[email protected]>
Date: Sat, 12 Dec 1998 16:58:48 +1000
From: [email protected]
To: [email protected]
Subject: Test of DSN

--QAA23358.913445931/mailhost.plugged.net.au--

Figure 9-3 is not quite as interesting. It shows a client connecting to a server which does not have “ESTMP” in its banner string. Being optimistic, the client attempts an EHLO command anyway, but should not have been surprised when it failed.

Since the server in question does not support any service extensions, the client may only presume that only required commands are available and in their standard form.

An EXPN command fails in this case, although it may work on some implementations. A client cannot be certain in advance since no service extension reporting is supported by the server.

A mail transaction is then entered with a standard, no frills MAIL command, followed by the expected RCPT and DATA commands. The client then quits after the server has excepted the message for delivery.

Sample SMTP session with an old server
Figure 9-3. Sample SMTP session with an old server
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.118.226.105