Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
MAILTO(1)		     General Commands Manual		       MAILTO(1)

NAME
     mailto - Simple mutlimedia mail sending program

SYNOPSIS
     mailto  [-a] [-c] [-s] [recipient name(s)]

DESCRIPTION
     The  mailto  program is a very simple user interface for sending multimedia
     mail in MIME format, the proposed standard format for  multimedia	Internet
     mail.  It is modelled very heavily on the Berkeley "mail" program.  However
     it  shares  NO code with that program -- it is a completely new implementa-
     tion.

     As its name implies, mailto is for sending mail, not for reading it.   None
     of  the mail-reading features of the Berkeley mail program have been imple-
     mented in mailto.

     Users who are already familiar with using the Berkeley mail command to send
     mail should skip the following section, which explains things that are  al-
     ready  familiar to you from that program.	Subsequent sections focus on the
     enhanced features that make this program different than Berkeley mail,  no-
     tably  the  ability  to  include rich text, multimedia objects, and text in
     non-ASCII languages such as Hebrew or Russian.

BASIC USE
     [THIS SECTION MAY BE SAFELY SKIPPED BY READERS ALREADY  FAMILIAR  WITH  THE
     BERKELEY MAIL PROGRAM.]

     The  basic  operation  of mailto is very simple.  If you just type "mailto"
     you will be asked for a list of mail  recipients  ("To:")	a  mail  subject
     ("Subject:") and possibly a list of people to receive a carbon copy of your
     message  ("CC:").	 Alternately, you can specify all of these things on the
     command line.  The "-s" option be used to specify the subject, and the "-c"
     option can be used to specify the carbon copy address.  All  other  command
     line  arguments are added to the To list.	Thus the following command sends
     mail to nsb and jxr, with a subject of "Test message" and a carbon copy  to
     kraut:

     mailto nsb jxr -s "Test message" -c kraut

     For  the convenience of users accustomed to mail readers in which names are
     separated by commas, you may optionally follow each address with  a  comma,
     but this is not required.

     After  these preliminaries are taken care of, you just type in the contents
     of your message.  Everything you type will be included in your message  UN-
     LESS  you	type  a line that begins with the "~" (tilde) character.  Such a
     line is known as a TILDE ESCAPE, and can be used to give  special	commands
     to the mailto program, as will be discussed shortly.

     When  you	are  done composing your message, you can cause it to be sent to
     the intended recipients by simply typing the end-of-file  character,  typi-
     cally  CONTROL-D.	 Depending on your option settings, you may also be able
     to send the mail by typing "." alone on a line, or by typing "~.".

     That's all that you really need to know in order to send mail with  mailto.
     However,  in  order  to  use it to its fullest, you will also want to learn
     about some of the tilde escapes.  In this section, we describe the most ba-
     sic ones, which the mailto program shares in common with the Berkeley  mail
     program.	 In  subsequent  sections, we will describe the more interesting
     tilde escapes which are unique to mailto.

     If anything in this section seems cryptic, it might be helpful  to  consult
     the  man  page  for the mail(1) program, since the user interfaces are very
     similar.

     Any line that starts with a tilde is a tilde escape.  The second  character
     on  the  line -- the one that follows the tilde -- is then interpreted as a
     special command to the mailto  program.   The  simple  tilde  escapes  that
     mailto and mail have in common are as follows:

	 ~? Show help on tilde escapes
	 ~! Shell escape (e.g. "~! ls")
	 ~~ Enter text line starting with a tilde.  The tilde
	     "quotes" itself, allowing you to input a line of
	     text that starts with a tilde.
	 ~. Send the mail and exit
	 ~c Add to CC list (e.g. "~c nsb")
	 ~d Read in the contents of "~/dead.letter"
	     (or a named file, "~d filename")
	 ~e Edit the message being composed using the
	     editor named by the EDITOR environment variable.
	 ~h Edit the To, Subject, and CC headers
	 ~p Print out the message so far
	 ~q Quit, copying the draft to ~/dead.letter
	 ~r Read the named text file into the message
	 ~s Reset the subject header
	 ~t Add to the To list
	 ~v Edit the message being composed using the
	     editor named by the VISUAL environment variable
	 ~w Write the message being composed to a named file
	     (e.g. "~w filename")

     You can also control the behavior of the mailto program to a limited extent
     by  putting  commands  in	a  file in your home directory called ".mailrc".
     These commands include the ability to define aliases for commonly used mail
     addresses.  See the section  entitled  "SUMMARY  OF  MAILRC  FUNCTIONALITY"
     later in this man page.

