HREF="http://www.sendmail.org/faq/section4.html">
unknown mailer
error 1
" mean?
If at all possible, no.
Wildcard MX records have lots of semantic "gotcha"s. For example, they will match a host "unknown.your.domain" -- if you don't explicitly test for unknown hosts in your domain, you will get "MX list for hostname points back to hostname" or "config error: mail loops back to myself".
See RFCs 1535, 1536, and 1912 (updates RFC 1537) for more detail and other related (or common) problems. See also _DNS and BIND_ by Albitz and Liu.
They can also cause your system to add your domain to outgoing FQDNs in a desperate attempt to get the mail to where it's supposed to go, but because *.your.domain is valid due to the wildcard MX, delivery to not.real.domain.your.domain will get dumped on you, and you may even find yourself in a loop as the domain keeps getting tacked on time after time after time (the "config error: mail loops back to myself" problem).
Wildcard MX records are just a bad idea, plain and simple. They don't work the way you'd expect, and virtually no one gets them right. Avoid them at all costs.
This is a local mailer issue, not a sendmail issue. Depending on what you're doing, look at procmail (see Q4.9), ftpmail, or Majordomo.
The latest version of Majordomo can be found at ftp://ftp.greatcircle.com/pub/majordomo/. It is written in Perl and requires either Perl 4.036, and appears to run with only minor tweaks under 5.001a or later. Make sure to check out the web interface for Majordomo called LWGate at http://www.netspace.org/users/dwb/lwgate.html. The latest versions of Perl (both 4.x and 5.x) can be found in http://www.metronet.com/perlinfo/src/. More information about Perl can be found at http://www.metronet.com/perlinfo/perl5.html
The latest version of ftpmail can be found at ftp://src.doc.ic.ac.uk/packages/ftpmail or any comp.sources.misc archive (volume 37).
Again, this is a local mailer issue, not a sendmail issue. Either modify your local mailer (source code will be required) or change the program called in the "local" mailer configuration description to be a new program that does this local delivery. One program that is capable of doing this is procmail (see Q4.9), although there are probably many others as well.
Or, I'm trying to use the "don't deliver to expensive mailer" flag, and it delivers the mail interactively anyway. I can see it does it: here's the output of "sendmail -v foo@somehost" (or Mail -v or equivalent).
The -v flag to sendmail (which is implied by the -v flag to Mail and other programs in that family) tells sendmail to watch the transaction. Since you have explicitly asked to see what's going on, it assumes that you do not want to to auto-queue, and turns that feature off. Remove the -v flag and use a "tail -f" of the log instead to see what's going on.
If you are trying to use the "don't deliver to expensive mailer" flag (mailer flag "e"), be sure you also turn on global option "c" -- otherwise it ignores the mailer flag.
I'm getting these error messages:
553 MX list for domain.net points back to relay.domain.net 554 <user@domain.net>... Local configuration errorHow can I solve this problem?
You have asked mail to the 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 (if you are using FEATURE(use_cw_file)) or add "Cw domain.net" to your configuration file.
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 `head -1 /etc/sendmail.pid` sh -c "`tail -1 /etc/sendmail.pid`"NOTA BENE: kill -1 does not work with versions prior to 8.7.y!
With version 8.8.z sendmail, if the daemon was started up with a full pathname (i.e., "/usr/lib/sendmail -bd -q13m"), then you should be able to send it a HUP signal ("kill -1", or more safely, "kill -HUP") and have it reload itself (version 8.7.y sendmail cannot do this safely, and represents a security risk if it's not replaced with version 8.8.3 or later).
I'm connected to the network via a SLIP/PPP link. Sometimes my sendmail process hangs (although it looks like part of the message has been transfered). Everything else works. What's wrong?
Most likely, the problem isn't sendmail at all, but the low level network connection. It's important that the MTU (Maximum Transfer Unit) for the SLIP connection be set properly at both ends. If they disagree, large packets will be trashed and the connection will hang.
This question is addressed on pages 445-449 of _sendmail, 2nd Ed_ (see page 319 of first edition) by Bryan Costales (see entry sendmail-faq//book/ISBN/1-56592-222-0 in Q6.1).
An updated version of this syslog-stat.pl script (so that it understands the log format used in version 8 sendmail) is at ftp://ftp.his.com/pub/brad/sendmail/syslog_stats. The updated version of ssl has been uploaded to the SMTP Resources Directory (in ftp://ftp.is.co.za/networking/mail/tools/), as well as ftp://ftp.his.com/pub/brad/sendmail/ssl. There is also another program (written by Bryan Beecher) at ftp://ftp.his.com/pub/brad/sendmail/smtpstats.
If you're interested in summarizing POP statistics, there is ftp://ftp.his.com/pub/brad/sendmail/popstats, also written by Bryan Beecher, and popstats.pl, written by Ryan Matteson.
To see what else is available today, check the Comprehensive Perl Archive Network ftp://ftp.funet.fi/pub/languages/perl/CPAN/CPAN or ftp://ftp.cis.ufl.edu/pub/perl/CPAN/CPAN for the site nearest you. For the scripts themselves, look under CPAN/scripts/mailstuff/ at any CPAN site. For more information, see the comp.lang.perl.* FAQs at ftp://ftp.cis.ufl.edu:/pub/perl/faq/FAQ or ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/comp/lang/perl/.
If you're interested in using these kinds of tools to help you do some near real-time monitoring of your system, you might be interested in MEWS (Mail Early Warning System). From the README:
If you've ever written a perl script to parse sendmail log files looking for errors, MEWS might be of interest to you. If you've ever thought about writing a perl script to munge sendmail log files, cringed a little and hurriedly came up with an excuse not to do it, read on. If you don't have a Solaris 2.5 machine, you can probably stop reading here. The Mail Early Warning System (MEWS) gives postmasters immediate notification of trouble spots on your mail backbone. It only works with sendmail. To explain it in a nutshell, whenever sendmail returns a 4xx or 5xx SMTP code, with the MEWS modifications, it also sends the code over UDP to a daemon which then replays the error message to interested parties. The man pages go into a little bit more detail.If this sounds like something you might be interested in getting more details about, you can find the MEWS archive at ftp://ftp.qualcomm.com/pub/people/eamonn/mews.tar.Z.
The recommended program for this is "checksendmail" by Rob Kolstad. Old versions of this are available on various archive sites, but currently, the only way to get the most recent version (which has been updated to understand version 8.7 long option name syntax, as well as now supporting both Perl 4.x and Perl 5.x) is from Rob himself.
The latest archive will be made publicly available (most likely through the SMTPRD run by Andras Salamon; see Q6.5, entry sendmail-faq//online/index/14) as soon as it is received.
The program "procmail" is a replacement for the local mailer (variously called /bin/mail, /usr/bin/mail, mail.local, rmail, etc...). It has been ported to run on virtually every Unix-like OS you're likely to run into, and has a whole host of features. It is typically about 30% faster performing the job of the local mailer than programs such as /bin/mail or /usr/bin/mail, it has been hammered on widely to make it extremely secure (much more so than most local mailers) and very robust. Procmail is also capable of helping you put a quota on a user's mailbox through the standard Unix quota mechanism (see Q4.3).
In short, whatever you've got, you're almost guaranteed that procmail is better (if nothing else, the author has been able to focus lots of time and energy into making it the best and fastest tool available, while most system vendors just throw something together as fast as they can and move on to the whole rest of the OS).
However, this only begins to scratch the surface of what procmail is capable of. It's most important feature is the fact that it gives you a standard way to create rules (procmail calls them "recipes") to process your mail before the messages get put into your mailbox, and for that feature alone, it is one of the most important tools any administrator can have in their repertoire. By filtering out or automatically dealing with 80% of your daily cruft, it lets you spend more time on the hard 20%.
Note that recent releases of version 8 sendmail natively support using procmail as an alternate local mailer (see "FEATURE(local_procmail)" for version 8.7 and above). They also support procmail as an additional local mailer, if you're concerned about flat-out replacing your current local mailer with procmail (see "MAILER(procmail)" in version 8.7 and above).
You can also install procmail as a user and run it out of your .forward file, although this tends to be a bit slower and less efficient.
More information about procmail can be found at http://www.procmail.org/ and the latest version can be found at ftp://ftp.procmail.org/pub/procmail/.
Procmail is also the core to a mailing list management package called "SmartList", so if you've already got procmail, adding SmartList may be a good option. Some listowners prefer Majordomo, Listserv, or one of those other programs, but SmartList has more than a few adherents as well. Your personal tastes will dictate whether you swear by SmartList or at it.
I upgraded from my vendor's sendmail to the latest version and now I'm getting these error messages when I run "newaliases":
/etc/aliases: line 13: MAILER-DAEMON... cannot alias non-local names /etc/aliases: line 14: postmaster... cannot alias non-local namesHow can I solve this problem?
Your local mailer doesn't have the "A" flag specified. Edit the Mlocal line in sendmail.cf and add "A" to the flags listed after "F=".
Better yet, if you're running a recent version of sendmail that uses m4 to generate .cf files from .mc files, regenerate your sendmail.cf and see if that fixes the problem. Remember to install the new sendmail.cf and restart the sendmail daemon.
Quoth Eric Allman:
... I can make the following assurances:Internally, sendmail represents dates in the Unix native format: seconds since January 1, 1970. This does not overflow until well after the year 2000.
Externally, sendmail always represents dates using four digit years, as required by the applicable Internet standards.
At no time does sendmail store dates using only the last two digits of the year. However, if a
Date:
field is received that has a two digit year, sendmail does not attempt to repair that damage. However, neither does it attempt to interpret the date.
First, you need to get sendmail not to use DNS on your local machine so your host doesn't trying to connect to your ISP for a DNS query. See Q3.22 for more information.
You also need to designate a "smart host" or external relay to handle all mail that you can't deliver locally (this would be your ISP's mailhost).
You need to configure it so that the smtp mailer is considered
"expensive" by adding the F=e
mailer flag and tell sendmail
not to connect to expensive mailers by default by setting the
HoldExpensive option to True
.
You need to add mydomain.com
to the sendmail.cw
file or the Cw
line in the sendmail.cf
. See
Q4.5.
Finally, you need to run a program periodically to check in with your ISP and get them to deliver any mail they may have queued for you. See Q3.23.
unknown mailer error 1
"
mean?
In general, sendmail does not perform final delivery of messages, but
relies on a local delivery agent instead. Such an agent, mail.local,
is provided with the sendmail distribution. Any such agent that sendmail
invokes for message delivery, as specified on an M
line in
sendmail.cf, must exit with code 0 (success), or one of the failure codes
noted in src/sysexits.h
. These generally run in the range
64 - 78, so 1 would be out of range, and lead to sendmail generating the
above error.