F=r flags are similar in their implementation
but can differ in their result. Consider, for example, the SunOS 4.x version
of /bin/mail. That program expects
-r command-line argument to specify the sender's name.
F=r flag correctly causes mail
to be seen as being from the sender (
but mistakenly using the
F=f flag invokes
-f sender instead.
This fails, because the SunOS 4.x version of /bin/mail expects
-f command-line argument to mean that it should
interactively read mail from the mailbox named sender.
A common problem with SysV versions of /bin/mail is its annoying habit
of prepending a "
From " line to the beginning of
each message, even if one is already there. This confuses
users, because it makes their mail appear to come from uucp
or daemon instead
of the real sender.
The problem stems from the fact that the SysV /bin/mail lacks
-r command-line argument (or its equivalent) to indicate
who the sender is. Instead, that program assumes that the sender's
identity can be taken from the identity of the person who ran the program.
This works correctly with local mail; but when mail comes in from
the outside world, /bin/mail is being run by
root, daemon, or uucp.
The best fix is to get a newer /bin/mail
from one of the many anonymous FTP sites. A less satisfactory
fix is to delete the
F=n flag from the appropriate (usually
local) delivery agent. This leaves two "
lines, the second prefixed with a
> character (the
 The BSD /bin/mail requires considerable hacking to get it to work on a SysV machine. Alternatives are deliver, the mh suite's slocal, and mail.local that is supplied with the sendmail source distribution.
Never use either the
F=r flags with the
prog delivery agent. That delivery agent usually runs programs
by evoking the Bourne shell, which misinterprets
-f command-line argument tells /bin/sh to disable
-r command-line argument is unknown to /bin/sh.
Both command-line arguments produce the wrong result.