RFC 2645

ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses

📅 published August 1999, from ietf

📮 RFC 2645: On-Demand Mail Relay (ODMR) 💖

Okay bestie, so this is RFC 2645, and it's called On-Demand Mail Relay (ODMR), with the subtitle SMTP with Dynamic IP Addresses 🦋. It was written by R. Gellens at Qualcomm, it's on the Standards Track, and it's dated August 1999. The title block doesn't list any RFCs that it obsoletes or updates ✨.

This is part 1 of 2, so we're covering the basics, the states, and the ATRN command. Part 2 has the example session, the response codes, security, and the references 🎀.

Status of This Memo 🌸

This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.

Copyright (C) The Internet Society (1999). All Rights Reserved.

Table of Contents 🧚

    1.  Abstract . . . . . . . . . . . . . . . . . . . . . . . . . .  1
    2.  Conventions Used in this Document . . . . . . . . . . . . . . 2
    3.  Comments . . . . . . . . . . . . . . . . . . . . . . . . . .  2
    4.  Description . . . . . . . . . . . . . . . . . . . . . . . . . 2
    5.  States . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
      5.1.  Initial State . . . . . . . . . . . . . . . . . . . . . . 4
        5.1.1.  EHLO . . . . . . . . . . . . . . . . . . . . . . . .  4
        5.1.2.  AUTH  . . . . . . . . . . . . . . . . . . . . . . . . 4
        5.1.3.  QUIT . . . . . . . . . . . . . . . . . . . . . . . .  4
      5.2.  Authenticated State . . . . . . . . . . . . . . . . . . . 4
        5.2.1.  ATRN (Authenticated TURN)  . . . . . . . . . . . . .  4
      5.3.  Reversed State  . . . . . . . . . . . . . . . . . . . . . 5
      5.4.  Other Commands . . . . . . . . . . . . . . . . . . . . .  6
    6.  Example On-Demand Mail Relay Session: . . . . . . . . . . . . 6
    7.  Response Codes . . . . . . . . . . . . . . . . . . . . . . .  6
    8.  Security Considerations . . . . . . . . . . . . . . . . . . . 6
    9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  7
   10.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 7
   11.  Author's Address   . . . . . . . . . . . . . . . . . . . . .  8
   12.  Full Copyright Statement  . . . . . . . . . . . . . . . . . . 9

1. Abstract ✨

More and more people are running their own local mail servers on cheap computers and Internet connections 💻. A lot of these systems only connect to their service provider now and then 🔌. If the system has a static IP address, the ESMTP ETRN command [ETRN] can do the job. But systems with dynamic IP addresses, which are super common on low-cost connections, don't have a widely-deployed solution yet 😭.

This memo proposes a new service, On-Demand Mail Relay (ODMR). It's a profile of SMTP [SMTP, ESMTP] that's secure, extensible, and easy to implement 🔥.

2. Conventions Used in this Document 💅

Since the client and server roles swap during the session, we're using the words "customer" and "provider" instead of "client" and "server" so nobody gets confused 🙈. Of course, this protocol could be useful in situations other than commercial service providers and customers, so don't limit your brain there 🌈.

In examples, P: marks lines sent by the provider, and C: marks lines sent by the customer. Line breaks inside a command are just for editing and aren't part of the command 📝.

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in [KEYWORDS] 🔑.

Examples use example.net as the provider, and example.org and example.com as the customers 🧚.

3. Comments 🎀

Private comments go to the author. Public comments can go to the IETF Disconnected SMTP mailing list at <ietf-disconn-smtp@imc.org> 💌. To subscribe, send a message to <ietf-disconn-smtp-request@imc.org> with the word SUBSCRIBE as the body ✨.

4. Description 🦋

On-Demand Mail Relay is a restricted profile of SMTP [SMTP, ESMTP] 💖. Port 366 is reserved for On-Demand Mail Relay 🍓. The first client and server roles are short-lived, because the whole point is letting the intermittently-connected host ask a service provider for the mail being held for it 📬.

The customer connects to the provider, authenticates, and asks for its mail. Then the client and server roles reverse, and normal SMTP [SMTP, ESMTP] takes over 🔄.

The provider runs an On-Demand Mail Relay process that listens for connections on the ODMR port 👑. This process doesn't have to be a full SMTP server 🫶. It does have to be an SMTP client that can get to the outgoing mail queues. As a server, it has to implement the EHLO, AUTH, ATRN, and QUIT commands 💅.

An MTA normally has a mail client component that works through the outgoing mail queues and tries to send mail for particular domains. That happens based on time or on an event, like new mail landing in the queue or the SMTP server component getting an ETRN command ⏰. The On-Demand Mail Relay service doesn't process the outgoing queue on a timer or when new mail shows up. It does it when someone asks ✋.

The provider side still has the normal SMTP server responsibilities [SMTP], including generating delivery failure notices and so on, as needed 📨.

5. States 🌙