ENHANCED FEATURES NOT FOUND IN BERKELEY MAIL
     The  main difference between mail and mailto is that the latter can be used
     to generate enhanced mail in MIME format, the proposed standard format  for
     Internet  multimedia mail.  However, mailto is intended to be a very simple
     multimedia mail generator.  There are, accordingly, lots of things it can't
     do. However, it has the virtues of being extremely simple, extremely  simi-
     lar  to  a  well-known  program  (mail), and highly configurable, using the
     "mailcap" file mechanism to be described below.

     Basically, mailto can include the following things in mail:

     1.  Simple formatted text, using the MIME type "text/richtext".   This  al-
     lows  you	to  add  emphasis  to your message using underlining, bold text,
     italic (diaplsyed as reverse video), centering, and the like.

     2.  Non-text data.  Metamail can include pictures, sounds, and  other  non-
     textual  data in the middle of any mail message.  The mailcap configuration
     mechanism can even make this process reasonably user-friendly, but a knowl-
     edgable user can include non-textual data even in the absence of  a  proper
     mailcap entry.

     3.   Text	including non-ASCII characters, such as Hebrew or Russian.  Cur-
     rently, mailto directly supports only the ISO-8859-*  family  of  character
     sets,  which  means that it does not meet the needs of Asian users, in par-
     ticular.  However, languages that can not be expressed in the ISO-8859 fam-
     ily can still be included in the same way non-text data can be included.

     These three mechanisms will be discussed separately in the  three	sections
     that follow.

ENRICHED TEXT
     Mailto lets you modify the formatting of your text in a few simple but use-
     ful ways.	As with everything else, this can be done using simple tilde es-
     capes, as described by the following list:

	 ~b Toggle bold mode (turn bold on or off)
	 ~i Toggle italic mode (turn italic/reverse-video on or off)
	 ~j Alter Justification, in particular:
	     ~jc Center subsequent text
	     ~jl Make subsequent text flush-left
	     ~jr Make subsequent text flush-right
	 ~k Toggles whether or not a "blind" copy of the message will be kept.
	 ~n Force newline (hard line break)
	 ~u Toggle underline mode (turn underline on or off)
	 ~> Indent Left Margin
	 ~< Unindent Left Margin
	 ~<R Indent Right Margin
	 ~>R Unindent Right Margin
	 ~Q Toggle quotation (excerpt) mode
	 ~z Add the contents of ~/.signature as a TEXT signature

     Some  of  these may require a little explanation.	Bold, italic, and under-
     line modes are toggles in the sense that alternate uses of ~b, ~i,  and  ~u
     turn  bold, italic, or underline mode on or off.  The justification, on the
     other hand, simply switches between the three justification modes,  center-
     ing, left justified, and right justified.

     To  understand  the  "~n" command, it must first be noted that rich text is
     automatically justified, so that the line breaks you type have no more sig-
     nificance than space characters.  This allows the text to be displayed more
     nicely on variable-width windows.	(An exception is when you type	multiple
     blank  lines, in which case the line breaks become real.)	The "~n" command
     may be used to foce a line break.	Remember that you can see what your mail
     looks like at any time using the "~p" command.

     Quotation mode, as toggled by "~Q", is useful for formatting excerpts.  If,
     for example, you turn on quotation mode, insert a file, and then  turn  off
     quotation	mode,  the  contents  of the file will be considered an excerpt.
     Most viewers will show excerpts as indented and/or preceded with  ">  "  to
     set them apart from the rest of the text.

     Finally, "~z" simply includes your text signature file, but formats it as a
     "signature",  which many richtext viewers will display in a smaller font or
     otherwise set it off from the rest of your message.

