Emerging SMTP Technologies: A Review
Hallett German
Copyright (c) 1997 All Rights Reserved
Outline of Talk -- 1
- What is Extended SMTP (ESMTP) ?
- The typical SMTP Session
Dialog
- Extended SMTP Technologies
- Other SMTP Technologies
- LDAP-based routing of
SMTP messages
Outline of Talk -- 2
- Conclusions
- Interoperability Tests
- References
- Your Turn
Why Extended SMTP (ESMTP)?
- Address original shortcomings
- Add capabilities that
make SMTP more efficient/effective.
- Add those capabilities
only found in X.400.
- Formalized in 1993
- In short, to make something good even better!
What is Extended SMTP?
- A framework for using SMTP extensions that is
understood by both client and server(s)
- Number will purposely
be kept small
- Need to be registered
with IANA:
- But can have local extensions
(X)
A Typical SMTP Session Dialog
Server 1
- HELO betty.tel.gte.com
- MAIL FROM:<hal@tel,gte.com>
- RCPT TO: <hhg1@gte.com>
- ...
- DATA
- ...
- .
- QUIT
- Due To Formatting, Server 2's dialog not shown.
Extended SMTP Technologies:
Overview -- 1
- Large Attachments
- Size Declaration
- Transmission of Large
Messages
- Enhancements
- Pipelining
- 8 bit MIME
- Enhanced Error Codes
- Delivery Status Notifications
Extended SMTP Technologies:
Overview -- 2
- Other capabilities
- Remote message queue starting
- SMTP checkpoint/restart
- Authentication
- Message submission
- Note: HELO replaced by
EHLO
- Shows Options on Startup
- Need Sendmail 8.7.x or
8.8.x for ESMTP
Extended SMTP Technologies:
Large Attachments -- 1
- Problem: Large message transfer failed due to
storage limitations or message size.
- Solution: RFC1870 (SIZE)
allows sending of a maximum size parameter.
- Session:
- EHLO betty.tel.gte.com
- 250 SIZE 1000000
- MAIL FROM... SIZE 500000
- 250 ...can accommodate
500000 byte message
Extended SMTP Technologies:
Large Attachments -- 2
- Error codes on failure provided
- Could be used by hackers
to create a service denial attack.
- Result: Reduces long and
unnecessary SMTP sessions
Extended SMTP Technologies:
Large Attachments -- 3
- Problem: Messages are getting larger due to richer
attachments.
- Solution: RFC1830 (BDAT)
allows a way to efficiently send unencoded large files .
- Session:
- EHLO betty.tel.gte.com
- 250 CHUNKING
- BDAT 69 LAST
- 250 Message OK 69 Octets
Received
Extended SMTP Technologies:
Large Attachments -- 4
- Can also be used with 8 BIT MIME & BINARY
MIME messages.
- Raises no new security
concerns
- Result: Shorter SMTP sessions
Extended SMTP Technologies:
Enhancements -- 1
- Problem: Server and client each send only one
command at a time during a session.
- Solution: RFC1854 (PIPELINING)
-- ability to batch single commands into one send.
- Raises no new security
concerns
- Result: Shorter SMTP sessions
for messages.
Extended SMTP Technologies:
Enhancements -- 2
- Session:
- 250 EHLO betty.tel.gte.com
- 250 PIPELINING
- MAIL FROM:
- RCPT TO...
- RCPT TO..
- DATA
- 250 sender <...> OK
- 250 recipient <...> OK
- 250 recipient <..> OK
Extended SMTP Technologies:
Enhancements -- 3
- Problem: SMTP (RFC821) limited to US-ASCII characters
and 7 bit transport.
- Solution: RFCs 1428/1652
(8 BIT MIME)
- Session:
- 250 EHLO betty.tel.gte.com
- 250 8BIT MIME
- MAIL FROM...BODY=8BITMIME
- DATA
- 354 Send 8BITMIME message ending in CRLF.CRLF
Extended SMTP Technologies:
Enhancements -- 4
- Raises no new security concerns.
- Works well with pipelining.
- Reduces need for encoding.
- Controversial
- US-ASCII-->ISO-8859-1
- Lessons from ISO-646
- Legacy systems may delete
message
- Inevitable?
Extended SMTP Technologies:
Enhancements -- 5
- Problem: Only 12 useful codes for delivery reports,
5 for system errors. International needs not addressed.
- Solution: RFCs 1893 and
2034
- Session:
- 250 EHLO betty.tel.gte.com
- 250 ENHANCEDSTATUSCODES
- RCPT TO:...
- 550 5.1.1 Mailbox... does not exist
Extended SMTP Technologies:
Enhancements -- 6
- Client:
- Action:Failed
- Status 5.1.1 (Bad destination
mailbox address)
- Diagnostic-Code: smtp;
- 550 Mailbox "..."
does not exist
- Does not raise any security
concerns
- Handle changing needs.
- Should be used wisely.
Extended SMTP Technologies:
Enhancements -- 7
- Problem: Need to have Return Receipt
- Solution: RFC1891 provides
Delivery Status Notification. Also 1892, 1894
- Session:
- 250 EHLO betty.tel.gte.com
- 250 DSN
- MAIL FROM<...> RET=HDRS ENVID=Q2222
- RCPT TO:<..>NOTIFY=SUCCESS,DELAY ORCPT=...
Extended SMTP Technologies:
Enhancements -- 8
- NOTIFY = SUCCESS, FAILURE, DELAY, NEVER.
- ORCPT -- Original Recipient
- RET -- FULL, HDRS
- ENVID -- envelope identifier.
Identify the transaction that DSN was issued.
- Was designed to work with
non-SMTP mail system too.
Extended SMTP Technologies:
Other Capabilities -- 1
- Problem: Need to start processing a message queue
on a remote server in a SECURE fashion. (Such as ISP or subdomain.)
- Solution: RFC 1985 (ETRN)
- I think this will be enhanced
in future.
- Security concern: Implement
parameter checking or face problems.
Extended SMTP Technologies:
Other Capabilities -- 2
- Session:
- 250 EHLO betty.tel.gte.com
- 250 ETRN
- ETRN @tel.gte.com
- 250 OK queuing for node
gte.com started
OR
- ETRN @tel.gte.com
- 250 OK, 100 pending messages
for tel.gte.com started
Extended SMTP Technologies:
Other Capabilities -- 3
- Problem: Need to have interrupted SMTP sessions
restarted and sending only untransmitted portion of message.
- Solution: RFC1845 (CHECKPOINT)
- Result: Multiple unsuccessful
transmit attempts eliminated.
- No new security concerns
raised
Extended SMTP Technologies:
Other Capabilities -- 4
- Session:
- 250 EHLO betty.tel.gte.com
- 250 CHECKPOINT
- MAIL FROM:<..>TRANSID=<..>
(New Session)
- MAIL FROM:<..>TRANSID=<..>
- 355 6135 is the transaction offset
- DATA
- 354 Send previously checkpointed message starting
at octet 6135 .
Extended SMTP Technologies:
Other Capabilities -- 5
- Other features:
- Authentication (IETF Draft)-
SASL Support
- Message Submission (IETF
Draft)
- Message Change History
included
- Supersedes and Expires
e-mail headers (IETF Draft)
Other SMTP Technologies -- 1
- LDAP-based sendmail routing -- verify address
at send-time and appropriate route.
- Available in sendmail
8.7 and later.
- Replace NIS for alias
management??
- Needs much memory
Other SMTP Technologies -- 2
- IETF drafts on this topic:
- Netscape
- Stanford University
Conclusions: Interoperability test
- MailConnect 2: IMAP & ESMTP
- Vendors participating:
- PMDF, Lotus, Microsoft,
Isocor, Qualcomm
- Test plan available
- 2 rounds of testing held.
No results released
Conclusions: References -- 1
- Extended SMTP RFCs
- RFC 1428 Transition of
Internet Mail from Just-Send-8 to 8bit-SMTP/MIME
- RFC 1652 SMTP Service
Extension for 8bit MIME transport
- RFC 1830 SMTP Service
Extensions for Transmission of Large and Binary MIME Messages
- RFC 1845 SMTP Service
Extension for Checkpoint/Restart
- RFC 1854 SMTP Extension
for Command Pipelining
- RFC 1869 SMTP Service
Extensions
Conclusions: References -- 2
- Extended SMTP RFCs
- RFC 1870 SMTP Service
Extension for Message Size Declaration
- RFC 1891 SMTP Service
Extension for Delivery Status Notification
- RFC 1985 SMTP Message
Extension for Remote Message Queue Restarting
- RFC 2034 SMTP Service
Extension for Returning Enhanced Return Codes
Conclusions: References -- 3
- IETF Drafts
- LDAP-based Routing of
SMTP Messages: Approach Used by Netscape
- LDAP-based Routing of
SMTP Messages: Approach at Stanford University
- Message Submission and
Relay
- Simple Mail Transfer Protocol
- SMTP Service Extension
for Authentication
- SMTP Extension for Command
Pipelining
- The Supersedes and Expires
e-mail headers
Conclusions: References -- 4
- Other documents:
- Using LDAP with Sendmail
8.8.x
- IME FAQ: Part 3
Your Turn
Home Page Publications