Transcript SMTP Tapu Ahmed Jeremy Nunn

SMTP
Tapu Ahmed
Jeremy Nunn
Basics



Responsible for electronic mail
delivery.
Simple ASCII protocol that runs on top
of TCP/IP.
Uses reserved port number 25.
SMTP Model
A
B
You want to send an E-Mail from A to B.
Both A and B are simple workstations.
A submits source and destination. If both are valid, server gives the
go-ahead signal
A
If, server is busy, client
will cancel connection
and try again.
We will first attempt the
destination server to see
if it will accept mail.
If server can accept
mail, the client submits.
Server B
Port 25
Our goal is to send a mail from A to B
A
B
Send Req
Step 1
A
Local Mail Server
ACK
Send Mail
Step 2
Local Mail Server
A
will store and queue
ACK
Step 3
DNS Query
Local Mail
Server
DNS Server
Reply with
IP address
resolution
REQ
Step 4
Server A
Server B
ACK
Send
Step 5
Server A
Server B:
receive/store
ACK
Ring
Step 6
Server B
B
ACK
Optional
SMTP protocol exists here,
between the two servers
and their “jumps.”

The exchange of mails using TCP/IP is
performed by a message transfer
agent (MTA).
– An MTA is responsible for routing mails to
their proper destinations.
– MTA uses the Mail Exchange (MX) record
from a DNS server to determine location.

In essence, the SMTP protocol
describes how two MTAs communicate
with each other using a single TCP
connection.
Sending Host
Local MTA
Local MTA
Queue
User A
Local MTA
Queue
of mail
Queue
of mail
Relay MTA
Across the
internet
Relay MTA
Local MTA
User B
User
Mailboxes
Receiving Host
Local MTA
Local MTA
Topics for SMTP

SMTP Description
– Primarily RFC 821 and 822
– Message formats
– Extensions

SMTP Applications
– Purpose
– Operations
– Unique problems encountered.
Topics for SMTP
continued

Security and performance issues
– Hacking
– End-end delivery system performance
– Spamming issues

Looking Ahead
– Future standardizations
RFC 821

A Description of SMTP
– Objective is to deliver mail reliably and
efficiently.

Points of interest
– Mailing/sending
– Forwarding
– Relaying
– Opening/closing

SMTP Procedure
– MAIL command


Clear buffer and get ready to receive mail
Gives sender ID
– RCPT command

Gives receiver information
– DATA command

Send the data






S: MAIL FROM: [email protected]
R: OK
S: RCPT TO: [email protected]
R: OK
S: RCPT TO: [email protected]
R: ERROR; no such user here

S: RCPT TO: [email protected]
R: OK

S: DATA

– send mails
– Ending signature

R: OK

RFC 821 also provides:
– Verification
– SMTP commands and syntax structure
– State diagrams
– Sequencing of commands and replies

Extensions:
– RFC 1869

EHLO command
– MAIL, RCPT, DATA can all receive
additional values.
RFC (2)822

Describes message formatting for SMTP.
– RFC 822 is the standard for the format of
internet text messages.
– RFC 2822: new standard

Points of interest
–
–
–
–
Message specifications
Date/time specifications
Address specifications
Different RFC extensions

Limitations:
– 998 character/line max. 78 min.
– Only ASCII characters

Header:
– Composed of a field name
– Terminates by a “:”, and ends with CRLF.

Address Specification:
– Individual or an entire mailbox
– Occurs in multiple fields to indicate
sender or receiver

Date and Time Specification
– Must be semantically valid.
– Added on through numerous headers.

Extensions:
– RFC 2045 and 2046

Describe mechanisms for transmission
SMTP Applications


Several SMTP applications exist, too numerous to
enumerate
qmail
– Configuration is “unique” (one file to one config value)
– Places many files in the root of your system
– Awkward license prevents distributing modified source or
binaries
– Developer/owner is a busy guy

sendmail
– Past and current versions (8) have been notoriously
insecure
– Remote root exploits, etc.
SMTP Applications

Postfix
–
–
–
–

Uses sensible defaults
Good security track record
Easier to configure
Can query LDAP to pick up new/modified users
Microsoft Exchange
– Very easy to use on a Windows network
– Integrates with Active Directory (uses LDAP)
– Not the best security
Security and Performance

Who needs security?
– When SMTP was initially developed, little (none maybe?)
emphasis was placed on security
– Design was built on the idea of cooperation and trust
– Didn’t anticipate spam

Mail Relay
– Relay is sending mail from one mail server to another
– Most SMTP servers didn’t check authenticity of users
Security and Performance

Bulk mails
– Unsolicited bulk mailers take advantage of this
– Decreases performance of server for rightful
users

Relay Restrictions
– Verify that the computer is on the server’s local
network
– Require a local domain return address
– Do not accept mail from other open relay servers
Security and Performance

How about a new SMTP?
– The problem is obvious, so let’s change the
protocol
– No guaranteed way to implement without
creating incompatibilities
– We like the idea of cooperation
– Maybe there’s another way
Security and Performance

Other Security Measures
–
–
–
–
Limit the use of commands
Check the validity of the envelope
Limit the size of the email
Limit the number of emails that may be sent in a given amount
of time
– Log everything
– POP-before-SMTP Authentication

Note that SMTP has no mechanism for privacy (encryption).
– This has to be done at a higher level if needed
– Currently is application specific
Future Projections
Current projects include:
 Sender Policy Framework (SPF)
– Only certain servers are allowed to forward mail from certain domain
names
– Easy to check

New DNS Blackhole Lists
– Narrowly identify specific invalid senders
– Will be viable once a large enough number of servers support this

Spam Filtering
– Intelligent, self-learning software
– Good job of identifying unwanted messages that get through

Greylisting
– Receiving servers make sending servers wait
– Spammers probably won’t come back
– More time means more chances to add the offender to the blackhole list