SMTP Extensions for Smail 3.1.28 Version 9 by Simon Leinen DESCRIPTION ----------- This file contains a patch to the Smail 3.1.28 sources that implements RFCs 1425, 1426 and 1427 as well as the Internet Draft `draft-ietf-smtpext-pipeline-02.txt'. The following features are implemented: * The new EHLO command is recognized as mandated by [RFC1425]. The list of supported extensions in the reply includes HELP, EXPN and optionally 8BITMIME and SIZE. If a message is received from a remote mailer that said EHLO, the Received: line that is added to the message will contain a sender protocol of "esmtp" rather than "stmp" (or "ebsmtp" rather than "bsmtp"). * NEW (June 15, 1994): The PIPELINING extension is provided by the server (this did not necessiatate any modifications of how the server works) and used by the client. The PIPELINING extension reduces the number of turn-arounds in SMTP conversations between two mailers that both support it. This can be a big win over slow IP networks. The implementation is based on the Internet Draft `draft-ietf-smtpext-pipeline-02.txt' which is available from many archive sites that have IETF documents. * BODY [RFC1426] and SIZE [RFC1427] clauses are recognized in MAIL FROM: SMTP commands on the receiver side. Currently it doesn't matter whether the BODY type is 7BIT or 8BITMIME - Smail is always 8-bit transparent. If the value passed in a SIZE clause exceeds max_message_size, a "552 message too large" error reply is generated. * The sender side tries to greet the receiving SMTP with an EHLO command. If this fails, we send the standard HELO greeting. If this also fails, we try RSET to clear up the remote mailer and then HELO. If the EHLO is accepted, Smail parses the response to find out whether the receiver understands SIZE and BODY. A maximum message size that is provided by the receiving SMTP is currently ignored, but the MAIL FROM: command is decorated with a SIZE declaration based on a guess of the spooled message's size. The BODY clause is never issued. INSTALLATION ------------ Apply the enclosed patch to the top-level directory of the Smail distribution (the one that contains the src/ subdirectory). You will need a fairly recent version of the "patch" program because the patch is in the newer, more compact and more readable Unidiff format. The server side of the extensions cannot be disabled in this version. This means that EHLO is always accepted as an SMTP greeting, and the SIZE parameter is accepted. In order to enable the extensions, the following symbols have to be added to the HAVE variable in the EDITME file: EHLO to enable client-side support for EHLO, SIZE and PIPELINING ESMTP_8BITMIME to enable minimal server-side RFC 1426 support. Basically the BODY clause is accepted and ignored. CAVEATS ------- Here is a possible problem with ESMTP support: Apparently there are some non-RFC821-conformant gateways running on legacy systems that react to the EHLO query by closing down the connection rather than giving a "500 command unrecognized" error. Smail handles this situation like a normal link failure, so a message sent via SMTP to such a mailer will presumably get bounced after the retry period is over. If you care about interoperatibility with such weird systems, you probably don't want to use the SMTP extensions, or write some code for Smail to handle this situation more cleverly (see the TODO section below). Personally I think that this is such an extreme case of protocol incompatibility that I haven't taken the time to support these mailer daemons. When an ESMTP-capable client Smail talks to a non-ESMTP-capable SMTP server, there are two additional query/reply pairs for each SMTP connection. This is because Smail issues EHLO to find out whether the recipient mailer handles ESMTP, gets an error message and then sends an RSET before retrying with HELO. If you have extremely slow or unreliable SMTP connections, or if your network connections are charged by the packet this may matter to you. TODO ---- Right now the SMTP extensions don't really give any new functionality, except that max_message_size is *somewhat* enforced, but only for cooperating (RFC 1427-savvy) client mailers. The following improvements to the code might be useful: * a SIZE clause should be used to dynamically determine whether the incoming message will fit where it will be put next (one of the spool directories). If this is the case, a temporary failure message should be sent to the client SMTP to avoid sending a lot of data in vain. * Smail should be extended to handle 8-bit text messages in a more standard way. Currently it is simply 8-bit transparent, which is seen as a feature by most users. However, sending non-7-bit-ASCII characters to remote mailer daemons is a violation of RFC 821 and can lead to interoperability problems. Even when communicating over 8-bit clean SMTP networks, the "Just-Send-8" approach has the problem that it is not clear which character set has been used by the author [RFC1428]. In principle, all these problems are solved by the MIME standard [RFC1341, RFC1342], which is rapidly gaining acceptance. In a world where everybody uses MIME-capable mailers, there wouldn't be any eighth bits to be transported. But as long as people still send 8-bit messages, Smail could convert such messages to 7bit-MIME when they are transported over an SMTP network. RFC1428 describes how this could be done. * If the "link broken by EHLO" problem really does occur in the real world, it has to be handled by Smail's SMTP client side. For instance, once an EHLO command causes a link to be broken, the receiving host should be noted in a "black list" by a mechanism similar to the retry file mechanism. Hosts should be removed from the black list periodically, so that when they are upgraded to SMTP-conforming software, the new functionality will be used. It would also be nice if the "retry" file could be extended by something like "ehlo/noehlo" keyword that would allow specific hosts/domains to be excluded from ESMTP trials. * Some SMTP-based transports may want to use EHLO while others don't. In batch SMTP, for example, the EHLO command probably doesn't make much sense since the whole idea of "option negociation" doesn't fit into the "batch" model. I don't know whether this should be hardwired in the SMTP transport or made a configurable parameter of transport entries. ReFerenCes 1344 N. Borenstein, "Implications of MIME for Internet Mail Gateways", 06/11/1992. (Pages=9) (Format=.txt, .ps) 1425 J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP Service Extensions", 02/10/1993. (Pages=10) (Format=.txt) 1426 J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 02/10/1993. (Pages=6) (Format=.txt) 1427 K. Moore, N. Freed, J. Klensin, "SMTP Service Extension for Message Size Declaration", 02/10/1993. (Pages=8) (Format=.txt) 1428 G. Vaudreuil, "Transition of Internet Mail from Just-Send-8 to 8Bit-SMTP/MIME", 02/10/1993. (Pages=6) (Format=.txt) 1521 N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", 09/23/1993. (Pages=81) (Format=.txt) (Obsoletes RFC1341) 1522 K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text", 09/23/1993. (Pages=10) (Format=.txt) (Obsoletes RFC1342)