Tài liệu Lập trình mạng P6 pdf

Email is defined by RFC 821 and RFC 822 ¢¢ Internet email, that is; not to be confused with LAN email such as cc:Mail or MS Mail, which use proprietary protocols “e RFC 821 defines th

- Tim hiễu các giao thức POP3, SMTP, IMAP

- Lập trình gửi nhận mail

Email is defined by RFC 821 and RFC 822

¢¢ Internet email, that is; not to be confused

with LAN email such as cc:Mail or MS Mail,

which use proprietary protocols

“e RFC 821 defines the SMTP protocol

“* How mail MTAs exchange messages

“* RFC 822 defines what a mail message looks

like

How email really works

“Hey, I’ve got some mail here! Anybody home?”

“fyawn) Yeah, yeah, I’m here ”

“This is for Joe Schmoe - you know him?”

“II take it ”

“OK, here it comes!”

“Got it!”

“See ya later!”

“By el 1

SMTP looks exactly like that

S$ telnet/port=25 arizona edu

Trying Connected to ARIZONA.EDU

220 Arizona EDU Server ESMTP (PMDF V4.3-10 #2381)

helo opus1d com

250 Arizona.EDU OK, Ternrnls.O©pusl COM

mail from:<trumbo@opus1 com>

290 Address Ok

rept to:<faceGarizona.edu>

250 face@arizona.edu OK

data

354 Enter mail, end with a single

This is where all the rest of the headers go

The commands are few and specific

$§ telnet/port=25 arizona.edu

Trying Connected to ARIZONA.EDU

220 Arizona EDU Server ESMTP (PMDF V4.3-10 #2381)

helo opusl.com

250 Arizona.EDU OK, Tennis Opusl.CcomM

mail from:<trumboGopusl com>

290 Address Ok

rept to:<face@arizona edu>

250 face@arizona.edu OK

data

354 Enter mail, end with a single

This is where all the rest of the headers go

SMTP reply codes

$ telnet/port=25 arizona edu

Trying Connected to ARIZONA EDU

220 Arizona.EDU Server ESMTP (PMDF V4.3-10 #2381)

helo opusl.com

250 Arizona.EDU OK, Tennis.Opusl.CoM

mail from: <trumbo@opusl com>

250 Address Ok

rept to:<face@arizona edu>

250 face@arizona edu OK

data

354 Enter mail, end with a single "."

This is where all the rest of the headers go

250 Ok

quit

221 Bye received Goodbye

SMTP reply codes

The first digit

indicates success, failure,

In fact, only the reply codes count

Other inform ation in a reply is purely for human consumption

501 Syntax error in parameters or arguments

502 Command not implemented

503 Bad sequence of commands

1- 3 success 220 <domain> Service ready

221 <domain> Service closing transmission channel

421 <domain> Service not available, closing transmission channel

[This may be a reply to any command if the service

knows it must shut down]

4 temp negative

250 Requested mail action okay, completed

354 Start mailinput; end with <CRLF>.<CRLF>

550 Requested action not taken: mailbox unavailable [E.g., mailbox not found, no access]

553 Requested action not taken: mailbox name not allowed

[E.g., mailbox syntax incorrect]

RFC 821 defines all the reply codes

“e The numeric codes are definitive

«* The text Is just for us humans

«* Most mailers follow the RFC821 suggeted

text, but some of them get fun and creative

“* You cant make up new reply codes for a

special situation

«* That's what being a protocol Is all about

The resultant raw mall

Date: Wed, U3 May 1995 19:17:47 -O700 (MST)

Date-warning: Date header was inserted by Arizona.EDU

Beware of vrfy on some mailers

$ telnet/port=25 arizvml.ccit arizona edu

Trying Connected to ARTZVM1I.CCTT.ARTZONA.EDU, an TBM 3090-

SO0E running VM/XA

220 ARIZVM1.ccit.arizona.edu running IBM VM SMTP VZRZ on Sun,

SMTP extension

*¢ After careful consideration, a few extensions have

been added to the SMTP protocol

“* A mailer supporting extensions uses EHLO instead

of HELO in the greeting

“+ The server will respond to indicate it can negotiate

extensions

“+ If the server gives a failure to the EHLO, the client

SMTP reverts back to plain of SMTP

“+ Sometimes called the ‘eight-bit HELO’, but other

extensions are included as well

“* Described in RFC1651

250-SIZE ee ee A mailer that supports

250-XVRB oo a list of which ones it can

quit

221 dbce.mtview.ca.us closing connection

Connection closed by Foreign Host

EHLO with old mailers

Trying Connected to ARIZVM1.CCIT.ARIZONA.EDU, an IBM

3090-300E running VM/XA

220 ARIZVM1.ccit.arizona.edu running IBM VM SMTP V2R2

on Tue, 25 Apr 95 21:09:1T

ehlo arizona.edu

SMTP extension

The non-required SMTP command set:

Service Ext EHLO Keyword Parameters Verb Added Behavior

Send SEND none SEND defined in RFC 821

send orMail SOML none SOML definedin RFC 821

send and Mail SAML none SAML defined in RFC 621

Turn TURN none TURN defined in RFC 821

Later additions, defined in other RFCs:

EHLO RFC1651 “SMTP Service Extensions"

SBITMIME RFC1662 “SMTP Service Extension for 8bit-MIME transport"

SIZE RFC1653, "SMTP Service Extension for Message Size Declaration”

x extensions (defined to be undefined)

RFC-822 Email Headers and How to Read Them

A typical mail message

Received: from mr.decus.org by DECUS.Org (PMDF V4.2-13 #7924)

id <O1LHPLU4NRVKOSAPFGORDECUS.Org>; Fri, 21 Apr 1995 15:53:47 EST

Received: with PMDF-MR; Fri, 21 Apr 1995 15:46:10 GNT

MR-Received: by mta TOPAZ; Relayed; Fri, 21 Apr 1995 15:46:10 +0000

Alternate-recipient: prohibited

A typical mail message

Subject: Seminar 5306

To: trumbo#Opusi1.COM, jms@Opusi.com

Message-id: <E437ZVSNMJWUOT*/ R=TOPAZ/ R=41/ U=CAPUTO/ @MHS>

From: IN$ "SYSTEM@Arizona EDU"

To: INS "trumbo@Arizona EDU"

Date: Thu, 20 Apr 1995 01:00:24 -O7?700 (MST)

Some headers are required Order of headers is not important

Return-path: <SYSTEMGArisona.EDU>

Received: from ärisona.EDU bự Arisona.EDU (PMDF V4.2-10 #2281)

i <01HPJKMXKY1C9JEUK1lGàr izena.EDU>; Thu, 20 Apr 1995 01:00:24 -0700 (MST)

Date: Thu, 20 Apr 1995 01:00:24 -0700 (MST)

From: SYSTEMGArisona EDU

Subject: Scheduler Job #22 (NAME: TMS-CHECK-DAILY-MVS-JOBS) finished,

Status: *NONAME-W-NOMSG, Message number 00000000

Job TMS-CKECK-D AILY-MVS-JOBS complete Blank line separates message body

Status: *NONAME-W-NOMSG, Message nmaumber 00000000

Return-path: <SYSTEMGArisona.EDU>

Received: from ärisona.EDU bự ärisona.FDU (PMDF V4.2-10 #2261)

id <Ol1HP JEMXKY1LC9IJEUKLGArisona.EDU>; Thu, 20 Spr 1995 01:00:24 -0700 (MST)

\

Headers atthe bottom don't count as headers

Origin headers, who it comes from

“* The agent (person, system or process) that

created the message Should be a single, authenticated machine address generated by the sending agent.

Origin headers, who send it

s* Sender [ Resent-Sender |

s+ [he agent (person, system or process) that sends the message

Intended for use when the sender is not the author of the message, oris one of a group of authors Not to be used if identical to From field The Sender fleld must be present if different from the From field

** Used by lists in this way:

From: "Fnts A.M Storms" <STO@MH NL=

sender: INFO-VAX Discussion <INFO-VAX@UGA.BITNET=

To: Multiple recipients of list INFO-VAX <INFO- VAX@UGA.BITNET>

Origin headers, best reply address

“-a mailbox where responses are to be sent, often used by list mail:

From: "Frits A.M Storms" <STO@MH.NL>

Subject: Re: Can Satellite Node Crash-Dump into Page File on

Note how the Reply-to: field is used intelligently

to direct mail to their preferred address

Date header is require

s* Orig-date or Resent-date field

s* Just what it looks like:

Date: Sat, 22 May 1993 05:46:55 +0000 (GMT)

“+ The only optional parts of the date specification are

the day of the week and the seconds

“* Timezone may be given in the usual ways: EST,

EDT, etc, UT, GMT, even military (Z,A,B,M,N)

“+ Timezone is preferred as a numeric offset from

GMT

Class quiz: What do we mean by ‘systems’ here? Is itthe MTA or the MUA that hides the bcc list?

Receive headers

Received: from CGNET.COM by Arizona EDU (PMDF V4.3-9 #2381)

id <O1LHGUMMSOTUOSARTDY@GArizona.EDU>; Thu, 08 Sep 1994

00:39:13 -O700 (MST)

Received: from faop.cgqnet.com by CGNET.COM (PMDF V4.3-9 #7702)

id <O1LHGUMN7N4S000370I@CGNET.COM>; Thu, 08 Sep 1994 00:40:08

Received: by msmail.fao.org with Microsoft Mail id

<ZE7 9C6AC@msmail fao org>;

Thu, O8 Sep 94 09:24:12 +02

Received headers show the path

Received:

Received:

Received:

Received:

from host 2 by host 3

by host 2 from host 1

by host 1 from host O

id <O1LHGUMMSOTUOSARTDY@Ari a.EDU>; Thu, 08 Sep 1994

Received: from{ CGNET COM Arizona.EDU (PMDF V4.3-9 #2381)

host 2 00:39:13 -O700 (MST)

byLCGNET.COM (PMDF V4.3-9# 7702)

id <[L1HGLIMN”? 1328 8L 3 7L T@CGNET.COM>; Thu, O08 Sep 1994 00:40:08 -O7?00 (PDT)

Received: fr lươiu41 1 ao org (191.0.1.130)

by FAOVMS,CGNET COM (EMDF ¥3.3-8 #3703)

ma a.- Thu, 08 Sep 1994

09:25:10 +0200

Received: by msmail fao)eeeg with Microsoft Mail id

<ZE?9C6ACHmsmall tao org;

Thu, O68 Sep 94 09:24:12 +02

Received line information

(MST)

s% Many optional fields:

from sending host

by receiving host

via physical path (predefined values)

with link/mail protocol (predefined values)

id reciever message id

for initial form

“+ And one required field:

date-time timestamp when message received

Received line IP address information

“+ Some mailers check to see that the domain name

in the SMTP HELO command matches the IP

address making the SMTP connection, and put

this verified information in the Received line:

“* RFC1123, Requirements for Internet Hosts,

requires that the receiver MUST NOT refuse to

accept a message, even if the senders HELO

command fails verification.

“+ There is no defined format for message Ids, except

that they be unique identifiers

** Invaluable for determining the source of mailing

Received header often contain the Message ID

“¢ An optional, but widely implemented,

component of the Received line

«e The same information as the orginating

mailers Message-ID field, provided by all the

intermediate mailers that handle the

message

“*Lets you figure out if a repeated message Is

being regenerated by the sender, or if the same message Is being resent by the sender

“* Often lets you figure out which mailer is

mailbombing you

Header usage by mailing list

“* RFC8&22 suggests common sense:

“+ The Sender field should be used instead of the From

field to report errors and problems

“+ The Sender field should NEVER be used automatically,

in a recipients’ s reply message

“+ Replies should go to the Reply-To field instead of the From field

“+ New (nonstandard) headers for mailing lists

“+ Errors-to is an explicit routing for all errors, bounce

messages, etc

“+ Error-Reply is the same thing, it was just made up by somebody else

MIME Multipurpose Internet Mail

Extensions

RFC 1561, RFC 1562,

ec.

What is MINE?

“* MIME stands for Multipurpose Internet Mail

Extensions

“+ MIME defines extensions to SMTP to support

binary attachments of arbitrary format

“+ The designers of MIME have leamed a /of from

the old SMTP protocol and Its mailers

** MIME is here to stay, and it WORKS

“+ MIME requires more capable user agents to

interpret messages

“+ These are widely available now, but they are not

ubiquitous

MINE does two main things

“e MIME encodes binary data so that it can be

passed over the Internet

“Remember that the Internet is a /-bit ASCII world

“Even the 8-bit extensions don't work, because there are issues of line length and file formatting

“e MIME labels encoded data so that the

‘content’ can be properly understood at the

other end

“*For example, “this is a Microsoft VVord document.”

How MINE work

“e Uses a new binary encoding scheme called

BASE64

“e New SMTP headers describe the attached

document

«* User agents read the headers to figure out

how to interpret the message

MINE add new headers

From: Nathaniel Borenstein <nshGbellcore.com-

Subject: Sample message

is a handy place for mail composers to include an

explanatory note to non-MIME conformant readers

This is explicitly typed plain ASCII text

It DOES end with a linebreak

New mail headers

Required fields

MIME-Version

Optional fields

Content-type Content-transfer_encoding Content-ID

Content-description Content-disposition

From: trumbo@Opusi1.COM (Jan Trumbo)

Subject: small message with Word attachment

To: trumbo3Dpus1.CũM

Content-type: MULTIPART/MIXED; BOUNDARY="Boundary [ID nf99lkyavAuSoC1F /HeK0Q]" Boundary [ID n£99lkyaväuSoCIF /HeE00] eH

This identical boundary

Joel, attached is a Word document - Jan marker separates the

Boundary [ID nf991kyavAuSoClF /Hekog] «—— | Parts of the mail message

Date: Thu, 19 Sep 1996 16:49:52 -0700

<Word document and more stuff below here>

Sample message boudary marker seperate each section

Boundary [ID nf991kyavñuSoCIF /HeK00]

Date: Thu, 19 Sep 1996 16:49:52 -0700

{This file must be converted with BinHex 4.0)

<lots of binhex deleted>

Boundary [ID nf991kyavñuSoCIF /HeK00]

Content-type: text/plain; charset=us-ascii

Jan Trumbo, 1404 East Lind Road, Tucson, AZ, 85719

Boundary [ID_nf99lkyavAuSoC1F /HeK0Q] «—— | The last boundary is

marked by ‘ ’on the end

The content type headers

¢«* Content-Type Sub-T ypes Describes what

format this part of the message is In

application video multipart

s% The default type is simple ASCII text

MIME-version: 1.0

Content-type: text/plain; charset=us-ascil

A minimal MINE message

To: trumbo#Opus1.CcoMm

Jan

A MIME-compliant mailer will generate a pair of MIME headers

Content type : application

s*Subtypes

s*Postscript s*octet-stream - unidentified binary data s*Many others will be added

⁄7

These headers allow the Mail User Agent to

intelligently extract and name the attached document