------------------------- Week 08 Notes for CST8165 ------------------------- -Ian! D. Allen - idallen@idallen.ca Remember - knowing how to find out an answer is more important than memorizing the answer. Learn to fish! RTFM! (Read The Fine Manual) Review: ------ - four (maybe five) layers Application, Transport, Network, Physical - TCP and UDP on "top" of IP (means packets go *inside* IP packets) - IP RFC791 is 45 pages - UDP RFC768 is 3 more pages on top of IP - TCP RFC793 is 95 more pages on top of IP - DCCP RFC4340 is 125 pages on top of IP Q: T/F packets get larger as they move down the protocol stack from Layer 4 (Application) down to the Physical media. Debugging C language using gdb ------------------------------ "If you have eight hours to cut down a tree, it is best to spend six hours sharpening your axe and then two hours cutting down the tree." - gdb reference card: http://sources.redhat.com/gdb/download/onlinedocs/refcard.ps.gz - the full manual http://www.gnu.org/software/gdb/ http://www.gnu.org/software/gdb/documentation/ http://sourceware.org/gdb/current/onlinedocs/gdb_toc.html http://sources.redhat.com/gdb/download/onlinedocs/gdb.html - debugging multi-process programs (fork): http://sourceware.org/gdb/current/onlinedocs/gdb_5.html#SEC28 http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gdb/processes.html http://www.delorie.com/gnu/docs/gdb/gdb_26.html http://www.cs.toronto.edu/~maclean/csc209/ddd-gdb-children.html - gdb normally follows the parent; to debug a child process (gdb) set follow-fork-mode child You can put these kinds of init commands in file .gdbinit Q: If you overflow an auto variable buffer in main() and then return, your program faults and dies. If you call exit(), the program doesn't die. In both cases, the program is terminating. Why does "return" fault and the other exit() cleanly? RFC tools by IETF ----------------- http://tools.ietf.org/ - html cross-linked pages - http://tools.ietf.org/html/ - reading tools - Firefox plugin - difference tools - wdiff (word diff) - verification tools - ABNF to regexp converter UDP vs TCP - streams of bytes ----------------------------- http://www.tcpipguide.com/free/t_TCPDataHandlingandProcessingStreamsSegmentsandSequ.htm UDP is message-oriented - fixed size chunks, unreliable TCP is stream-oriented - arbitrary byte stream, reliable UDP and TCP packet header ------------------------- The TCP header is much more complex than the UDP header http://www.ssfnet.org/Exchange/tcp/tcpTutorialNotes.html#TH - has to handle issues dealing with reliability, flow control, congestion - note the peculiar TCP/UDP pseudo-header for checksums - checksum includes the source and destination IP addresses! Q: What purpose is the UDP "pseudo header" used in calculating a checksum? http://tools.ietf.org/html/rfc768 page 2 http://www.postel.org/pipermail/end2end-interest/2005-February/004617.html http://www.postel.org/pipermail/end2end-interest/2005-February/004616.html Q: What purpose is the TCP "pseudo header" used in calculating a checksum? http://tools.ietf.org/html/rfc793 page 16-17 http://www.postel.org/pipermail/end2end-interest/2005-February/004617.html http://www.postel.org/pipermail/end2end-interest/2005-February/004616.html Q: T/F TCP and UDP include the IP layer packet source and destination addresses in their checksum calculations. TCP state transition diagram ---------------------------- http://www4.informatik.uni-erlangen.de/Projects/JX/Projects/TCP/tcpstate.html http://www.ssfnet.org/Exchange/tcp/tcpTutorialNotes.html#ST - client and server both start in the CLOSED state (top of diagram) - graph arrows are labelled with transitions [/] where indicates either an incoming packet with a flag set, (e.g. ACK, FIN) or a deliberate change to another state (e.g. "Passive Open", "Close", "Send"). * The "three-way handshake" for a non-simultaneous connectin opening: - a server is sitting in the LISTEN state - a client does an "active open" 1. client sends: SYN, moves to SYN_SENT 2. server sends: SYN,ACK, moves to SYN_RCVD 3. client sends: ACK, moves to ESTABLISHED 4. server receives ACK and moves to ESTABLISHED Now both processes are in the "ESTABLISHED" state. Q: Give the three-way TCP handshake, showing the role of client and server * A simultaneous open: 1. both send SYN and move to SYN_SENT 2. both send ACK (or maybe SYN,ACK) and move to SYN_RCVD 3. both move to ESTABLISHED - RFC1122 4.2.2.7 says RFC793 has an error on what is sent on the transition from SYN_SENT directly to SYN_RCVD: should be sending SYN,ACK, not SYN http://tools.ietf.org/html/rfc1122 - the corrections suggested by RFC1122 break the simultaneous open! Q: Looking at the TCP state transition diagram, into which state will a program move if it is currently in state SYN_SENT and it receives a TCP packet with just the SYN flag set? When it makes that state transition, what flags will it set in the next outgoing packet? - be familar with interpreting a TCP state diagram in RFC793 - three-way handshake for an asymmetric (non-simultaneous) open - trace a simultaneous open in RFC793 - the corrections suggested by RFC1122 break the simultaneous open! - RFC1122 section 4.2.2.10 says: http://tools.ietf.org/html/rfc1122 "It sometimes surprises implementors that if two applications attempt to simultaneously connect to each other, only one connection is generated instead of two. This was an intentional design decision; don't try to "fix" it." Q: T/F When two systems attempt simultaneous connections with each other, you end up with two separate TCP streams. TCP acknowledgements -------------------- - after the three-way handshake, an open TCP connection communicates with ACK always set - ACKs are cumulative - one number indicates the highest contiguous set of successfully received bytes - no provision for "selective ACK" in vanilla TCP - you can't say you got packets 1, 2, and 5 - "selective ACK (SACK)" capability was added later as a TCP Option - RFC1072/RFC2018 describe the TCP SACK option http://www.tcpipguide.com/free/t_TCPNonContiguousAcknowledgmentHandlingandSelective-4.htm - buffering is possible; use PSH to "push" (flush) data out at either end Q: T/F The single 32-bit TCP header Acknowledgement number lets you know the sequence number of the last successfully received byte of data Q: T/F The single 32-bit TCP header Acknowledgement number allows a machine to selectively acknowledge packets, e.g. byte ranges such as I got packets 1, 2, and 4 (but not 3). Q: T/F Selective Acknowledgment is a TCP option that has to be negotiated TCP Windowing - how it works ---------------------------- http://www.tcpipguide.com/free/t_TCPSlidingWindowAcknowledgmentSystemForDataTranspo.htm http://www.tcpipguide.com/free/t_TCPNonContiguousAcknowledgmentHandlingandSelective.htm - windows allow multiple packets to be waiting acknowledgement - better use of bandwidth; less waiting - http://www.tcpipguide.com/free/t_TCPNonContiguousAcknowledgmentHandlingandSelective.htm - ACK bit says highest byte received is in the 32-bit ACK field - cumulative ACK says *all* previous bytes received OK - basic TCP/IP cannot issue out-of-sequence or selective ACKs (ACK ranges) - you can't say you got packets 1, 2, and 5 - "selective ACK (SACK)" capability was added later as a TCP Option - RFC1072/RFC2018 describe the TCP SACK option - TCP buffering is possible; use PSH to "push" data out at either end - interactive programs need to do this to get good response times Q: The TCP ACK field was sufficent to implement the "selective ACK" enhancment - No, the TCP ACK field can only acknowledge a single byte value; you need multiple byte ranges to implement SACK - these were added as TCP options Fragmentation Considered Harmful -------------------------------- * How does TCP send large amounts of data, if the wires won't? Linux command: ifconfig - shows MTU (Maximum Transmission Unit) size for each interface - raw Ethernet shows limit of 1,500 bytes MTU - other protocols will show other limits (e.g. PPP, PPPoE) Q: Give the MTU for your ethernet card (eth0) and the loopback (lo) - The IP Layer can split packets into "fragments" to pass them through routers that can't handle large packets. - IP packets also have a "Don't Fragment" bit that prevents fragmentation Fragmentation Considered Harmful - Google for this: "fragmentation considered harmful" - www.acm.org/sigs/sigcomm/ccr/archive/1995/jan95/ccr-9501-mogulf1.pdf - SIGCOMM October 1987 - 1. inefficient use of resources "Consider a TCP process that tries to send 1024 data bytes across a route that includes the ARPAnet, which has an MTU of 1006 bytes. The IP and TCP headers are at least 40 bytes long, leading to a total unfragmented IP datagram 1064 bytes in length. To cross the ARPAnet, this will be broken into a 1006 byte fragment, followed by a 78 byte fragment. These short fragments amortize the fixed overhead per ARPAnet packet over very few bytes of data, and the total packet count is much higher than needed. If the sending TCP instead chooses segments that fit in a 1006 byte ARPAnet packet, the total packet count is minimized, and the total overhead is as low as possible." - 2. degraded performance (in reassembly, fragment loss) "When segments are sent that are large enough to require fragmentation, the loss of any fragment requires the entire segment to be retransmitted. This can lead to poorer performance than would have been achieved by originally sending segments that didn't require fragmentation." - 3. lack of efficient reassembly - TCP windowing communicates well the size of receive queue/buffer - but IP has no indication of how many IP fragments are coming! - TCP can ACK the bytes received so far and ship the data up the stack - but TCP works on the *packet* level, not the *fragment* level - not possible to partially ACK an initial sequence of fragments - applications must cooperate with the IP layer in minimizing fragmentation Q: Why should IP fragmentation be avoided? Q: Of the four layers, which common layer is best suited to handling fragmentation avoidance? Q: T/F TCP can ACK each fragment of a packet as it arrives Path Maximum Transmission Unit discovery PMTU RFC1191 - November 1990 - 19 pages - http://tools.ietf.org/html/rfc1191 ftp://ftp.rfc-editor.org/in-notes/rfc1191.txt "This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice." "In this memo, we describe a technique for using the Don't Fragment (DF) bit in the IP header to dynamically discover the PMTU of a path. The basic idea is that a source host initially assumes that the PMTU of a path is the (known) MTU of its first hop, and sends all datagrams on that path with the DF bit set. If any of the datagrams are too large to be forwarded without fragmentation by some router along the path, that router will discard them and return ICMP Destination Unreachable messages with a code meaning "fragmentation needed and DF set" [7]. Upon receipt of such a message (henceforth called a "Datagram Too Big" message), the source host reduces its assumed PMTU for the path." "Unfortunately, the Datagram Too Big message, as currently specified, does not report the MTU of the hop for which the rejected datagram was too big, so the source host cannot tell exactly how much to reduce its assumed PMTU. To remedy this, we propose that a currently unused header field in the Datagram Too Big message be used to report the MTU of the constricting hop. This is the only change specified for routers in support of PMTU Discovery." Q: How does IP PMTU discovery work? Q: What changes were made to the ICMP "Datagram Too Big" message to accommodate PMTU? * Congestion Control Even if packets aren't fragmented, routers can be come congested if too many packets arrive to process. When TCP originated, the only indication that a router is overloaded came when packets started to drop - you couldn't get any advance warning. The Addition of Explicit Congestion Notification (ECN) to IP RFC3168 - September 2001 - 63 pages - http://tools.ietf.org/html/rfc3168 ftp://ftp.rfc-editor.org/in-notes/rfc3168.txt - the Introduction paragraphs (Section 1.) are important "Since TCP determines the appropriate congestion window to use by gradually increasing the window size until it experiences a dropped packet, this causes the queues at the bottleneck router to build up. With most packet drop policies at the router that are not sensitive to the load placed by each individual flow (e.g., tail-drop on queue overflow), this means that some of the packets of latency-sensitive flows may be dropped. In addition, such drop policies lead to synchronization of loss across multiple flows." - vanilla TCP minimizes effect of congestion on *throughput*, not *latency* - but, the mechanism for detecting congestion is lost packets - no mechanism for avoiding lost packets in the first place "Active queue management mechanisms detect congestion before the queue overflows, and provide an indication of this congestion to the end nodes. Thus, active queue management can reduce unnecessary queuing delay for all traffic sharing that queue." Q: T/F Traditional "drop packet" TCP congestion control mechanisms are designed to keep overall throughput high Q: T/F Traditional "drop packet" TCP congestion control mechanisms also keep packet latency to a minimum Q: What advantage does ECN have over traditional "drop-packet" methods for detecting and avoiding congestion? Datagram Congestion Control Protocol DCCP RFC4340 - NEW! March 2006 - 125 pages "The Datagram Congestion Control Protocol (DCCP) is a transport protocol that implements bidirectional, unicast connections of congestion-controlled, unreliable datagrams." - this RFC also contains this important port allocation information: "Port numbers are divided into three ranges. The Well Known Ports are those from 0 through 1023, the Registered Ports are those from 1024 through 49151, and the Dynamic and/or Private Ports are those from 49152 through 65535. Well Known and Registered Ports are intended for use by server applications that desire a default contact point on a system. On most systems, Well Known Ports can only be used by system (or root) processes or by programs executed by privileged users, while Registered Ports can be used by ordinary user processes or programs executed by ordinary users. Dynamic and/or Private Ports are intended for temporary use, including client-side ports, out-of- band negotiated ports, and application testing prior to registration of a dedicated port; they MUST NOT be registered." Q: What range of ports should your experimental application use? Interpreting the RFC documents and the raw protocols ---------------------------------------------------- * The "Requirements for Internet Hosts" documents: RFC 1122 and 1123 http://tools.ietf.org/html/rfc1122 http://tools.ietf.org/html/rfc1123 - RFC1122 and 1123 are clarifications and examples of how the RFCs work - RFC1122 deals with "Communication Layers" - RFC1123 deals with "Application and Support" * The overview discussion document: RFC1127 http://tools.ietf.org/html/rfc1127 - describes the history of the creation of 1122 and 1123 "This group of people struggled with a broad range of issues in host implementations of the Internet protocols, attempting to reconcile theoretical and architectural concerns with the sometimes conflicting imperatives of the real world. The present RFC recaps the results of this struggle, with the issues that were settled and those that remain for future work." "Indeed, many of these are simply restatements or reinforcement of requirements that are already explicit or implicit in the original standards RFC's. Some more cynical members of the working group refer to these as "Read The Manual" provisions. However, they were included in the HR RFCs because at least one implementation has failed to abide by these requirements. In addition, many provisions of the HR RFCs are simply applications of Jon Postel's Robustness Principle [1.2.2 in either RFC]." Q: T/F The two "Requirements for Internet Hosts" documents were written to extend the existing RFCs with new features. Application Protocols --------------------- * RFC1123 - Requirements for Internet Hosts - Application and Support http://tools.ietf.org/html/rfc1123 ftp://ftp.rfc-editor.org/in-notes/rfc1123.txt - RFC1123 reviews and clarifies many major protocols and standards: - TELNET, FTP, TFTP, SMTP, RFC822 (message format), DNS "This RFC enumerates standard protocols that a host connected to the Internet must use, and it incorporates by reference the RFCs and other documents describing the current specifications for these protocols. It corrects errors in the referenced documents and adds additional discussion and guidance for an implementor." "A good-faith implementation of the protocols that was produced after careful reading of the RFC's and with some interaction with the Internet technical community, and that followed good communications software engineering practices, should differ from the requirements of this document in only minor ways. Thus, in many cases, the "requirements" in this RFC are already stated or implied in the standard protocol documents, so that their inclusion here is, in a sense, redundant. However, they were included because some past implementation has made the wrong choice, causing problems of interoperability, performance, and/or robustness." Q: Why was the RFC1123 "Application and Support" document written? Sending electronic mail: SMTP ----------------------------- http://tools.ietf.org/html/rfc2821 - Remember: The protocol and ports used to send email (SMTP) are completely separate from the ports and protocols used to fetch email (POP3, IMAP)! SMTP - Simple Mail Transfer Protocol - RFC821 -> RFC2821 - April 2001 - 79 pages on top of TCP (95 pages) on top of IP (45 pages) - a "PUSH" protocol - sender initiates (HTTP is "PULL" protocol) - http://tools.ietf.org/html/rfc2821 "This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. It consolidates, updates and clarifies, but doesn't add new or change existing functionality of the following: RFC822, DNS, RFC1123" - did not add to or change RFC821; dropped obsolete items Q: T/F RFC2821 replaced RFC821 and added new SMTP functionality * SMTP vs. Message Format - the SMTP *protocol* does not define the format of the *message* - the *message* delivered by the *protocol* has its own description: RFC822 -> RFC2822 "Internet Message Format" (51 pages) - http://tools.ietf.org/html/rfc2822 - the content of the message (including To/From message header lines) is independent of the To/From used in the SMTP protocol! Q: T/F The SMTP protocol RFC defines the format and headers of an email message * SMTP is a readable ASCII protocol on top of TCP - not binary! - you can run it using "nc" or telnet to port 25 - but you can't do it here at Algonquin College! - port 25 blocked leaving the College (must use College servers) - College servers implement long wait times before answering - to discourage spam programs that don't wait as long - SMTP wait times are documented in http://tools.ietf.org/html/rfc1122 "Timeouts are an essential feature of an SMTP implementation. If the timeouts are too long (or worse, there are no timeouts), Internet communication failures or software bugs in receiver-SMTP programs can tie up SMTP processes indefinitely. If the timeouts are too short, resources will be wasted with attempts that time out part way through message delivery." * a sample SMTP session: see Notes file smtp_session.txt Note the difference between the SMTP RFC2821 "envelope" FROM/TO lines and the RFC2822 Message From:/To: lines. The Message From:/To: lines need not be related to the SMTP RFC2821 envelope FROM/TO lines, and application writers are warned not to try to link them: (RFC 2821 Section 7.2) * Extending the original SMTP protocol "HELO" with "EHLO" - orignal SMTP "HELO" greeting had no protocol version number - no way to negotiate options or features - RFC1425 (1993) replaced HELO with new EHLO greeting, allowing extensions - http://tools.ietf.org/html/rfc1425 - awkward way to do protocol versioning - latest version of extensions: http://tools.ietf.org/html/rfc2821 - SMTP extensions (must be registered with IANA) ABNF: ehlo-cmd ::= "EHLO" SP domain CR LF Q: Is the EHLO case-sensitive? Q: Is the domain optional? - HELO vs. EHLO: http://tools.ietf.org/html/rfc2821 "Contemporary SMTP implementations MUST support the basic extension mechanisms. For instance, servers MUST support the EHLO command even if they do not implement any specific extensions and clients SHOULD preferentially utilize EHLO rather than HELO." - response to EHLO: http://tools.ietf.org/html/rfc2821 "Normally, the response to EHLO will be a multiline reply. Each line of the response contains a keyword and, optionally, one or more parameters. Following the normal syntax for multiline replies, these keyworks follow the code (250) and a hyphen for all but the last line, and the code and a space for the last line." - the response to EHLO is a list of options that indicates what optional features this email server offers Q: What SHOULD an SMTP client do if the server refuses EHLO? (RFC2821 section 2.2.1 p.7, section 3.2 p. 16) * Even clever people argue about the interpretation of the RFC documents: - http://www.imc.org/ietf-smtp/old-archive/msg01782.html "Certain individuals have the impression that the correct response to a RSET is ``close the connection'', and insist that RFC-821 backs them up. That seems to be an unusually bizarre interpretation, but by golly they insist that they Following The Standard (TM). It quickly became clear that attempting to reason with such individuals was hopeless." - http://www.imc.org/ietf-smtp/old-archive/msg01783.html "having just reread the text in 821, that construing RSET as a synonym for QUIT must require real creativity (or trying to think with one's head in a normally-uncomfortable position)," - SMTP continuation syntax: every line but the last of a multi-line response contains a "-" immediately following the response number, e.g. $ nc -v localhost smtp localhost.home.idallen.ca [127.0.0.1] 25 (smtp) open 220 elm.home.idallen.ca ESMTP Postfix (idallen@idallen.ca) EHLO idallen.ca 250-elm.home.idallen.ca 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250 8BITMIME Q: How does a SMTP server indicate continuation lines in a reply? * Reading RFC 2821 - the SMTP protocol http://tools.ietf.org/html/rfc2821 The RFC is the final word on the protocol. - note allowed order of SMTP commands p.39 - you cannot reject an address if the HELO/EHLO name doesn't match the IP - note the structure of SMTP reply codes p.40 Q: What is the meaning of the first digit of an SMTP response code? 1yz Positive Preliminary reply (not used in standard SMTP) 2yz Positive Completion reply 3yz Positive Intermediate reply 4yz Transient Negative Completion reply 5yz Permanent Negative Completion reply Q: Do SMTP protocol lines end in CR+LF or just LF? (RFC2821 p.12) Q: Do Internet Message lines end in CR+LF or just LF? (RFC2821 p.12, RFC2822 p.17-18) Q: SMTP commands are given as double-quoted upper-case strings in the RFC 2821. Does this mean they must be upper-case? Q: T/F The space following the three-digit SMTP respose code is mandatory and all clients MUST look for it, failing if it is not found. (RFC 2821 Section 4.2) Q: How must an SMTP client handle new response codes that it doesn't recognize? (RFC 2821 Section 4.2, 4.3.2) Q: T/F SMTP clients can figure out how to proceed based on just the first digit of an SMTP reply code; they can usually ignore the rest. (RFC 2821 Section 4.2, 4.2.1, 4.3.2) Q: T/F You can queue up and send multiple commands to an SMTP server without waiting for any responses. (RFC 2821 Section 4.3.1) Looking at RFC 2821 Section 4.3.2, there are three codes that might be returned by an SMTP server "if the corresponding unusual circumstances are encountered". Clients must be prepared to see these codes in response to any SMTP request. Q: T/F SMTP clients only need to handle the fixed set of requests listed as responses in the RFC document. Q: Looking at RFC 2821 Section 4.5.2, how must clients handle the sending of email message lines that start with a period? Q: What is the maximum length of an email address (local-part plus domain), as passed through the SMTP protocol? (RFC 2821 Section 4.5.3.1) Q: How long may an SMTP server delay before issuing the initial 220 Message greeting? (RFC 2821 Section 4.5.3.2) Q: Based on experience, what is the suggested policy for retrying failed attempts at sending a message? (RFC 2821 Section 4.5.4.1) Q: Should programs attempt to relate the MAIL and RCPT (envelope) email addresses with the addresses (that may be) present in the headers of the message body? (RFC 2821 Section 7.2) A Perl SMTP Client ------------------ Creating a TCP connection to a socket using Perl: - programming in C: lots of messy code and buffer management - C has poor string parsing and handling - C requires programmer to do memory management - need to handle time-out with select() or signals (SIGALRM!) - nc and telnet expect a Unix tty, not a process pipe An easier TCP client: using Perl modules - Perl raw (non-module) clients and servers look similar to C language: http://www.perl.com/doc/manual/html/pod/perlipc.html#Internet_TCP_Clients_and_Servers - getservbyname() looks up character string in /etc/services for you - getprotobyname() looks up character string in /etc/protocols for you - Perl's inet_aton does host name and DNS lookups for you! $ip = inet_aton("idallen.ca"); Perl has higher-level modules to simplify coding even further: "For those preferring a higher-level interface to socket programming, the IO::Socket module provides an object-oriented approach." - recall the earlier example of a Perl socket client http://www.perl.com/doc/manual/html/pod/perlipc.html#Interactive_Client_with_IO_Sock - look at a sample Perl server using the Perl IO::Socket module: http://www.perl.com/doc/manual/html/pod/perlipc.html#TCP_Servers_with_IO_Socket * Using the Perl module Net::Telnet - another module to simplify coding of interactive socket applications - this module is easiest way to implement a Perl SMTP client http://www.perlfect.com/articles/telnet.shtml http://search.cpan.org/search?module=Net::Telnet http://search.cpan.org/~jrogers/Net-Telnet-3.03/lib/Net/Telnet.pm SMTP Reference: http://tools.ietf.org/html/rfc2821 Reference: "man Net::Telnet" or see notes file perl_net_telnet.txt http://www.perlfect.com/articles/telnet.shtml http://search.cpan.org/search?module=Net::Telnet http://search.cpan.org/~jrogers/Net-Telnet-3.03/lib/Net/Telnet.pm Q: T/F The Net::Telnet module already converts LF to CR+LF on output to the remote server and converts CR+LF to LF in input from the server. (Look for the RTFM explanation under "binmode") - see the Perl and SMTP examples posted in the course notes: SMTP Client Template: smtpclient_v1.pl Reading STDIN with Perl: read_stdin.pl SMTP client session: smtp_session.txt - see "man Getopt::Long" for parsing command-line arguments.