Note: This web page was automatically created from a PalmOS "pedit32" memo.

sendmail notes

/usr/lib/sendmail -v -qIfLAA22711 | less -sc This should do a verbose queue "sweep", but only for messages whose queue ID contains the string "fLAA22711". The option itself is "-qI", and sendmail doesn't want a space in between. -d2112 wasn't informative in this case. This allowed us to quickly determine that a honeypot SMTP server was being accessed only because the legitmate mail servers were rejecting the message, each in turn, due to an unresolvable address in the message envelope. Here's part of some sample output: Hello [], pleased to meet you 250-ENHANCEDSTATUSCODES 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 20000000 250-DSN 250-ONEX 250-ETRN 250-XUSR 250 HELP >>> MAIL From:<> SIZE=4038 451 4.1.8 <>... Domain of sender address does not resolve Connecting to via ether... Closing connection to >>> QUIT 221 2.0.0 closing connection
[root@wintermute ~]# grep silly /etc/mail/access ERROR:"550 Fix your stupid spam blocker"
Delivery agent flags: You can find a pretty good list of the flags for your, for example, Mlocal line, in: ./sendmail/sendmail.h ...within your sendmail source distribution. This -may- be the flag to prevent delivery to maildrops when .forward's are unavailable due to homedir (NFS) problems: #define M_CHECKHDIR '~' /* SGI: check for valid home directory */
Am I the only one who noticed, during the dcs.nac downtime, that e-mail that should've been refiled to a home directory folder, instead went to /var/mail/$USER, apparently due to sendmail not waiting for the homedir to come back prior to delivery? Anyway, here are the mailer options for the RHEL Mlocal (local delivery agent invocation) and the legacy mostly-V5 Mlocal we're using on most of the others (so far :). Legacy: lsDFMAw5:/|@ SPfhn mE RHEL: lsDFMAw5:/|@qSPfhn9 So RHEL has the addition of: q and 9 ...and removed: m and E I had originally hypothesized that we needed the "~" option, until I saw these differences. Also, although a header file in the sendmail distribution defines this option, it apparently makes no attempt to actually Use it. Anyway, here are the (tersely defined) meanings of the options: #define M_CHECKHDIR '~' /* SGI: check for valid home directory */ #define M_VRFY250 'q' /* VRFY command returns 250 instead of 252 */ #define M_MAKE8BIT '9' /* convert 7 -> 8 bit if appropriate */ #define M_MUSER 'm' /* can handle multiple users at once */ #define M_ESCFROM 'E' /* escape From lines to >From */ So none of those really look relevant. This, in the release notes, does though, although it was introduced in 8.8.0 - IE, some time ago: Only queue messages on transient .forward open failures if there were no successful opens. The previous behavior caused it to queue even if a "fall back" .forward was found. Problem noted by Ann-Kian Yeo of the Dept. of Information Systems and Computer Science (DISCS), NUS, Singapore. Next time we see this, we'll probably have to make a note of which "E" error is being generated by a missing home directory, and verify that it is listed properly in transienterror() of conf.c in the sendmail distribution.
When testing a sendmail change, it's usually important to test at -least- the following: 1) Incoming mail from another system to sherlock 2) Incoming mail sent from sherlock to sherlock 3) Outgoing mail sent from sherlock to another system
Nice URL about configuring sendmail on Solaris:
You can check the status of messages in that directory using the mailq command. It normally looks in /var/spool/mqueue but you can get it to look in other directories: mailq -OQueueDirectory=/var/spool/clientmqueue This also works for MailScanner inbound queue: mailq -OQueueDirectory=/var/spool/
FYI, I've updated 928-10-m4sendmail so that mail clients will not start the sendmail binary in daemon mode, i.e. they will not answer on port 25. It will only run to process the /var/spool/mqueue and /var/spool/clientmqueue directories. For Solaris 9 and 10, you will need the "D{MTAHost}" field in /etc/mail/ to be set to $MAILHOST for this to function correctly; the each script makes this change for you. If this causes a problem, you can remove the file /etc/default/sendmail and change field to "D{MTAHost}[]" to revert back to the previous behavior. -Francisco

Back to Dan's palm memos