reading a mail in SMTP

[dev]

hello all,

can anyone tell me how a client reads mail from a server in SMPT sort of protocol?, as SMTP is a fully command/responce mode based protocol, everything is fine when a client has to send a mail, but what happens if he has to read one?,( though a TURN command is mentioned in RFc, but still not implemented.)

how can we read a mail?, as client has to initate a session, when it has to read a mail, suppose it sends READ(suppose), the server has to responde (by say "OK"). now again it is again clients turn!, but what should he say this time as its the server who has the info he needs!, or should the serevr break the rules of strict command/respode mode and after responding with OK, again send some command like DATA or start sending file ?

is there any way we can read SMTP mail from telnet?

and what would be better - implementing TURN command or breaking the rules?

with thanks
-dev

ps:- i am not working on a strict SMTP, still it helps to understand concepts.

[RobSeace]

SMTP has nothing to do with reading mail... It's designed for
sending and receiving mail... That's all... It accepts incoming
mail for local delivery, and/or accepts outgoing mail for remote
relaying... It has absolutely no method of giving delivered mail
to a client for reading... That's not its purpose... For that, you
want something like POP or IMAP...

[Loco]

dev,

SMTP is a protocol used mostly by MTAs (Mail Transfer Agents) to distribute emails to other MTAs. It's also used by MUAs (Mail User Agent) to send messages to their configured MTA, so that it will take care of the distribution.

There are other protocols for retrieving messages from mailboxes. One of the most widely used is POP3.

It has basically the following command/response sintax:

+OK <POP3 software>
USER <username>
+OK Password required for <username>
PASS <paswsord>
+OK <username> has N messages in M octets
LIST
+OK N messages in M octects
1 <size of message>
2 <size of message>
.
RETR 1
+OK <size of message> octets
<message>

.
DELE 1
+OK message 1 has been deleted
QUIT
+OK <bye bye of some sort>

(Client messages in bold, variable information in <>)

As you can see it's pretty simple:
You open a user mailbox by using the commands USER and PASS.
After authentication, you can LIST the messages, RETRieve them and DELEte them. You can also see part of the messages by using the HEAD command.

Your email client usually does what I wrote here. It RETRieves the messages and deletes them afterwards (although you can configure them not to delete the messages)

The commands are four letter words (or partial words), confirmation from the host is given in the three first characters of the line. If it begins with "+" the response is positive, if it begins with "-" it means the response is negative (you can check for +OK and -ERR). Some commands should expect multiline responses (LIST, RETR, HEAD), the end of the message will be signaled by a "." as the only character in a line (if your mail includes a dot as first character in the line it is usually doubled, you can check it with your mail server)

You can telnet to port 110 where this service is usually configured to listen.

Have fun

[dev]

hi all,

that was helpful of u guys, yea i tried pop3, it cleared a lot of doubts.
that means we need other protocol other than smtp(like pop3) for retriving or reading mails which we have posted using smtp sort of protocol. thus i have to implement the functionallity of both system in my application.

with thanks
-dev

[vikasgp]

In case you're interested, the 'category killer' POP client,(and for many other protocols) is fetchmail(http://catb.org/~esr/fetchmail). It's configuration utility, fetchmailconf, has checks for a lot of POP servers, and also tells you how many of them are broken and/or violate the RFC.

Makes me wonder if the RFCs only give you an idea of what to expect :)

[mlampkin]

Yah... I sometimes think people just can't read... especially since most of the things which are out of spec with the RFCs are not enhancements or anything even close... just dumb mistakes...

If you think the POP impls are bad... you should take a look at some of the http servers... I've written several (commercial) proxy systems... and I swear that half the code has always been stuff needed to compensate for the servers (and clients for that matter) doing things incorrectly...

Ah well... such is life...

Michael

[RobSeace]

I honestly think lots of people just find most RFCs too baroque
and bizarre and hard to read... What with their constant talk of
"octets" (what most normal human beings refer to as "bytes" or
"characters" ;-)), and their complex BNF-like syntax definitions,
and their overly formal tone and layout... Even I don't particularly
enjoy reading most RFCs, and I'm about the geekiest geek I
know of... ;-) They really could do a whole hell of a lot better,
quite frankly... There are some RFCs that aren't quite as
painful to read (the IPv6 RFCs co-written by Richard Stevens
were quite a joy to read, compared to most; most importantly,
they contained lots of actual code examples/demonstrations,
and used pretty straight-forward talk, with no needlessly formal
bullshit in the way)... But, it seems the majority of them tend to
be mind-numbingly boring, and needlessly formal and strange,
and difficult to actually figure out, because they rarely present any
actual working code, or a dump of a sample/demo session (eg: if
defining a protocol), or anything remotely helpful like that...