0122-0124.html
来自「linux-unix130.linux.and.unix.ebooks130 l」· HTML 代码 · 共 373 行
HTML
373 行
<HTML>
<HEAD>
<TITLE>Developer.com - Online Reference Library - 0672311739:RED HAT LINUX 2ND EDITION:SMTP and POP</TITLE>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<SCRIPT>
<!--
function displayWindow(url, width, height) {
var Win = window.open(url,"displayWindow",'width=' + width +
',height=' + height + ',resizable=1,scrollbars=yes');
}
//-->
</SCRIPT>
</HEAD>
-->
<!-- ISBN=0672311739 //-->
<!-- TITLE=RED HAT LINUX 2ND EDITION //-->
<!-- AUTHOR=DAVID PITTS ET AL //-->
<!-- PUBLISHER=MACMILLAN //-->
<!-- IMPRINT=SAMS PUBLISHING //-->
<!-- PUBLICATION DATE=1998 //-->
<!-- CHAPTER=07 //-->
<!-- PAGES=0097-0130 //-->
<!-- UNASSIGNED1 //-->
<!-- UNASSIGNED2 //-->
<P><CENTER>
<a href="0119-0121.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0125-0127.html">Next</A>
</CENTER></P>
<A NAME="PAGENUM-122"><P>Page 122</P></A>
<P>The -d21.12 in the preceding example tells
sendmail to turn on level 12 debugging in section 21 of its code. The same command with the option
-d21.36 gives more verbose output (debug level 36 instead of 12).
</P>
<CENTER>
<TABLE BGCOLOR="#FFFF99">
<TR><TD><B>
NOTE
</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
You can combine one or more debugging specifications separated by commas, as in
-d21.12,14.2, which turns on level 12 debugging in section 21 and level 2 debugging
in section 14. You can also give a range of debugging sections, as in
-d1-10.35, which turns on debugging in sections 1 through 10 at level 35. The specification
-d0-91.104 turns on all sections of V8 sendmail's debugging code at the highest levels and produces
thousands of lines of output for a single address.
</BLOCKQUOTE></TD></TR>
</TABLE></CENTER>
</P>
<P>The -d option is not limited for use with
sendmail's address testing mode (-bt); you can
also use it to see how sendmail processes rulesets while sending a letter, as the following
example shows:
</P>
<!-- CODE SNIP //-->
<PRE>
$ sendmail -d21.36 joe@gonzo.gov < /tmp/letter
[lots and lots of output...]
</PRE>
<!-- END CODE SNIP //-->
<P>Unfortunately, the SIOG doesn't tell you which numbers correspond to which sections of
code. Instead, the author suggests that keeping such documentation current is a lot of work
(which it is) and that you should look at the code itself to discover the correct debugging formulas.
</P>
<P>The function tTd() is the one to look for. For example, suppose you want to turn on
debugging in sendmail's address-parsing code. The source file
parseaddr.c contains most of this code, and the following command finds the allowable debugging levels:
</P>
<!-- CODE SNIP //-->
<PRE>
$ egrep tTd parseaddr.c
if (tTd(20, 1))
[...]
if (tTd(24, 4))
if (tTd(22, 11))
[etc.]
</PRE>
<!-- END CODE SNIP //-->
<P>The egrep output shows that debugging specifications such as
-d20.1, -d24.4, and -d22.11 (and others) will make sense to
sendmail.
</P>
<P>If perusing thousands of lines of C code doesn't appeal to you, the O'Reilly book
sendmail, 2nd Ed. documents the debugging flags for
sendmail.
</P>
<P>The -C option allows you to test new configuration files before you install them, which is
always a good idea. If you want to test a different file, use
-C/path/to/the/file. You can combine it with the -bt and -d flags. For example, a common invocation for testing new
configuration files is
</P>
<!-- CODE SNIP //-->
<PRE>
sendmail -Ctest.cf -bt -d21.12
</PRE>
<!-- END CODE SNIP //-->
<A NAME="PAGENUM-123"><P>Page 123</P></A>
<CENTER>
<TABLE BGCOLOR="#FFFF99">
<TR><TD><B>
WARNING
</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
For security, sendmail drops its superuser permissions when you use the
-C option. You should perform final testing of configuration files as the superuser to ensure that your
testing is compatible with sendmail's normal operating mode.
</BLOCKQUOTE></TD></TR>
</TABLE></CENTER>
<H4>
Testing sendmail and sendmail.cf
</H4>
<P>Before installing a new or modified sendmail.cf, you must test it thoroughly. Even small,
apparently innocuous changes can lead to disaster, and as mentioned in the introduction to
this chapter, people get really irate when you mess up the mail system.
</P>
<P>The first step in testing is to create a list of addresses that you know should work at your
site. For example, at gonzo.gov, an Internet site without UUCP connections, the following
addresses must work:
</P>
<!-- CODE SNIP //-->
<PRE>
joe
joe@pc1.gonzo.gov
joe@gonzo.gov
</PRE>
<!-- END CODE SNIP //-->
<P>If gonzo.gov has a UUCP link, those addresses must also be tested. Other addresses to
consider include the various kinds of aliases (for example,
postmaster, an :include: list, an alias that mails to a file, and one that mails to a program), nonlocal addresses, source-routed
addresses, and so on. If you want to be thorough, you can create a test address for each legal address
format in RFC 822.
</P>
<P>Now that you've got your list of test addresses, you can use the
-C and -bt options to see what happens. At a minimum, you should run the addresses through rulesets 3 and 0 to make
sure that they are routed to the correct mailer. An easy way to do so is to create a file containing
the ruleset invocations and test addresses and then run
sendmail on it. For example, if the file addr.test contains the lines
</P>
<!-- CODE SNIP //-->
<PRE>
3,0 joe
3,0 joe@pc1.gonzo.gov
3,0 joe@gonzo.gov
</PRE>
<!-- END CODE SNIP //-->
<P>you can test your configuration file test.cf by typing
</P>
<!-- CODE SNIP //-->
<PRE>
$ sendmail -Ctest.cf -bt < addr.test
rewrite: ruleset 3 input: joe
rewrite: ruleset 3 returns: joe
[etc.]
</PRE>
<!-- END CODE SNIP //-->
<P>You also might want to follow one or more addresses through the complete rewriting
process. For example, if an address resolves to the
smtp mailer and that mailer specifies R=21, you
can test recipient address rewriting by using 3,2,21,4
test_address.
</P>
<A NAME="PAGENUM-124"><P>Page 124</P></A>
<P>If the sendmail.cf appears to work correctly so far, you're ready to move on to sending
some real letters. You can do so by using a command like the following:
</P>
<!-- CODE SNIP //-->
<PRE>
$ sendmail -v -oQ/tmp -Ctest.cf recipient < /dev/null
</PRE>
<!-- END CODE SNIP //-->
<P>The -v option tells sendmail to be verbose so that you can see what's happening.
Depending on whether the delivery is local or remote, you can see something as simple as
joe... Sent or an entire SMTP dialogue.
</P>
<P>The -oQ/tmp tells sendmail to use /tmp as its queue directory. Using this option is
necessary because sendmail drops its superuser permissions when run with the
-C option and can't write queue files into the normal mail queue directory. Because you are using the
-C and -oQ options, sendmail also includes the following warning headers in the letter to help alert the recipient
of possible mail forgery:
</P>
<!-- CODE SNIP //-->
<PRE>
X-Authentication-Warning: gonzo.gov: Processed from queue /tmp
X-Authentication-Warning: gonzo.gov: Processed by joe with -C srvr.cf
</PRE>
<!-- END CODE SNIP //-->
<P>sendmail also inserts the header Apparently-to:
joe because, although you specified a recipient on the command line, none was listed in the body of the letter. In this case, the letter's
body was taken from the empty file /dev/null, so no
To: header was available. If you do your testing as the superuser, you can skip the
-oQ argument, and sendmail won't insert the warning
headers. You can avoid the Apparently-to: header by creating a file like
</P>
<!-- CODE SNIP //-->
<PRE>
To: recipient
testing
</PRE>
<!-- END CODE SNIP //-->
<P>and using it as input instead of /dev/null.
</P>
<P>The recipient should be you so that you can inspect the headers of the letter for correctness.
In particular, return address lines must include an FQDN for SMTP mail. That is, a header
like From: joe@gonzo is incorrect because it doesn't include the domain part of the name, but
a header like From: joe@gonzo.gov is fine.
</P>
<P>You should repeat this testing for the same variety of addresses you used in the first tests.
You might have to create special aliases that point to you for some of the testing.
</P>
<P>The amount of testing you do depends on the complexity of your site and the amount of
experience you have, but a beginning system administrator should test very thoroughly, even
for apparently simple installations. Remember the flaming toaster.
</P>
<H3><A NAME="ch07_ 37">
POP
</A></H3>
<P>As much as you may love Linux, you have to deal with the reality that you must contend
with other operating systems out there. Even worse, many of them aren't even UNIX based.
Although the Linux community has forgiven the users of "other" operating systems, there is
still a long way to go before complete assimilation will happen. In the meantime, the best
thing that can happen is to use tools to tie the two worlds together.
</P>
<P><CENTER>
<a href="0119-0121.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0125-0127.html">Next</A>
</CENTER></P>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?