Date: Mon, 20 May 2002 18:50:03 -0700 (PDT) From: Giorgos Keramidas <keramida@FreeBSD.org> To: freebsd-doc@FreeBSD.org Subject: Re: docs/38318: Many typo, grammar, and minor tag patches. Message-ID: <200205210150.g4L1o3R30761@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR docs/38318; it has been noted by GNATS.
From: Giorgos Keramidas <keramida@FreeBSD.org>
To: Chris Pepper <pepper@rockefeller.edu>
Cc: bug-followup@FreeBSD.org
Subject: Re: docs/38318: Many typo, grammar, and minor tag patches.
Date: Tue, 21 May 2002 04:41:17 +0300
On 2002-05-19 23:53, Chris Pepper wrote:
>
Hello Chris, I've only commented on where changes were probably
needed. The rest of the diff looks OK :)
> <sect2>
> <title><filename>/etc/mail/virtusertable</filename></title>
>
> - <para>The <filename>virtualusertable</filename> maps mail for
> + <para>The <filename>virtualusertable</filename> maps mail addresses for
Shouldn't this be `virtusertable' instead of `virtualusertable' to
match the title?
> <application>sendmail</application>-compatible system. If
> applications continue to use
> <application>sendmail</application>'s binaries to try and send
> - e-mail after you have disabled it, the mail may transparently
> - queue forever.</para>
> + e-mail after you have disabled it, the mail may silently
> + wait forever.</para>
Why would they wait forever? Perhaps we could clarify this a bit
more, writing?
e-mail after you have disabled it, the mail may silently
get queued and never be delivered.</para>
> <username>root</username>. The script should also accept the
> - parameters 'start' and 'stop'. So that you could, for example, execute
> + parameters 'start' and 'stop'. The system will execute it with these arguments at start and shutdown time, e.g.,
> <filename>/usr/local/etc/rc.d/supermailer.sh start</filename>
> - or <filename>/usr/local/etc/rc.d/supermailer.sh stop</filename>.
> - The system will call your script using 'start' when the it
> - boots and using 'stop' when the it shuts down.</para>
> + or <filename>/usr/local/etc/rc.d/supermailer.sh stop</filename>; you can also do this manually to start and stop your new MTA.</para>
This changes the original text a lot, and breaks the style of the
original text without sounding a lot better, imho. How about being
just a bit more verbose?
<para> ...
The script should also accept the <literal>start</literal> and
<literal>stop</literal> parameters. At startup time the
system scripts will execute the command</para>
<programlisting>/usr/local/etc/rc.d/supermailer.sh start</programlisting>
<para>which you can also use later on, to manually start the
server. At shutdown time, the system scripts will use the
<literal>stop</literal> option, running the command</para>
<programlisting>/usr/local/etc/rc.d/supermailer.sh start</programlisting>
<para>which you can also use to manually stop the server,
while the system is running.</para>
That is a lot more verbose, but is a small step towards making the
entire thing harder to misunderstand, IMHO. What do you think?
> For this reason, many alternative MTA's provide utilities
> - that implement exactly the same command-line interface
> - that <application>sendmail</application> provides.</para>
> + that implement the <application>sendmail</application> command-line interface exactly.</para>
Why do I not like the replacement text? :/
Apart from style issues, that is.
> - <para>This means that when any of these common commands
> - are run, such as <filename>/usr/bin/sendmail</filename>
> - the program that is actually sitting in that location
> - checks <filename>mailer.conf</filename> and
> - executes <filename>/usr/libexec/sendmail/sendmail</filename>
> - instead. This system makes it easy to change what binaries
> + <para>This means, for example, that when <filename>sendmail</filename> is invoked, <filename>/usr/bin/mailwrapper</filename> is actually executed; mailwrapper checks <filename>mailer.conf</filename>, and based on what it finds there, executes <filename>/usr/libexec/sendmail/sendmail</filename>. This system makes it easy to change what binaries
No thank you. This is way too complicated as a change to even try to
sort it out and see what changed. Can we have another go at this?
> - <para>When the senders' <command>sendmail</command> is trying to
> + <para>When the sender's <command>sendmail</command> is trying to
> deliver the mail it will try to connect to you over the modem
Everyone's sendmail. All the senders' sendmail. :-)
> - this list, providing the user has an account on your
> - system, will succeed. This is a very nice way to allow
> + this list (provided the user has an account on your
> + system), will succeed. This is a very nice way to allow
Looks fine (although I have to admit the coma after the parentheses
looked a bit strange at first). Nice catch :)
> <para>If that is what you see, mail directly to
> <email>yourlogin@example.FreeBSD.org</email> should work without
> - problems.</para>
> + problems (assuming <application>sendmail</application> is running correctly on <hostid role="fqdn">example.FreeBSD.org</hostid>).</para>
I guess wrapping is ok here :)
> freefall MX 20 who.cdrom.com</programlisting>
>
> <para>As you can see, <hostid>freefall</hostid> had many MX entries.
> - The lowest MX number is the host that ends up receiving the mail in
> - the end while the others will queue mail temporarily if
> - <hostid>freefall</hostid> is busy or down.</para>
> + The lowest MX number is the host that receives mail directly if available; if it's not accessible for some reason, the others (sometimes called <quote>backup MXes</quote>) accept messages temporarily, and pass it along when a lower-numbered host becomes available, eventually to the lowest-numbered host.</para>
and necessary here!
> <para>If you are doing virtual email hosting, the following
> - information will come in handy. For the sake of an example, we
> + information will come in handy. For the example, we
"For this example ..." ?
--
Giorgos Keramidas - http://www.FreeBSD.org
keramida@FreeBSD.org - The Power to Serve
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200205210150.g4L1o3R30761>