MULTIMEDIA OBJECT INCLUSION
     The basic command for inserting multimedia objects in a mailto  message  is
     "~*".   When you type this command, you will be give a list of options that
     will vary depending on your configuration.  (How  to  configure  this  list
     will be described below.)	 For example, it might look something like this:

      Please choose which kind of data you wish to insert:

      0: A raw file, possibly binary, of no particular data type.
      1: Raw data from a file, with you specifying the content-type by hand.
      1: An audio clip
      2: Data in 'application/andrew-inset' format
      3: An X11 window image dump
      4: An interactive mail-based survey

     Of  these	options, only the first two, options 0 and 1, will appear at all
     sites and in all configurations.

     If you choose options 0 or 1, you will be asked for the name of a file con-
     taining data you wish to include.	(If you enter something that starts with
     "|", you are including the output of a command rather than the contents  of
     a	file.)	 If  you choose option 1, you will also be asked for the correct
     "content-type" name that describes that type  of  data.   The  content-type
     values  are  defined  by  the MIME standard, and are typically type/subtype
     pairs that describe the general data type and its specific format.  For ex-
     ample, a picture in GIF format has a content-type of  "image/gif",  and  an
     audio  clip in basic u-law format has a content-type of "audio/basic".  For
     option 0, the type "application/octet-stream" will be used.   For	complete
     documentation  on	the  content-type field, consult the MIME proposed stan-
     dard, RFC 1341.

     More commonly, however, at a well-configured site you will not need to know
     anything about content-types,  because you will choose one of the	non-zero
     options.  In these cases, a program will run that will allow you to compose
     data  of  the given type.	The user interface to this process cannot be de-
     scribed here, because it will necessarily be site-dependent, but such  pro-
     grams are generally designed to be easy for novice users.

     An  extra mailto command that is useful for including multimedia objects is
     the "~Z" command.	This can be used to include a multimedia signature file.
     The signature file should be a complete MIME-format file, with  a	Content-
     type header field at the top.

