Where are the logs?
The default location depends on your linux/unix system, but the most common places are
- /var/log/maillog
- /var/log/mail.log
- /var/adm/maillog
- /var/adm/syslog/mail.log
If it's not there, look up /etc/syslog.conf
. You should see something like this
mail.* -/var/log/maillog
sendmail writes logs to the mail
facility of syslog. Therefore, which file it gets written to depends on how syslog was configured.
If you system uses syslog-ng (instead of the more "traditional" syslog), then you'll have to look up your syslog-ng.conf
file. You'll should something like this:
# This files are the log come from the mail subsystem.
#
destination mail { file("/var/log/mail.log"); };
destination maillog { file("/var/log/maillog"); };
destination mailinfo { file("/var/log/mail.info"); };
destination mailwarn { file("/var/log/mail.warn"); };
destination mailerr { file("/var/log/mail.err"); };
Unable to send out emails?
One of the most common reason I've seen for a freshly installed sendmail not being able to send out emails is the DAEMON_OPTIONS being set to listen only on 127.0.0.1
See /etc/mail/sendmail.mc
dnl #
dnl # The following causes sendmail to only listen on the IPv4 loopback address
dnl # 127.0.0.1 and not on any other network devices. Remove the loopback
dnl # address restriction to accept email from the internet or intranet.
dnl #
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
If that's your case, remove the "Addr=127.0.0.1" part, rebuild your conf file and you're good to go!
DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
[root@server]$ m4 sendmail.mc > /etc/sendmail.cf
[root@server]$/etc/init.d/sendmail restart
If you've been making changes to /etc/sendmail.cf manually thus far (instead of the *.m4 file) you can make similar changes in /etc/sendmail.cf. The offending line will look like this:
O DaemonPortOptions=Port=smtp,Addr=127.0.0.1, Name=MTA
Change it to:
O DaemonPortOptions=Port=smtp, Name=MTA
sendmail (a mail transport agent - MTA) stores mail in the place where it is configured to store mail. But an MTA only stores mail which it is currently queueing - delivery of mail to the location where it is accessible by a user is handled by the mail delivery agent (MDA). While sendmail (and other MTAs) can act as an MDA, it's very unusual for that to be the case.
Regardless, trying to access the mail files is not the right way to implement an autoresponder.
This should be done as a filter in the MTA (i.e. a milter) or in the MDA. The milter API is specifically designed for this - and there may already be tools available which would meet your requirement with no modification.
If your current MDA is procmail then in you're in luck - this provides a huge amount of flexibility (indeed its a programming language in its own right) for handling mail messages. Again there is lots of code on the internet which may meet your needs (AFAIK there is no central respository for procmail recipes - but try google).
Even the basic .forward mechanism can be used to implement this - but I'd advise against this - goingdown the procmail route you can fork the message so that delivery is not dependent upon/implemented by your script.
Best Answer
if you're open to using a different MTA or at least an intermediate MTA, have a look at qpsmtpd. i currently use qpsmtpd to convert incoming uuencoded emails from some legacy apps we use to MIME.
here's what i use, which is a modified version of the tnef2mime plugin (so please ignore any extra cruft and references to tnef2mime). this could be easily modified to remove the existing message-id header and add a new one.