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 multime-
       dia mail	in MIME	format,	the proposed standard  format  for  multimedia
       Internet	mail.  It is modelled very heavily on the Berkeley "mail" pro-
       gram.  However it shares	NO code	with that program  --  it  is  a  com-
       pletely new implementation.

       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 implemented	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 already familiar to you from	that program.  Subsequent sections fo-
       cus on the enhanced features that  make	this  program  different  than
       Berkeley	mail, notably the ability to include rich text,	multimedia ob-
       jects, 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 con-
       tents of	your message.  Everything you type will	be  included  in  your
       message UNLESS you type a line that begins with the "~" (tilde) charac-
       ter.  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,
       typically  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	basic 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  con-
       sult  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	 char-
       acter  on  the line -- the one that follows the tilde --	is then	inter-
       preted 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 similar 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
       allows 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  con-
       figuration  mechanism  can  even	 make  this  process  reasonably user-
       friendly, but a knowledgable 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.
       Currently, mailto directly supports only	the ISO-8859-* family of char-
       acter sets, which means that it does not	meet the needs of Asian	users,
       in particular.  However,	languages that can not	be  expressed  in  the
       ISO-8859	family can still be included in	the same way non-text data can
       be included.

       These three mechanisms will be discussed	separately in the  three  sec-
       tions that follow.

ENRICHED TEXT
       Mailto  lets you	modify the formatting of your text in a	few simple but
       useful ways.  As	with everything	else, this can be  done	 using	simple
       tilde escapes, 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  un-
       derline	modes  are toggles in the sense	that alternate uses of ~b, ~i,
       and ~u turn bold, italic, or underline mode on or off.  The  justifica-
       tion,  on  the other hand, simply switches between the three justifica-
       tion modes, centering, 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 significance 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  op-
       tions  that will	vary depending on your configuration.  (How to config-
       ure 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
       containing  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	example, 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 "applica-
       tion/octet-stream" will be used.	 For  complete	documentation  on  the
       content-type field, consult the MIME proposed standard, 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 described here, because it will necessarily be site-
       dependent, but such programs 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	signa-
       ture  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 extend-
       ing  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
       consult.	 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 ignored.  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)  pro-
       gram,  and (possibly) a set of optional "flag" values.  The mailto pro-
       gram 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
       assumed	to  be	in  MIME format, including at least a content-type and
       also, if	necessary, a content-transfer-encoding header field.  Compose-
       typed is	necessary if variable information needs	to be conveyed via pa-
       rameters	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
       critical.   The	metamail program uses the first	matching mailcap entry
       to display data.	 Mailto, on the	other hand, offers the user an	alter-
       native  for every mailcap entry that has	a "compose" command.  However,
       it should be noted that mailto will use the content-type	from the mail-
       cap  entry  in  composing 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	entry for displaying and for composing the ba-
       sic types, e.g.:

	image/*; showpicture %s
	image/gif; showpicture %s; compose="xwd	-frame | xwdtoppm | ppmtogif";
       description="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
       metamail(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
       character 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
       character  set,	and  will not allow the	inclusion of non-ASCII charac-
       ters.  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 character set.  This is what you would use
       if  you were on a terminal that actually	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, particularly 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 charac-
       ters.  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	command	"~?+".

       Finally,	certain	languages that can be expressed	in the	ISO-8859  fam-
       ily,  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	Berke-
       ley 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 mod-
       ern
	       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 major	known differences, beyond the  multimedia  enhancements,  that
       might confuse users accustomed to the Berkeley mail program:

       Address	separators:  In	Berkeley mail, addresses are separated by spa-
       ces, which is an	abomination to the mail	gods.  For  backward  compati-
       bility,	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.	Alter-
       nately, any line	that starts with a space or tab	character will be pre-
       ceded 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
       implementation of this feature differs from Mail's in two ways:	First,
       the message 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  in-
       stead 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 com-
       patible 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  separately,  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
       standard	Berkeley mail.

SUMMARY	OF OPTIONS
       -a <charset> -- specifies an alternate character	set in use.  This  had
       better  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
       multiple	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 spa-
       ces, 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 pro-
	       gram to run to paginate output from an interpreter, when	 pagi-
	       nation 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 ev-
       ident, 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  consid-
       ered 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
       purpose 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  per-
       taining to this material	without	the specific, prior written permission
       of an authorized	representative of Bellcore.  BELLCORE MAKES NO	REPRE-
       SENTATIONS  ABOUT  THE ACCURACY OR SUITABILITY OF THIS MATERIAL FOR ANY
       PURPOSE.	 IT IS PROVIDED	"AS IS", WITHOUT ANY EXPRESS OR	 IMPLIED  WAR-
       RANTIES.

AUTHOR
       Nathaniel S. Borenstein

Bellcore Prototype		   Release 1			     MAILTO(1)

NAME | SYNOPSIS | DESCRIPTION | BASIC USE | ENHANCED FEATURES NOT FOUND IN BERKELEY MAIL | ENRICHED TEXT | MULTIMEDIA OBJECT INCLUSION | CONFIGURATION VIA MAILCAP FILES | TEXT IN NON-ASCII LANGUAGES | COMPLETE SUMMARY OF TILDE ESCAPES | SUMMARY OF MAILRC FUNCTIONALITY | OTHER KNOWN DIFFERENCES FROM BERKELEY MAIL | SUMMARY OF OPTIONS | ENVIRONMENT VARIABLES | SEE ALSO | BUGS | COPYRIGHT | AUTHOR

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

home | help