CONFIGURATION VIA MAILCAP FILES
     NOTE:   This  section is intended for those who are interested in extending
     the behavior of mailto to easily include new types of mail.  Users at well-
     administered sites are unlikely to need to do this very often, as the  site
     administrator will have done it for you.

     For  a  more complete explanation of the mailcap mechanism, consult the man
     page for metamail(1).  Here we summarize  only  those  aspects  of  mailcap
     files that are relevant to configuring the mailto program.

     First of all, mailto uses a search path to find the mailcap file(s) to con-
     sult.   Unlike  many path searches, mailto will always read all the mailcap
     files on its path.  That is, it will keep reading mailcap	files  until  it
     runs  out	of them, collecting mailcap entries.  The default search path is
     equivalent to

     $HOME/.mailcap:/etc/mailcap:/usr/etc/mailcap:/usr/local/etc/mailcap

     It can be overridden by setting the MAILCAPS environment  variable.   Note:
     mailto  does  not actually interpret environment variables such as $HOME or
     the "~" syntax in this path search.

     The syntax of a mailcap file is quite simple, at least compared to  termcap
     files.   Any  line  that starts with "#" is a comment.  Blank lines are ig-
     nored.  Otherwise, each line defines a single mailcap entry  for  a  single
     content  type.  Long lines may be continued by ending them with a backslash
     character, \.

     Each individual mailcap entry consists of a content-type  specification,  a
     command  to  be  executed on reading, typically by the metamail(1) program,
     and (possibly) a set of optional "flag" values.  The mailto program is only
     interested in mailcap entries that have either  or  both  of  the	optional
     "compose"	or  "composetyped" or "edit" flags.  The compose flag is used to
     tell mailto about a program that can be used to compose data in  the  given
     format,  while the edit flag can be used to tell mailto how to edit data in
     the given format.	Thus, for example the following mailcap entry  describes
     how to compose and edit audio data:

     audio/basic;  showaudio  %s; compose=audiocompose %s; edit=audiocompose %s;
     description="An audio clip"

     The "composetyped" flag is just like compose, except that its output is as-
     sumed to be in MIME format, including at least a content-type and also,  if
     necessary,  a content-transfer-encoding header field.  Composetyped is nec-
     essary if variable information needs to be conveyed via parameters  in  the
     content-type field.

     The  optional  "description"  field  is  used  in composing the prompt that
     mailto prints in response to the "~*" command.  The compose program is used
     to compose data in this format, and the edit program is used to  edit  data
     in  this format.  In each of these, any occurrence of "%s" will be replaced
     by the name of the file to be composed or edited.	If there is no	"%s"  in
     the  compose command, it is equivalent to having "> %s" appended to the end
     of the compose command.

     Note that the order in which things appear in mailcap files is highly crit-
     ical.  The metamail program uses the first matching mailcap entry	to  dis-
     play  data.   Mailto, on the other hand, offers the user an alternative for
     every mailcap entry that has a "compose" command.	However,  it  should  be
     noted  that mailto will use the content-type from the mailcap entry in com-
     posing content-type headers.  Therefore, compose and edit	commands  should
     NOT  be  specified  on wildcard mailcap entries.  If you have a program can
     display lots of different subtypes, you should probably make a separate en-
     try for displaying and for composing the basic types, e.g.:

      image/*; showpicture %s
      image/gif; showpicture %s; compose="xwd -frame | xwdtoppm | ppmtogif"; de-
     scription="An X11 window image dump in GIF format"
      image/x-xwd; showpicture %s;  compose="xwd  -frame";  description="An  X11
     window image dump in XWD format"

     For  more	information on the mailcap file format and syntax, see the meta-
     mail(1) man entry.

TEXT IN NON-ASCII LANGUAGES
     Mailto provides rudimentary support for the composition  of  mail	in  non-
     ASCII  character sets.  Currently, it supports the ISO-8859 family of char-
     acter sets.  These character sets all have the nice property that they  are
     proper  supersets of ASCII.  That is, all ASCII characters are identical in
     all of the ISO-8859 character sets.  When you use one  of	these  character
     sets, then, you can still type all ASCII characters as normal.

     By default, however, mailto assumes that you are using the US-ASCII charac-
     ter set, and will not allow the inclusion of non-ASCII characters.  To tell
     mailto  that  you are using a terminal or terminal window that supports one
     of the ISO-8859 character sets, you can use the -a switch or the MM_CHARSET
     environment variable.  For example, typing  "mailto  -a  ISO-8859-8"  tells
     mailto  that your terminal understands ISO-8859-8, the ASCII+Hebrew charac-
     ter set.  This is what you would use if you were on a terminal  that  actu-
     ally  understood  this character set.  If you're using a window system such
     as X11, you'll also need to be sure that your terminal  emulator  is  using
     the  right  font.	Thus if you have a font named "heb6x13", you can start a
     compatible xterm and mailto to send mixed	English/Hebrew	mail  using  the
     command "xterm -fn heb6x13 -e mailto -a iso-8859-8".  In general, having an
     installed font with the same name as the character set is a good idea, par-
     ticularly if you're using shownonascii(1).

     Once you've got mailto started up using the right character sets, there are
     two ways to enter non-ASCII characters.  The first, and by far the easiest,
     is  to  use  the keys as marked, if you're on a physical terminal that uses
     one of these character sets.  However, if you're  using  a  standard  ASCII
     keyboard,	as most X11 users do, you need some other way to enter non-ASCII
     characters.  To permit this, mailto has an "eight bit mode".  In eight  bit
     mode, all printable characters that you type have the eighth bit turned on,
     thus  turning them into non-ASCII characters.  You can enter eight bit mode
     using the tilde escape "~+", and you can leave it using "~-".  To	see  the
     mapping from your keyboard to eight-bit-mode characters, just give the com-
     mand "~?+".

     Finally,  certain	languages  that can be expressed in the ISO-8859 family,
     notably Hebrew and Arabic, go from right to left rather than left to right.
     To ease the composition of text in these languages, mailto has a "right  to
     left"  mode.   This  mode is toggled on or off using the "~^" command.  For
     added convenience, the right-to-left mode and eight-bit-mode can be toggled
     on and off together using a single command, "~S" (Semitic mode).

COMPLETE SUMMARY OF TILDE ESCAPES
     For easy reference, here is a complete summary of the tilde escapes in  the
     mailto program:

	 ~? Show help on tilde escapes
	 ~! Shell escape
	 ~~ Enter text line starting with a tilde
	 ~. Send the mail and exit
	 ~/ Set maximum size before message is split into
	     multiple parts
	 ~?+ Show help on extended (eight-bit) characters
	 ~> Indent Left Margin
	 ~< Unindent Left Margin
	 ~<R Indent Right Margin
	 ~>R Unindent Right Margin
	 ~+ Enter 8-bit mode for non-ASCII characters
	 ~- Leave 8-bit mode (return to ASCII)
	 ~^ Toggle
	 ~* Add non-text data (pictures, sounds, etc.) as a new
	     MIME part (try it!)
	 ~b Toggle bold mode
	 ~c Add to CC list
	 ~d Read from dead.letter (or named file, ~d filename)
	 ~e Edit message being composed
	 ~h Edit the headers
	 ~i Toggle italic mode
	 ~j Alter Justification (~jc = center, ~jl = flushleft,
	     ~jr = flushright.)
	 ~n Force newline (hard line break)
	 ~p Print out the message so far
	 ~q Quit, copying to dead.letter
	 ~Q Toggle quotation (excerpt) mode
	 ~r Read the named text file into the message
	 ~s Reset the subject
	 ~S Toggle Semitic mode (right-to-left AND eight-bit)
	 ~t Add to To list
	 ~u Toggle underline mode
	 ~v Edit using VISUAL editor
	 ~w Write message to named file
	 ~z Add the contents of ~/.signature as a TEXT signature.
	 ~Z Add the contents of ~/.SIGNATURE as a NON-TEXT
	     (MIME-format) signature.

SUMMARY OF MAILRC FUNCTIONALITY
     The  .mailrc  file in your home directory is used to customize the Berkeley
     mail program.  The mailto program is sensitive to some, though not all,  of
     these  customizations.   In particular, you can use the .mailrc file to set
     the following variables (via "set variablename"  or  "unset  variablename")
     that affect mailto's behavior:

	askcc -- controls whether or not you are prompted for a CC list.
	dot -- controls whether or not a period alone on a line
	     should be interpreted as terminating your mail
	ignore -- controls whether or not interrupts are ignored
	verbose -- controls the verbosity of output from /usr/lib/sendmail
	quiet -- controls the verbosity of output from the mailto program.
	keepblind -- controls whether or not a 'blind' copy of the mail is kept.
       commasonly -- controls whether or not a space character
	      is interpreted as separating mail addresses.  By default,
	     for compatibility with BSD mail, space is interpreted in this way,
	     but the commasonly option makes mailto behave more like a modern
	     Internet mailer in this regard.

     The  other  functionality	implemented by the .mailrc file is personal mail
     aliases.  If you have a friend with a long horrible mail address,	you  can
     put  a  line in your .mailrc file that allows you to refer to him by a more
     friendly name:

	alias	boygeorge    George.Herbert.Walker.Bush%white-house.uucp@nsf-re-
     lay.com

     Mailto  implements  the  alias  feature in a manner that is compatible with
     Berkeley mail.  Moreover, it also knows how to read ".AMS_aliases" files as
     used by CMU's Andrew system, so that Andrew users do not need  to	maintain
     two different alias files in order to use both Andrew and mailto.

OTHER KNOWN DIFFERENCES FROM BERKELEY MAIL
     Although  this program was modelled on Berkeley mail, its user interface is
     inevitably not identical with that program.   What follows is a list of ma-
     jor known differences, beyond the multimedia enhancements, that might  con-
     fuse users accustomed to the Berkeley mail program:

     Address  separators:  In  Berkeley mail, addresses are separated by spaces,
     which is an abomination to the mail gods.	For backward compatibility, this
     also works in mailto, but right-thinking people may use commas instead.

     Newline semantics: Unlike Berkeley mail, in mailto single line  breaks  are
     generally	regarded  as "soft".  This means that your message may be filled
     and/or justified when it is seen by the recipient.   Explicit  line  breaks
     can  be  added  using  the  "~n" command.	Multiple consecutive line breaks
     typed by the user WILL have the desired effect.  Alternately, any line that
     starts with a space or tab character will be preceded by a line break.

     Inclusion of dead.letter files: The "~d" command is  used	to  include  the
     contents of the file "dead.letter" in the current message.  Mailto's imple-
     mentation of this feature differs from Mail's in two ways:  First, the mes-
     sage  is  included  as  an  encapsulated message rather than as plain text.
     While this may sometimes be inconvenient, it allows multimedia  dead.letter
     files   to  be retrieved properly.   Second, the "~d" command in mailto can
     take an argument, which is the name of a file to use instead of the default
     "~/dead.letter".

     Incompatibilities with Sun's version: Sun Microsystems (and no  doubt  many
     other  vendors  with  whom  the  author is less familiar) have enhanced the
     Berkeley mail command in several ways, a few of which  are  not  compatible
     with  mailto.   In particular, the "~b," "~i,  and "~<" commands, at least,
     are different in mailto than in Sun's version.

     Potential for failure in ~p: In the standard Berkeley mail program,  it  is
     inconceivable  that  "~p"	would ever fail.  In mailto, ~p works by calling
     the metamail(1) program.  If metamail is not on the user's search path,  ~p
     will not work.

     Extended  alias searching: The mailto program reads both the aliases in the
     .mailrc file, as does Berkeley mail, and those in the .AMS_aliases file, as
     used by CMU's Andrew Message System.

     Altered editing behavior: The ~e and ~v commands, which are  used	to  edit
     the  message  being composed, will behave differently in mailto if the mail
     includes non-text portions.  In such cases, each part will be edited  sepa-
     rately,  in sequence, which makes it impossble for the user to accidentally
     mess up the inter-part boundaries.  Moreover, if the mailcap  entry  for  a
     given data type includes an "edit" field, the user will be given the choice
     of  editing  with	the program named there or editing with his usual (text)
     editor.  In most cases, this will be a choice between  using  a  structured
     editor or editing the raw data stream.

     Altered behavior for large messages: Mailto delivers your message using the
     splitmail(1)  program.   This  is done so that large messages will be split
     into a set of smaller parts in a MIME-compliant way, so that  MIME  readers
     can  automatically  reassemble  them upon receipt.  By default all messages
     over 100Kbytes are split, but this can be controlled  using  the  SPLITSIZE
     environment variable.  See the splitmail(1) man page for more information.

     New  -r command-line option The -r comand-line option is not found in stan-
     dard Berkeley mail.

SUMMARY OF OPTIONS
     -a <charset> -- specifies an alternate character set in use.  This had bet-
     ter be the one your terminal is actually using.  Currently it  must  be  in
     the iso-8859 character set family.

     -c  name -- specifies a name for the CC field.  If you want to include mul-
     tiple values, you'll need to quote the name, as in -c "name1, name2, name3"

     -r message-id -- specifies a message-id to be used in constructing  an  In-
     Reply-To header field.

     -s  subject  -- specifies the subject for the mail.  If it includes spaces,
     it will need to be surrounded by double quotes as well.

ENVIRONMENT VARIABLES
     MAILCAPS
	     This variable can be used to override the default path  search  for
	     mailcap files.

     PAGER   If  set,  this variable overrides "more" as the name of the program
	     to run to paginate output from an interpreter, when pagination  has
	     been requested.

     MM_CHARSET
	     This  variable  can be used instead of the -a switch to tell mailto
	     that your terminal (or terminal emulator)	implements  a  character
	     set other than US-ASCII.

     TERM    This  variable  tells  mailto  what your terminal type is.  This is
	     used in conjunction with the termcap(5) facility to figure out  how
	     to  do  bold  characters, reverse video, underlining, or other neat
	     stuff on your terminal.

     EDITOR  This variable names the editor mailto will use when you  ask  (with
	     ~e) to edit the message you are composing.

     VISUAL  This  variable names the visual editor mailto will use when you ask
	     (with ~v) to edit the message you are composing.

SEE ALSO
     metamail(1),  mmencode(1),  richtext(1),  audiocompose(1),  getfilename(1),
     mailto-hebrew(1), splitmail(1), shownonasci(1)

BUGS
     Currently,  fgets	is  used  to get each line of input.  An intelligent re-
     placement, in which the effects of right-to-left mode, eight-bit-mode,  and
     the  margin-  and	justification-related commands were immediately evident,
     would be a big improvement.

     Although this program was modelled on Berkeley mail, its user interface  is
     inevitably  not  identical  with that program.  The section entitled "OTHER
     KNOWN DIFFERENCES FROM BERKELEY MAIL," above, might be considered	by  some
     to be an extension of this "BUGS" section.

COPYRIGHT
     Copyright (c) 1992 Bell Communications Research, Inc. (Bellcore)

     Permission  to use, copy, modify, and distribute this material for any pur-
     pose and without fee is hereby granted, provided that the	above  copyright
     notice  and  this permission notice appear in all copies, and that the name
     of Bellcore not be used in advertising or publicity pertaining to this  ma-
     terial without the specific, prior written permission of an authorized rep-
     resentative of Bellcore.  BELLCORE MAKES NO REPRESENTATIONS ABOUT THE ACCU-
     RACY  OR  SUITABILITY OF THIS MATERIAL FOR ANY PURPOSE.  IT IS PROVIDED "AS
     IS", WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES.

AUTHOR
     Nathaniel S. Borenstein

Bellcore Prototype		    Release 1			       MAILTO(1)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=mailto&sektion=1&manpath=FreeBSD+Ports+15.1.quarterly>

home | help