


      MMMMAAAAIIIILLLLAAAADDDDDDDDRRRR((((5555))))                 ((((bbbbssssdddd 4444....2222))))                 MMMMAAAAIIIILLLLAAAADDDDDDDDRRRR((((5555))))



      NNNNAAAAMMMMEEEE
           mailaddr - mail addressing description

      DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
           Mail addresses are based on the ARPANET protocol listed at
           the end of this manual page.  These addresses are in the
           general format

                     user@domain

           where a domain is a hierarchical dot separated list of
           subdomains.  For example, the address

                     eric@monet.Berkeley.ARPA

           is normally interpreted from right to left:  the message
           should go to the ARPA name tables (which do not correspond
           exactly to the physical ARPANET), then to the Berkeley
           gateway, after which it should go to the local host monet.
           When the message reaches monet, it is delivered to the user
           ``eric''.

           Unlike some other forms of addressing, this does not imply
           any routing.  Thus, although this address is specified as an
           ARPA address, it might travel by an alternate route if that
           was more convenient or efficient.  For example, at Berkeley
           the associated message would probably go directly to monet
           over the Ethernet rather than going via the Berkeley ARPANET
           gateway.

           _A_b_b_r_e_v_i_a_t_i_o_n. Under certain circumstances it may not be
           necessary to type the entire domain name.  In general,
           anything following the first dot may be omitted if it is the
           same as the domain from which you are sending the message.
           For example, a user on ``calder.Berkeley.ARPA'', could send
           to ``eric@monet'' without adding the ``.Berkeley.ARPA''
           since it is the same on both sending and receiving hosts.

           Certain other abbreviations may be permitted as special
           cases.  For example, at Berkeley ARPANET hosts can be
           referenced without adding the ``.ARPA'' as long as their
           names do not conflict with a local host name.

           _C_o_m_p_a_t_i_b_i_l_i_t_y. Certain old address formats are converted to
           the new format to provide compatibility with the previous
           mail system.  In particular,

                     host:user

           is converted to

                     user@host



      Page 1                                                   (9010-E)






      MMMMAAAAIIIILLLLAAAADDDDDDDDRRRR((((5555))))                 ((((bbbbssssdddd 4444....2222))))                 MMMMAAAAIIIILLLLAAAADDDDDDDDRRRR((((5555))))



           to be consistent with the _r_c_p(1) command.

           Also, the syntax:

                     host!user

           is converted to:

                     user@host.UUCP

           This is normally converted back to the ``host!user'' form
           before being sent on for compatibility with older UUCP
           hosts.

           The current implementation is not able to route messages
           automatically through the UUCP network.  Until that time,
           you must explicitly tell the mail system which hosts to send
           your message through to get to your final destination.

           _C_a_s_e _D_i_s_t_i_n_c_t_i_o_n_s. Domain names (i.e., anything after the
           ``@'' sign) may be given in any mixture of upper and lower
           case with the exception of UUCP hostnames.  Most hosts
           accept any mixture of case in user names, with the notable
           exception of MULTICS sites.

           _D_i_f_f_e_r_e_n_c_e_s _w_i_t_h _A_R_P_A _P_r_o_t_o_c_o_l_s. Although the UNIX
           addressing scheme is based on the ARPA mail addressing
           protocols, there are some significant differences.

           At the time of this writing the only ``top level'' domain
           defined by ARPA is the ``.ARPA'' domain itself.  This is
           further restricted to having only one level of host
           specifier.  That is, the only addresses that ARPA accepts at
           this time must be in the format ``user@host.ARPA'' (where
           ``host'' is one word).  In particular, addresses such as:

                     eric@monet.Berkeley.ARPA

           are not currently legal under the ARPA protocols.  For this
           reason, these addresses are converted to a different format
           on output to the ARPANET, typically:

                     eric%monet@Berkeley.ARPA

           _R_o_u_t_e-_a_d_d_r_s. Under some circumstances it may be necessary to
           route a message through several hosts to get it to the final
           destination.  Normally this routing is done automatically,
           but sometimes it is desirable to route the message manually.
           Addresses that shows these relays are termed ``route-
           addrs.'' These use the syntax:

                     <@hosta,@hostb:user@hostc>



      Page 2                                                   (9010-E)






      MMMMAAAAIIIILLLLAAAADDDDDDDDRRRR((((5555))))                 ((((bbbbssssdddd 4444....2222))))                 MMMMAAAAIIIILLLLAAAADDDDDDDDRRRR((((5555))))



           This specifies that the message should be sent to hosta,
           from there to hostb, and finally to hostc.  This path is
           forced even if there is a more efficient path to hostc.

           Route-addrs occur frequently on return addresses, since
           these are generally augmented by the software at each host.
           It is generally possible to ignore all but the ``user@host''
           part of the address to determine the actual sender.

           _P_o_s_t_m_a_s_t_e_r. Every site is required to have a user or user
           alias designated ``postmaster'' to which problems with the
           mail system may be addressed.

           _C_S_N_E_T. Messages to CSNET sites can be sent to
           ``user.host@UDel-Relay''.

      SSSSEEEEEEEE AAAALLLLSSSSOOOO
           _m_a_i_l(1), _s_e_n_d_m_a_i_l(1); Crocker, D. H., _S_t_a_n_d_a_r_d _f_o_r _t_h_e
           _F_o_r_m_a_t _o_f _A_r_p_a _I_n_t_e_r_n_e_t _T_e_x_t _M_e_s_s_a_g_e_s, RFC822.




































      Page 3                                                   (9010-E)



