|
 Testen der Adressen
Sendmail ermöglicht es eine Adresse zu testen. Dazu wird Sendmail im
Test-Mode aufgerufen. Man hat die Möglichkeit zu beobachten, welche Rules auf eine
Adresse angewendet werden und wie die Adresse durch die einzelnen Rules verändert
werden.
Testen von Mailer, Host, User
$ /usr/lib/sendmail -bt -Ctest.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
> 0,4 zephir!bj
rewrite: ruleset 3 input: zephir ! bj
rewrite: ruleset 6 input: bj < @ zephir . uucp >
rewrite: ruleset 6 returns: bj < @ zephir . uucp >
rewrite: ruleset 3 returns: bj < @ zephir . uucp >
rewrite: ruleset 0 input: bj < @ zephir . uucp >
rewrite: ruleset 9 input: bj < @ zephir . uucp >
rewrite: ruleset 9 returns: bj < @ zephir . uucp >
rewrite: ruleset 0 returns: $# uucp $@ zephir $: bj
rewrite: ruleset 4 input: $# uucp $@ zephir $: bj
rewrite: ruleset 9 input: $# uucp $@ zephir $: bj
rewrite: ruleset 9 returns: $# uucp $@ zephir $: bj
rewrite: ruleset 4 returns: $# uucp $@ zephir $: bj
Zuerst wird das Ruleset 3 aufgerufen, welches die Adresse in die interne
Form bj<@zephir.uucp> bringt. Ruleset 3 verwendet Ruleset 6 ($@$>6<@$1>:$2).
Dann erfolgt die Verarbeitung in Ruleset 0 um dem Mailer, den Recipient-Host und den
Recipient-User festzulegen. Ergebnis: $#uucp$@zephir$:bj. Ruleset 4 bringt die Adresse in
die endgültige, externe Form $#uucp$@zephir$:bj. Zu beachten ist ferner, dass Ruleset
0 und 4 das Ruleset 9 intern verwendet. Aus dieser Information kann folgendes ermittelt
werden: Als Kommunikations-Protokoll zur Übermittlung der Email wird UUCP verwendet.
Der Zielhost ist zephir, dort wird die EMail Adresse bj vom «zephir-Sendmail»
weiterverarbeitet. Man muss sich also sehr kritisch fragen, ob der Host zephir in der Lage
ist die Adresse zu verarbeiten.
Testen der Sender Address Rewriting
(From:)
Damit kann festgestellt werden, wie die From: Headerzeile bearbeitet
wird. Je nach Mailer wird für S ein Ruleset aufgerufen. Man muss somit im
Konfigurationsfile sendmail.cf nachschauen, welches Ruleset für einen bestimmten
Mailer aufgerufen wird.
Beispiel: Der Mailer uucp verwendet S=13, smartuucp verwendet S=22
$ /usr/lib/sendmail -bt -Ctest.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
> 1,13,4 mzsun!mz
rewrite: ruleset 3 input: mzsun ! mz
rewrite: ruleset 6 input: mz < @ mzsun . uucp >
rewrite: ruleset 6 returns: mz < @ mzsun . uucp >
rewrite: ruleset 3 returns: mz < @ mzsun . uucp >
rewrite: ruleset 1 input: mz < @ mzsun . uucp >
rewrite: ruleset 1 returns: mz < @ mzsun . uucp >
rewrite: ruleset 13 input: mz < @ mzsun . uucp >
rewrite: ruleset 5 input: mz < @ mzsun . uucp >
rewrite: ruleset 5 returns: mzsun ! mz
rewrite: ruleset 13 returns: mzsun . boa . ch ! mz
rewrite: ruleset 4 input: mzsun . boa . ch ! mz
rewrite: ruleset 9 input: mzsun . boa . ch ! mz
rewrite: ruleset 9 returns: mzsun . boa . ch ! mz
rewrite: ruleset 4 returns: mzsun . boa . ch ! mz
Damit wird die Headerzeile zu From: mzsun.boa.ch!mz Das Sender-Ruleset
für den UUCP Mailer ist das Ruleset-Nr 13, dies kann im Konfigurationsfile
herausgelesen werden. Die Kontrolle der Sender-Adresse ist äusserst wichtig, damit der
Empfänger die EMail mittels «Reply» beantworten kann. In EMail Umgebungen
sind falsche Reply-Adressen der häufigste Grund für unzustellbare EMails.
Testen der Receiver Address Rewriting
(To: / Cc:)
Beispiel: Für den uucp Mailer wird R=23 verwendet:
$ /usr/lib/sendmail -bt -Ctest.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
> 2,23,4 zephir!bj
rewrite: ruleset 3 input: zephir ! bj
rewrite: ruleset 6 input: bj < @ zephir . uucp >
rewrite: ruleset 6 returns: bj < @ zephir . uucp >
rewrite: ruleset 3 returns: bj < @ zephir . uucp >
rewrite: ruleset 1 input: bj < @ zephir . uucp >
rewrite: ruleset 1 returns: bj < @ zephir . uucp >
rewrite: ruleset 23 input: bj < @ zephir . uucp >
rewrite: ruleset 5 input: bj < @ zephir . uucp >
rewrite: ruleset 5 returns: zephir ! bj
rewrite: ruleset 23 returns: zephir ! bj
rewrite: ruleset 4 input: zephir ! bj
rewrite: ruleset 9 input: zephir ! bj
rewrite: ruleset 9 returns: zephir ! bj
rewrite: ruleset 4 returns: zephir ! bj
Damit wird die Headerzeile zu: To: zephir!bj
Oberserving if the
mailer properly connects to the remote mailer
By observing if your mailer properly connects to the remote mailer and
formats the addresses correctly, you'll get a goof idea of how the configuration is
working.
$ /usr/lib/sendmail -Ctest.cf -t -v
To: zephir!bj
From:mzsun!mz
Subject: Header-Test
Dies ist ein Header-Test
^D
zephir!bj... Connecting to zephir via uucp...
zephir!bj... Sent
Test Header and
Envelope Address
If you know the mailer, you can use sendmail with the -bt option to
process the sender From: address. There are two types of sender addresses: the sender
address in the envelope and the sender address in the message header. The message header
is the one on the From: line sent with the message during SMTP DATA transfer. You
probably see it in the mail headers when you view the message with your mail reader. The
envelope address is the address used during the SMTP protocol interactions. Sendmail
allows us to view the processing of both of these addresses.
$ /usr/lib/sendmail -Ctest.cf -bt
> /tryflags HS
> /try smtp zahn
Trying header sender address zahn for mailer smtp
rewrite: ruleset 3 input: zahn
rewrite: ruleset 96 input: zahn
rewrite: ruleset 96 returns: zahn
rewrite: ruleset 3 returns: zahn
rewrite: ruleset 1 input: zahn
rewrite: ruleset 1 returns: zahn
rewrite: ruleset 31 input: zahn
rewrite: ruleset 51 input: zahn
rewrite: ruleset 51 returns: zahn
rewrite: ruleset 61 input: zahn
rewrite: ruleset 61 returns: zahn < @ *LOCAL* >
rewrite: ruleset 93 input: zahn < @ *LOCAL* >
rewrite: ruleset 93 returns: zahn < @ rabbit . akadia . com . >
rewrite: ruleset 31 returns: zahn < @ rabbit . akadia . com . >
rewrite: ruleset 4 input: zahn < @ rabbit . akadia . com . >
rewrite: ruleset 4 returns: zahn @ rabbit . akadia . com
Rcode = 0, addr = zahn@rabbit.akadia.com
The following flags are available: S for sender, R for
recipient, H for Header and E for envelope.
Wichtigste Sendmail Kommandos
$ /usr/lib/sendmail -q (Message-Queue bearbeiten)
$ /usr/lib/sendmail -bp (Message-Queue auslisten)
$ /usr/lib/sendmail -bi (/etc/aliases neu erstellen)
$ /usr/lib/sendmail -bz (/etc/sendmail.fc neu erstellen)
$ /usr/lib/sendmail -bd -q1h (Sendmail listens on TCP/IP-Port)
Testen von Mailinglists in /etc/aliases
$ /usr/lib/sendmail -bv -v glue
glue... aliased to zephir!hueni zephir!bj zephir!metz%iam.unibe.ch
zephir!hueni zephir!bj zephir!metz%iam.unibe.ch... deliverable
Troubleshooting Sendmail
Logfile von Sendmail kontrollieren
(afxxx = Header Informationen, dfxxx= Body, lfxxx= Lock File)
$ /usr/spool/mqueue/syslog
Welche Konfigurationsfiles werden benutzt ?
$ grep "/[^0-9].*/" /etc/sendmail.cf
Stoppen des Sendmail Prozesses
$ kill ‘cat /etc/sendmail.pid‘
Sendmail als Daemon starten
$ /usr/lib/sendmail -bd -q1h
Rebuild der Alias Listen in /etc/aliases
$ /usr/lib/sendmail -bi
Testen der Alias Listen in /etc/aliases
$ /usr/lib/sendmail -bv <alias>
Verbose Mode von Sendmail (Debbuging)
$ /usr/lib/sendmail -v <recipient> < /dev/null
$ mail -v <recipient> < /dev/null
Show Sendmail Queue
$ /usr/lib/sendmail -bp
Process Sendmail Queue
$ /usr/lib/sendmail -q
Freeze Konfigurationsfile /etc/sendmail.cf
$ /usr/lib/sendmail -bz
Test SMTP Connection
$ telnet mailhost zahn
helo
mail from: martin dot zahn at akadia dot ch
rcpt to: info@akadia.com
data
Test Mail
.
quit
Debug Sendmail
Sendmail im Debug Modus
$ /usr/lib/sendmail -d <kategorie.level> -bt
Show Delivery Agent (Mailer)
$ /usr/lib/sendmail -d0.12 -bt < /dev/null
Show Macros without $u, $M which will be set when mail is already
delivered
$ /usr/lib/sendmail -d35.9 -bt
Show Rulesets
$ /usr/lib/sendmail -d21.12 -bt
Show internal Macros $w (Canonical Name of the Host)
$ /usr/lib/sendmail -d0.4 -bp
Version 8.8.8+Sun
Compiled with: LOG MATCHGECOS MIME7TO8 MIME8TO7 NAMED_BIND NDBM NETINET
NETUNIX NIS NISPLUS QUEUE SCANF SMTP XDEBUG
canonical name: quorum.glue.ch
a.k.a.: quorum
UUCP nodename: quorum
a.k.a.: [193.72.194.29]
UUCP nodename: quorum
a.k.a.: [127.0.0.1]
============ SYSTEM IDENTITY (after readcf) ============
(short domain name) $w = quorum
(canonical domain name) $j = $w.$m
(subdomain name) $m = akadia.ch
(node name) $k = quorum
========================================================
Mail queue is empty
MX Record testen
$# /usr/lib/sendmail -bt
WARNING: writable directory /var
WARNING: writable directory /var/spool
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> /mx akadia.com
getmxrr(akadia.com) returns 1 value(s):
mail.glue.ch.
> $=D
akadia.com
Sendmail Interfaces
Sendmail kann über verschiedene Interfaces angesprochen werden
$ /usr/lib/sendmail -v < file -f mz@boa.ch
zephir!bj
zephir!bj... Connecting to zephir via uucp...
zephir!bj... Sent
Das File «mail» enthält folgenden Inhalt:
to: zephir!bj
cc: zephir!hueni
From: mz@mzsun
Dies ist der Message Body
$ cat mail | /usr/lib/sendmail -bm -t -v
zephir!bj,zephir!hueni... Connecting to zephir via uucp...
zephir!bj,zephir!hueni... Sent
$ telnet mzsun 25
Trying 193.72.194.1 ...
Connected to mzsun.boa.ch.
Escape character is ’^]’.
220 boa.ch Sendmail 4.1/SMI-4.1 ready at Mon, 20 Sep 93 16:11:51 +0200
$ helo
250 boa.ch Hello (mzsun.boa.ch), pleased to meet you
$ mail from:<mz@mzsun>
250 <mz@mzsun>... Sender ok
$ rcpt to:<bj@zephir.uucp>
250 <bj@zephir.uucp>... Recipient ok
$ data
354 Enter mail, end with . on a line by itself
Nun kommt die eigentliche Message. Sie besteht aus
diesen zwei Zeilen.
$ .
250 Mail accepted
$ quit
221 boa.ch delivering mail
Cannot forward my E-Mail
with $HOME/.forward -- Help !
Last week, we had a very strange behavior on one of our UNIX
machines. From one user account we could forward his E-Mail, but from another account it
didn't work. We found the solution for this problem in the Sendmail FAQ.
Beginning with sendmail 8.9, permission checks have become
more strict to prevent users from being able to access files they would normally not be
able to read. In particular, .forward and :include: files in unsafe directory paths
(directory paths which are group or world writable) will no longer be allowed. This would
mean that if user joe's home directory was writable by group staff, sendmail would not use
his .forward file.
Other files affected by this strengthened security include
class files (i.e. Fw /etc/sendmail.cw), persistent host status files, and the files
specified by the ErrorHeader and HelpFile options.
If you have an unsafe configuration of .forward and
:include: files, you can make it safe by finding all such files, and doing a "chmod go-w
$FILE" on each. Also, do a "chmod go-w $DIR" for each directory in the file's path.
Relay and DNS configuration tips
for Sendmail
Much of the potential problem with sendmail lies in its
local configuration and which remote hosts are allowed to relay mail through the local
server. Fortunately for us, sendmail's default Linux configuration is secure. A
single-system site will need to do very little with the sendmail configuration. A system
providing mail service for a LAN will need to enable relaying for the LAN hosts. Otherwise,
your mail server won't accept outgoing mail from your local machines. Relaying is enabled
for specific hosts in one of two file, /etc/mail/access or /etc/mail/relay-domains. An
example of /etc/mail/access for the small LAN 192.168.138.0 might contain:
# Check the /usr/doc/sendmail-8.9.3/README.cf file for a
description
# of the format of this file. (search for access_db in that file)
# The /usr/doc/sendmail-8.9.3/README.cf is part of the sendmail-doc
# package.
#
# by default we allow relaying from localhost...
localhost.localdomain RELAY
localhost RELAY
127.0.0.1 RELAY
192.168.138 RELAY
The configuration files in /etc/mail are pairs of files, an ASCII file and
a hashed database file created from the ASCII file. After editing one of the ASCII files,
its hashed counterpart needs to be updated. The following command updates the
/etc/mail/access hash table, /etc/mail/access.db:
makemap hash /etc/mail/access <
/etc/mail/access
The Mail Exchanger (MX Records) in the DNS configuration is
just an ordered list of destinations that tells mailers where to send messages if they want
to reach a given domain. The preference value tells them how desirable it is to use that
destination. That's the basic idea behind MX records and mail exchangers, but there are a
few more wrinkles you should know about. Here is the output of a typical MX entry in the
DNS configuration, where the DNS-Server is rabbit.akadia.ch:
IN MX 10 mail1.akadia.ch.
IN MX 20 mail2.akadia.ch.
What happens if a mailer finds itself at the highest preference, and has to
discard the whole MX list as shown below ?
IN MX 10 rabbit.akadia.ch.
IN MX 20 opal.akadia.ch.
Some mailers attempt delivery directly to
the destination host's IP address, as a last-ditch effort. In most mailers however , it's
an error. It may indicate that DNS thinks the mailer should be processing (not just
forwarding) mail for the destination, but the mailer hasn't been configured to know that.
Or it may indicate that the administrator has ordered the MX records incorrectly by using
the wrong preference values. Then it will bounce the mail with the familiar error:
554 MX list for akadia.ch points back to rabbit.akadia.ch
554 <root@akadia.ch> ... Local configuration
error
Many versions of sendmail use class w or file class w as the list of local
destinations. The sendmail configuration on RedHat Linux offers the file /etc/sendmail.cw.
Enter the local domains in this file and the local delivery together with MX records will
work.
# sendmail.cw - include all aliases for your machine here.
akadia.ch
akadia.com
Besides this configuration, do not specify any values for the macros DS and
DH
# who I send unqualified names to (null means deliver locally)
# Do not put anything here (M.Zahn)
DR
# who gets all local email traffic ($R has precedence for unqualified names)
# Do not put anything here (M.Zahn)
DH
Relaying E-Mails with sendmail
Relaying (transmission of messages from a site outside
your domain to another site outside your domain) is denied by default. Note that this
changed in sendmail 8.9; previous versions allowed relaying by default. Relaying is a
feature (not a bug) to prevent E-Mail spamming. You have to configure relaying or you will
get the error message: 550 Requested action not taken: relaying denied.
An "access'' database can be created to accept or reject
mail from selected domains. For example, you may choose to reject all mail originating from
known spammers. To enable such a database, use the file /etc/mail/access. Remember,
since /etc/mail/access is a database, after creating the text file as described below, you
must use makemap to create the database map.
For example:
makemap hash /etc/mail/access <
/etc/mail/access
The table itself uses e-mail addresses, domain names, and
network numbers as keys.
For example:
spammer@aol.com REJECT
cyberspammer.com REJECT
192.168.212 REJECT
would refuse mail from spammer@aol.com, any user from
cyberspammer.com
(or any host within the cyberspammer.com domain), and any host on the
192.168.212.* network.
The value part of the map can contain:
| OK |
Accept mail even if other rules in the running ruleset would reject it,
for example, if the domain name is unresolvable |
| RELAY |
Accept mail addressed to the indicated domain or received from the
indicated domain for relaying
through your SMTP server. RELAY also serves as an implicit OK for the other checks |
| REJECT |
Reject the sender or recipient with a general purpose message |
| DISCARD |
Discard the message completely using the $#discard mailer. This only
works for sender addresses (i.e., it indicates that you should discard anything
received from the indicated domain). |
| Error Text |
Any text where ### is an RFC 821 compliant error code and "any text" is
a message to return for the command. |
For example:
cyberspammer.com
550 We don't accept mail from spammers
okay.cyberspammer.com OK
sendmail.org OK
128.32
RELAY
Would accept mail from okay.cyberspammer.com, but would
reject mail from all other hosts at cyberspammer.com with the indicated message.It would
allow accept mail from any hosts in the sendmail.org domain, and allow relaying for the
128.32.*.* network.
More information can be found in the README.cf file of
sendmail.
How to solve MX
record problems with sendmail ?
These helpful tips comes from http://www.sendmail.org
I'm getting these error messages:
-
MX list for domain.net points back to relay.domain.net
<user@domain.net>... Local configuration error
-
MX list for hostname points back to hostname.
-
Config error: mail loops back to myself.
How can I solve these problems ?
You have asked mail to a domain (e.g., domain.net) to be forwarded to a
specific host (in this case, relay.domain.net) by using an MX record, but the relay
machine doesn't recognize itself as domain.net. Add domain.net to /etc/sendmail.cw
prior to version 8.10 or add "Cw domain.net" to your configuration file.
There are a couple of additional cases where you don't actually want
local delivery, and thus adding domain.net to class w is not the right fix:
-
When relay.domain.net should just be acting as a forwarder,
e.g. a firewall/gateway box. The proper fix could be to set up a mailertable entry for
domain.net.
-
When relay.domain.net is a secondary (etc.) MX, and the MX
mistakenly points to a CNAME or other "non-canonical" name [this gives "config error:
mail loops back to me (MX problem?)"]. The proper fix is to point the MX at the actual
name, a "work-around" to add the MX target to class w.
IMPORTANT: When making changes to your configuration file, be sure you
kill and restart the sendmail daemon (for any change in the configuration, not just this
one):
kill -HUP `head -1 /var/run/sendmail.pid`
How to setup
correct directory permissions for sendmail ?
Sendmail often gets blamed for many problems that are actually the result
of other problems, such as overly permissive modes on directories. For this reason,
sendmail checks the modes on system directories and files to determine if can have been
trusted. For sendmail to run without complaining, you MUST execute the following
command:
chmod go-w / /etc /etc/mail /usr /var /var/spool /var/spool/mqueue
chown root / /etc /etc/mail /usr /var /var/spool /var/spool/mqueue
You will probably have to tweak this for your environment (for example,
some systems put the spool directory into /usr/spool instead of /var/spool and use
/etc/mail for aliases file instead of /etc). If you set the RunAsUser option in your
sendmail.cf, the /var/spool/mqueue directory will have to be owned by the RunAsUser user.
As a general rule, after you have compiled sendmail, run the command
sendmail -v -bi
to initialize the alias database. If it gives messages such as
WARNING: writable directory /etc
WARNING: writable directory /usr/spool/mqueue
then the directories listed have inappropriate write permissions and
should be secured to avoid various possible security attacks.
Beginning with sendmail 8.9, these checks have become more strict to
prevent users from being able to access files they would normally not be able to read. In
particular, .forward and :include: files in unsafe directory paths (directory paths which
are group or world writable) will no longer be allowed. This would mean that if user
joe's home directory was writable by group staff, sendmail would not use his .forward
file.
|
Download Download PDF
File with more Sendmail Tips ....