The On-Demand Mail Relay service has three states: an initial state, an authenticated state, and a reversed state 💫. Here's how it moves between them:

   ---------------------------
   !      initial state      !
   ---------------------------
     !             !
   QUIT           AUTH
     !             !
     !             V
     !      -----------------------
     !      ! authenticated state !
     !      -----------------------
     !       !            !
     !      QUIT         ATRN
     !       !            !
     !       !            V
     !       !      ------------------
     !       !      ! reversed state !
     !       !      ------------------
     !       !         !
     !       !        QUIT
     !       !         !
     V       V         V
     ---------------------
     !    termination    !
     ---------------------

(Heads up: in the reversed state, the provider is the one sending commands, not the customer 🔁.)

5.1. Initial State 🌱

In the initial state, the provider is the server and the customer is the client. Three commands are valid here: EHLO, AUTH, and QUIT 💖.

5.1.1. EHLO 🌸

The EHLO command works the same as in [ESMTP]. The response MUST include AUTH and ATRN 🫶.

5.1.2. AUTH 🔐

The AUTH command is specified in [AUTH]. It uses a [SASL] mechanism to authenticate the session. The session doesn't count as authenticated until a success response to AUTH has been sent ✅.

For interoperability, implementations MUST support the CRAM-MD5 mechanism [CRAM] 🤝. Other SASL mechanisms may be supported too. A site MAY disable CRAM-MD5 support if it uses more secure methods 🛡️. The EXTERNAL mechanism [SASL] might be useful in some cases, for example, if the provider has already authenticated the client, such as during a PPP connection 🔌.

5.1.3. QUIT 👋

The QUIT command works the same as in [SMTP] 🧡.

5.2. Authenticated State 🔓

The authenticated state starts after a successful AUTH command. Two commands are valid in this state: ATRN and QUIT 💜.

5.2.1. ATRN (Authenticated TURN) 🎀

Unlike the TURN command in [SMTP], the ATRN command can optionally take one or more domains as a parameter 💅. The ATRN command MUST be rejected if the session hasn't been authenticated. Response code 530 [AUTH] is used for this 🚫.

The timeout for this command MUST be at least 10 minutes, so the provider has enough time to work through its mail queue ⏳.

An ATRN command sent with no domains is the same as an ATRN command that names every domain the customer has access to 🌈.

If the authentication the customer used doesn't give access to all of the domains in ATRN, the provider MUST NOT send mail for any domains to the customer. The provider MUST reject the ATRN command with a 450 code 🙅‍♀️.

If the customer does have access to all of the named domains, but none of them have queued mail, the provider normally rejects the ATRN command with response code 453 📭. The provider MAY instead issue a 250 success code. In that case, after the roles reverse, the customer sends a QUIT following the EHLO 🦋.

The provider MAY also reject the ATRN command with a 450 response to show that it won't take multiple requests within a particular time interval ⏱️.

If the customer has access to all of the named domains and mail exists in at least one of them, the provider issues a 250 success code 🎉.

If the server can't verify access to the requested domains (for example, a mapping database is temporarily unavailable), response code 451 is sent 🥺.

      [ABNF] for ATRN:

      atrn          = "ATRN" [SP domain *("," domain)]

      domain        = sub-domain 1*("." sub-domain)

      sub-domain    = (ALPHA / DIGIT) *(ldh-str)

      ldh-str       = *(ALPHA / DIGIT / "-") (ALPHA / DIGIT)

5.3. Reversed State 🔄

After the provider sends a success reply to the ATRN command, the roles reverse. The customer becomes the server, and the provider becomes the client 🪞.

After the customer gets the success response to ATRN, it sends a standard SMTP initial greeting line 👋. From here on, normal SMTP [SMTP, ESMTP] commands are used. Usually the provider sends EHLO after it sees the customer's greeting, and then comes MAIL FROM and so on 💌.

5.4. Other Commands 🚧

The provider MAY reject every command other than EHLO, AUTH, ATRN, and QUIT with response code 502 🙅‍♀️.

9. Acknowledgments ✨

okay so this memo came together partly from comments and discussions that happened on and off the IETF-disconn-smtp mailing list 📬 bestie, huge shoutout to Chris Newman and Ned Freed for their feedback 🫶💖

10. References 📚

okay here's the whole reading list, every single one of these is a must-read if you wanna understand the vibe 💅

  • [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. 🦋
  • [AUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. 🔐
  • [CRAM] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997. 🌸
  • [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", RFC 1869, November 1995. ✨
  • [ETRN] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996. 🧚
  • [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 👑
  • [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. 🎀
  • [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. 💜

11. Author's Address 🎀

the author is Randall Gellens, over at QUALCOMM Incorporated 💖

Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Dr.
San Diego, CA  92121-2779
U.S.A.

Phone: +1.619.651.5115
EMail: randy@qualcomm.com

Copyright (C) The Internet Society (1999). All Rights Reserved. 🌈

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 🫶

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. ✨

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 😭

Acknowledgement 🌸

funding for the RFC Editor function is currently provided by the Internet Society, so shoutout to them too 💖

📦 where this page comes from