unknown mailer
error 1" mean?
NOQUEUE: Null
connection from ..." 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, Majordomo or of course vacation, which is part of the sendmail (8.10.0 and later) distribution.
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 "HoldExpensive" (whose old one-character name was "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 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/mail/local-host-names [known as /etc/sendmail.cw
prior to version 8.10] (if you are using FEATURE(`use_cw_file'))
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:
kill -HUP `head -1 /var/run/sendmail.pid`Note: You can also get this error message (MX loops ...) when two sendmail systems talk to each other, and both have the same value of $j . The best solution is "don't do that."
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).
To see what else is available today, check the Comprehensive Perl Archive Network. For more information, see the comp.lang.perl.* FAQs at 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.
Here's an update from Stephane Lentz on June 29, 2000:
See also John Oliver's sendmail tools page for pointers to several related scripts. (May 25, 2001)
Brad Knowles's links for popstats, smtpstats and syslog_stats have been revived at a new location. (May 29, 2001)
Two new links (November 12, 2001):
Sendmail's test mode is best for this. See the Sendmail Installation and Operation Guide, § 3.8 (Testing Configuration files); here is a short sample:
% sendmail -bt -C /path/to/test/sendmail.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /tryflags hs > /try esmtp user@domain.com Trying header sender address user@domain.com for mailer esmtp ... > /quit %
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.
Please refer to the Sendmail Year 2000 Readiness Disclosure page.
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.
Andrzej Filip offers a different solution based on use of the dsmtp mailer (introduced in 8.10) instead of expensive mailers.
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.
Situation: Your system
mailserver.my.domain
should act as a backup mailserver for
mailserver.destination.domain.
The client wants to receive mail for the address
user@destination.domain.
This requires:
destination.domain. IN MX 10 mailserver.destination.domain. destination.domain. IN MX 20 mailserver.my.domain. mailserver.destination.domain. IN MX 10 mailserver.destination.domain. mailserver.destination.domain. IN MX 20 mailserver.my.domain.The last two records are there "just in case" (someone forgot masquerading).
mailserver.my.domain
must know its own name, otherwise you'll get the famous
mail loops back to myself error.
Instead of using MX records that point to
mailserver.destination.domain, you can use the
FEATURE(mailertable) on mailserver.my.domain
as explained in cf/README
for routing e-mails.
destination.domain to the
required files (8.9)
(or for 8.8).
Don't add destination.domain or
mailserver.destination.domain to
class w
on your system!
If you want finer-grained control, then instead of updating
/etc/mail/relay-domains, add the following to
/etc/mail/access, as the access
map entries allows relaying only "To:" a domain, while
relay-domains allows both directions.
To:destination.domain RELAY
ETRN
command.
You don't. Sendmail is a mail transfer agent (MTA). Creating e-mail messages, including adding attachments or signatures, is the function of a mail user agent (MUA). Some popular MUAs include mutt, elm, exmh, Netscape, Eudora and Pine. Some specialized packages (metamail, some Perl modules, etc.) can also be used to create messages with attachments.
To find out which version is actually running, from without, telnet to the SMTP port (port 25). The daemon usually announces its name and version number, as in
thishost% telnet that.host 25 Trying IP_addr... Connected to that.host. Escape character is '^]'. 220 that.host ESMTP Sendmail 8.12.1/8.12.1; Fri, 28 Dec 2001 11:39:34 -0800 QUITTo query a binary on your local host, the following command should display its version number, along with some extra configuration information, possibly including the configuration version number:
% echo \$Z | /usr/sbin/sendmail -bt -d0
Version 8.12.1
Compiled with: MAP_REGEX LOG MATCHGECOS MIME7TO8 MIME8TO7 NAMED_BIND
NETINET NETUNIX NEWDB NIS QUEUE SCANF SMTP USERDB XDEBUG
============ SYSTEM IDENTITY (after readcf) ============
(short domain name) $w = knecht
(canonical domain name) $j = knecht.Sendmail.ORG
(subdomain name) $m = Sendmail.ORG
(node name) $k = knecht.Sendmail.ORG
========================================================
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 8.12.1
%
Adjust the pathname as needed; /usr/lib and /usr/sbin
are the most common locations.
You really shouldn't, because upper case characters in user names are contrary to the Unix tradition. If you do, then e-mail addresses will be case sensitive, so that mail to <USER@your.host> will bounce instead of being delivered to <user@your.host>. As this is contrary to the expectations of many, it is not recommended.
But if you insist on doing so anyway, and you have version 8.10, put the following in your .mc file:
MODIFY_MAILER_FLAGS(`LOCAL', `+u')dnlIf you don't have 8.10, you will need to redefine the
LOCAL_MAILER_FLAGS m4 variable, but the initial value varies
from OS to OS, so this is yet another reason not to mess with this flag.
Another hack is the creation of aliases for Uppercase local users in the form:
# lowercase version to real one uppercase: UppercaseIt will make sendmail deliver messages to uppercase local recipients in a case insensitive manner.
NOQUEUE: Null connection from
..." mean?An entry like:
NOQUEUE: Null connection from host.domain [IP.AD.DD.RESS]in the logfile means that
host.domain connected to your MTA but neither
initiated transmission of a message (by issuing the MAIL
command), nor used any of the commands that are logged separately
(EXPN/VRFY/ETRN). Unless this happens very often, you
can ignore this. If it happens very often, it's either someone playing
around or it's a network problem.
Note 1: The significant part of the message isn't the NOQUEUE,
but the "Null connection from ...". In particular,
NOQUEUE isn't an error indication, but just a "place-holder"
when no queue ID has been assigned, typically because message collection
hasn't started (yet). It can occur in other messages too, and there too the
significant part is what comes after the NOQUEUE.
Note 2: In 8.10, the text which led to the confusion has been changed to:
"... did not issue MAIL/EXPN/VRFY/ETRN during connection to ...".
You don't. Sendmail is a mail transfer agent whose primary purpose is to send and receive e-mail (primarily via SMTP). Sendmail does not implement any remote access protocols such as POP or IMAP. But if you want to learn more about these and other (non-sendmail) e-mail related things, please refer to our Other (Non-Sendmail) E-Mail Related Links page.
It would require custom programming. You could either write a mail filter using the new Milter API in sendmail 8.10 and later (see libmilter/README) or you could look at some of these other unsupported hints:
There is no magic short-cut for this. But it is not hard to set up: create an aliases entry
alluser: :include:/etc/mail/allusersDon't forget to run 'newaliases'. Then list your users, one per line, in the file '/etc/mail/allusers'. You might be able to do that with
awk -F: '$3 > 100 { print $1 }' /etc/passwd > /etc/mail/allusers
Several vendors have changed the way that sendmail is run. They decided that most people need a client-only version of sendmail. So it is listening only on the localhost interface. Check the system documentation on how to change your .mc file. Here is a partial table of where some vendors ship their sendmail configuration hierarchy:
| sendmail distribution | ./cf |
| Solaris 7,8,9 | /usr/lib/mail |
| Solaris 10 | /etc/mail/cf |
| Red Hat 6.2 | /usr/lib/sendmail-cf |
| Red Hat 7 | /usr/share/sendmail-cf |
| Slackware 7.1 | /usr/src/sendmail/cf |
proto.m4", then go up the tree one level. When you
find the .mc file, look for the string "DAEMON_OPTIONS" and
for the comment lines near that string.
See also 5.3.1.3 for discussion about this problem as it relates specifically to Red Hat 7.1 and later.
sendmail itself does not look at the content of a message, so it is not in a position to strip attachments. You need a filtering package that works with sendmail. You might want to look at www.milter.org for some open source solutions that use our "milter" facility. There's also something called MIMEDefang that can do it. You can also get commercial products to do it (see www.sendmail.com for example).
If the e-mail comes from example.com, you have to look up
the MX or A records for example.com to figure out which mail
server to ask if the user is valid. The DNS could be slow or unresponsive.
The remote server could be slow or unresponsive.
If you were to make such checks, a bad guy could bombard you with mail
claiming to come from hotmail.com users, and then suddenly
you would be connection-bombing Hotmail's mail servers asking them about
the recipients the bad guy is claiming to be.
The only safe way to do this is to verify that the sender exists when the sender claims to be in your domain. Naturally you are then in a position to confirm or deny the sender is valid.