On Mon, 5 Feb 2001, Samuel W. Heywood wrote:

> Were there not some
> facility other than Telnet involved, then it would be a reasonable
> inference that we would be seeing our email clients receiving the
> same kinds of messages and feedback from the server end as we see in our
> Telnet clients during a Telnet session.  The fact that server end feedback
> is not the same when using an email client as when using a Telnet client
> would quite naturally lead one to conclude that the that there is some
> facility other than Telnet doing business at port 25 on the server end,
> and that this other facility may also be used for processing outgoing mail.
> I don't know what this other facility might be called, and I am only
> hypothesizing its existence based on the observations described above.

  It's called SMTP, which stands for Simple Mail Transport Protocol.
A protocol consists of the "rules" for communication.  At the 
TCP/IP level, a protocol consists of which port to listen to
and what commands are valid.
 
  The fact that you don't *see* those commands printed to your
screen is simply the transparent use of said protocol.  If you
want to, you CAN see the entire exchange... using the telnet
program, or some other which records what it receives and sends.

  For example, when I run fetchmail -d 0, I see which server is
being polled, how many messages are there, and a march of periods
across the screen as each message is downloaded.  Here's a typical
run of USER feedback for fetchmail: 

fetchmail: No mail for stackman at pop.delphi.com
6 messages for twovoyag at mail.addr.com (13020 octets).
reading message 1 of 6 (2295 octets) .. flushed
reading message 2 of 6 (1867 octets) . flushed
reading message 3 of 6 (1905 octets) . flushed
reading message 4 of 6 (2348 octets) .. flushed
reading message 5 of 6 (2967 octets) .. flushed
reading message 6 of 6 (1638 octets) . flushed
fetchmail: No mail for stackman at mail.cybertrails.com

  This is merely the "user interface" version of what's going on.  
The authors of fetchmail have (rightly) decided that most users
don't care to defaultly see all the nitty-gritty of what's actually 
being communicated between client and server.

  If I specify that fetchmail report verbosely what it's hearing
and saying, then 'fetchmail -v -d 0' results in a protocol-level
output like this:  (I'm only copying output for ONE server and 
ONE message)  

fetchmail: 5.5.0 querying mail.addr.com (protocol POP3) at Mon, 05 Feb
2001 13:5
0:55 -0500 (EST)
fetchmail: POP3< +OK POP3 addr.com
fetchmail: POP3> USER twovoyag
fetchmail: POP3< +OK User name accepted, password please
fetchmail: POP3> PASS *
fetchmail: POP3< +OK Mailbox open, 1 messages
fetchmail: POP3> STAT
fetchmail: POP3< +OK 1 2201
fetchmail: POP3> LAST
fetchmail: POP3< +OK 0
1 message for twovoyag at mail.addr.com (2201 octets).
fetchmail: POP3> LIST
fetchmail: POP3< +OK Mailbox scan listing follows
fetchmail: POP3< 1 2201
fetchmail: POP3< .
fetchmail: POP3> TOP 1 99999999
fetchmail: POP3< +OK Top of message follows
reading message 1 of 1 (2201 octets)
fetchmail: SMTP< 220 wizard.dyndns.org ESMTP Sendmail 8.9.3/8.9.3; Mon, 5
Feb 20
01 13:51:23 -0500
fetchmail: SMTP> EHLO localhost
fetchmail: SMTP< 250-wizard.dyndns.org Hello IDENT:steve@localhost
[127.0.0.1], 
pleased to meet you
fetchmail: SMTP< 250-EXPN
fetchmail: SMTP< 250-VERB
fetchmail: SMTP< 250-8BITMIME
fetchmail: SMTP< 250-SIZE
fetchmail: SMTP< 250-DSN
fetchmail: SMTP< 250-ONEX
fetchmail: SMTP< 250-ETRN
fetchmail: SMTP< 250-XUSR
fetchmail: SMTP< 250 HELP
fetchmail: SMTP> MAIL FROM:<[EMAIL PROTECTED]> SIZE=2201
fetchmail: SMTP< 250 <[EMAIL PROTECTED]>... Sender ok
fetchmail: SMTP> RCPT TO:<steve@localhost>
fetchmail: SMTP< 250 <steve@localhost>... Recipient ok
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself
#********************.*******fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 NAA13591 Message accepted for delivery
 flushed
fetchmail: POP3> DELE 1
fetchmail: POP3< +OK Message deleted
fetchmail: POP3> QUIT
fetchmail: POP3< +OK Sayonara

  Here, fetchmail has grabbed the mail from a remote POP server 
and delivered it to the SMTP server on my machine which then decides 
who to deliver it to locally.  (After that, procmail decides if it 
goes to spamfolder, arachne, glass, inbox, or wherever, but that's
a separate program rather than anything to do with any protocols.)

  ESMTP is (I think) Extended Simple Mail Transport Protocol,
which simply adds a few new commands to the old SMTP protocol.

  If you send a POP command to an SMTP server, you'll get an
error message.  If you send an NNTP command to a POP server,
you'll also get an error.

  Telnet is in and of itself a protocol, however, you can use it
to specify a port, and then use other protocol commands over it,
thereby manually "emulating" other protocols.

  Hopefully this will clarify the matter.

 - Steve

Reply via email to