Akadia Information Technology
Testen der Adressen
Download Download PDF File with more Sendmail Tips ....
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.
$ /usr/lib/sendmail -bt -Ctest.cf
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.
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
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.
Beispiel: Für den uucp Mailer wird R=23 verwendet:
$ /usr/lib/sendmail -bt -Ctest.cf
Damit wird die Headerzeile zu: To: zephir!bj
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
Dies ist ein Header-Test
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
Trying header sender address zahn for mailer smtp
The following flags are available: S for sender, R for recipient, H for Header and E for envelope.
$ /usr/lib/sendmail -q (Message-Queue bearbeiten)
$ /usr/lib/sendmail -bv -v glue
Logfile von Sendmail kontrollieren
Sendmail im Debug Modus
MX Record testen
Sendmail kann über verschiedene Interfaces angesprochen werden
$ /usr/lib/sendmail -v < file -f email@example.com zephir!bj
Das File «mail» enthält folgenden Inhalt:
Direkt via SMTP
$ telnet mzsun 25
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.
Enable Relaying for the LAN hosts
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:
How to deliver local mails if DNS- and Mail-Server is the same machine ?
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:
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.
makemap hash /etc/mail/access < /etc/mail/access
The table itself uses e-mail addresses, domain names, and network numbers as keys.
would refuse mail from firstname.lastname@example.org, any user from cyberspammer.com
The value part of the map can contain:
cyberspammer.com 550 We don't accept mail
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.
These helpful tips comes from http://www.sendmail.org
I'm getting these error messages:
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:
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`
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
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
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.