NAME DMail SYNOPSIS DMail go into mail shell if mail pending DMail -O go into mail shell whether you have mail or not DMail path mail somebody (go directly to mail editor) DMail -f file use a file other than your default mail box There are other options. To get a complete list of options enter 'DMail -O' at a CLI prompt, then at the mail prompt enter the 'help' command. The file MAN:dmail.help must exist for dmail's online help to work! This file exists in the boot floppy's man directory. DMail's online help is *EXTENSIVE* and quite flexible. You need only specify a fragment of what you are looking for and the help command will do its best to find the appropriate commands. NOTE: The USER enviroment variable overrides any UULIB:Config based enviroment variable. DESCRIPTION DMail is an interactive mail editor that allows you to view and respond to messages in your mail box as well as generate new messages from scratch. DMail has a huge number of commands and options ('set' variables) that cannot be described in a manual entry like this so I leave those to the online help capability. The basic dmail commands are (and these may be abbreviated): type [msgno] type a message reply [msgno] reply to a message Reply [msgno] reply to a message and include original text mail path send new mail to somebody d [msgno] delete a message dt delete current msg and type next one db delete current msg and type previous one list list available messages These are only a few commands out of many. Commands like mail and reply bring up an interactive editor (default is DME but you should be able to use your favorite editor... just change the defaults in UULIB:Config). When sending and replying to email, what you see from the editor is pretty much what you get. If you quit out of the editor without saving the email is aborted. If you save and quit from the editor DMail will scan the message and figure out who to send it to by extracting addresses out of the To:, Cc:, and Bcc: fields. DMail then runs Sendmail to actually send the message (which may wind up queueing it via UUCP to somewhere else). You list the primary recipients of the message in the To: field, separated by commas. you may continue an address list like this: To: blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, Cc: The Cc: field lists carbon-copy recipients of the message... people you want to see the message but for which the message is not primarily meant for. This can be left blank or deleted. The Bcc: field lists blind-carbon-copy recipients of the message. Specifically, the message gets sent to these people but the Bcc: field itself is NOT propogated, so nobody but you knows that the message was also sent to these people. Every message should have a Subject: field, usually a one liner that describes the subject of the message. When replying to a message you usually keep the original message's Subject: line and prepend an 'Re:' to it... normally you do NOT allow Re:'s to build up. I.E. Re: Re: Re: is not considered proper. When using the upper case Reply that includes the original text of the message, please prune out as much as you can to decrease redundant bandwidth. The original most likely has a copy of the original message anyway and the idea is to simply provide a soft reminder to jog the originator's memory. A BLANK LINE ALWAYS SEPARATES THE HEADER LIST FROM THE MESSAGE BODY!!! ADDRESSES DMail attempts to pick the proper return path when you reply to a message and place that path into the To: field for you. DMail does not always get it right. Sometimes it is not possible to get it right. Generally, bang (!) only paths are safe. A bang path lists the machines the message to reach through with the last field being the user on the destination machine. For example: To: fubar!uunet.uu.net!overload!dillon Assuming I talk UUCP to fubar directly my message will be sent first to the machine fubar, then the machine uunet, then the user 'dillon' on overload. When at all possible finding a fully domained machine in a path makes email all the more reliable. For example, To: uunet.uu.net!overload!dillon This is the path to my amiga. Note that the first element in the path is a fully domain'd machine (an address with dots in it). If your Amiga talks to a machine that understands domains (say you connect to a university machine), and assuming you set your 'DefaultNode' entry in UULIB:Config to this machine, a message addressed as above will get to me. BADLY FORMED ADDRESSES Unfortunately, USENET and INTERNET addresses do not mix well. On the INTERNET and address like this: a!b!user@foo.com maps to foo.com!a!b!user Whereas the same address in USENET format: a!b!user@foo.com maps to a!b!foo.com!user If confusion occurs, your best bet is to look at the 'Received:' fields in the mail header (the HEADER command in DMail, but read the online help for the HEADER command before using it). These fields tell you exactly which machines the message got routed through and the order in which it was routed. Try your best to construct a bang (!) only path to the destination. Sending mail directly to an arbitrary address usually doesn't work unless it is fully domained. For example, mail to fnf@fishpond.UUCP (Fred Fish) will fail utterly unless the machine you connect to has a smart mailer and runs the UUCP Pathalias. On the otherhand, using the path: !cs.utexas.edu!asuvax!mcdphx!estinc!fnf will work assuming understands domains. P.S. if your DefaultNode entry in your UULIB:Config file is set properly and assuming the later about your connection to the outside world, you can just email directly through an arbitrary domained name: cs.utexas.edu!asuvax!mcdphx!estinc!fnf Of course, if you have UUCP setup in a small network between a few friends and none of you have access to a major USENET node then you cannot email outside your little group. Refer to the Domains manual page for information on using the UULIB:Domain file to simplify addressing and to automatically route email.