Guys,
I've had a weird problem with Sendmail misbehaving in a way I don't really understand. I've worked round the problem but I'd like to understand what was going on.
The MX for one of our domains, blah.com, pointed at an internal Exchange server. Mail relayed to a Sendmail MailScanner which then delivered to Exchange for this domain. The domain expired leading to all its mail queueing in Sendmail. So far so sensible.
While waiting for the domain to be renewed I setup a mailertable entry to bypass DNS and route mail directly to the Exchange server...
blah.com smtp:[192.168.10.10]
I rebuilt mailertable then tried flushing the queue with...
sendmail -q -v -qRblah
... which resulted in a bunch of "Transient parse error -- message queued for future delivery" errors due to DNS resolution failure.
I thought mailertable entries bypassed DNS? Does Sendmail cache the state of the destination for queued messages somehow? In the qf${msgid} files in the spool?
I tried restarting MailScanner (and hence both Sendmail processes), same problem. I read ( http://www.sendmail.org/~ca/email/doc8.12/op-sh-3.html ) that Sendmail can, when configured with HostStatusDirectory enabled, retain information on the status of hosts on disk but "sendmail -bh" returned nothing and "sendmail -bH", just in case, didn't help either.
So, was mailertable being bypassed because these messages had already been attempted to be delivered before the mailertable changes? Anyone know what was going on here? I worked around it by just setting up a quick zone for blah.com with an MX in it but I'd like to understand WTF was going on with mailertable for future reference.
Will.
On 21/06/06, Will McDonald wmcdonald@gmail.com wrote:
Guys,
I've had a weird problem with Sendmail misbehaving in a way I don't really understand. I've worked round the problem but I'd like to understand what was going on.
Oh, and this is on:
sendmail-8.13.1-3.RHEL4.5 CentOS release 4.3 (Final)
I've installed a lot of Sendmail/MailScanner smtp relays on CentOS and i've never encountered a problem like this ... I manipulate the mailertable and i issue makemap hash /etc/mail/mailertable < /etc/mail/mailertable to reconstruct the mailertable. The difference i have is that i don't use ip address but hostnames in the mailertable : domain.org smtp:[central.domain.org]
Of course central.domain.org is not an official A record but just a entry in my /etc/hosts file (to avoid dns resolution) ...
On Wed, 2006-06-21 at 11:23 +0100, Will McDonald wrote:
Guys,
I've had a weird problem with Sendmail misbehaving in a way I don't really understand. I've worked round the problem but I'd like to understand what was going on.
The MX for one of our domains, blah.com, pointed at an internal Exchange server. Mail relayed to a Sendmail MailScanner which then delivered to Exchange for this domain. The domain expired leading to all its mail queueing in Sendmail. So far so sensible.
While waiting for the domain to be renewed I setup a mailertable entry to bypass DNS and route mail directly to the Exchange server...
blah.com smtp:[192.168.10.10]
I rebuilt mailertable then tried flushing the queue with...
sendmail -q -v -qRblah
... which resulted in a bunch of "Transient parse error -- message queued for future delivery" errors due to DNS resolution failure.
I thought mailertable entries bypassed DNS? Does Sendmail cache the state of the destination for queued messages somehow? In the qf${msgid} files in the spool?
I tried restarting MailScanner (and hence both Sendmail processes), same problem. I read ( http://www.sendmail.org/~ca/email/doc8.12/op-sh-3.html ) that Sendmail can, when configured with HostStatusDirectory enabled, retain information on the status of hosts on disk but "sendmail -bh" returned nothing and "sendmail -bH", just in case, didn't help either.
So, was mailertable being bypassed because these messages had already been attempted to be delivered before the mailertable changes? Anyone know what was going on here? I worked around it by just setting up a quick zone for blah.com with an MX in it but I'd like to understand WTF was going on with mailertable for future reference.
Will. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 21/06/06, Fabian Arrotin fabian.arrotin@arrfab.net wrote:
I've installed a lot of Sendmail/MailScanner smtp relays on CentOS and i've never encountered a problem like this ... I manipulate the mailertable and i issue makemap hash /etc/mail/mailertable < /etc/mail/mailertable to reconstruct the mailertable. The difference i have is that i don't use ip address but hostnames in the mailertable : domain.org smtp:[central.domain.org]
Of course central.domain.org is not an official A record but just a entry in my /etc/hosts file (to avoid dns resolution) ...
I should've mentioned this mailtertable was, and is, working for another domain in the exact same form (i.e. IP rather the hostname). It just appears to be messages which would've been routed differently before the mailertable changes IYSWIM.
I tried rebuilding it using both "make -C /etc/mail" and a manual makemap. I neglected to run strings just to verify the mailertable.db contained the relevant entry but I've just done so and it does.
Will.
On 6/21/06, Will McDonald wmcdonald@gmail.com wrote:
I thought mailertable entries bypassed DNS?
Are you sure there's not some other DNS-based check involved, such as (not that it would be this specific one) the sender-domain-must-resolve check for spam prevention? Just because sendmail doesn't use DNS to reach the destination MTA doesn't mean it isn't attempting to validate the message via DNS lookups.
On 21/06/06, Bart Schaefer barton.schaefer@gmail.com wrote:
On 6/21/06, Will McDonald wmcdonald@gmail.com wrote:
I thought mailertable entries bypassed DNS?
Are you sure there's not some other DNS-based check involved, such as (not that it would be this specific one) the sender-domain-must-resolve check for spam prevention? Just because sendmail doesn't use DNS to reach the destination MTA doesn't mean it isn't attempting to validate the message via DNS lookups.
I couldn't say for sure but I don't think this is the case. DNS *is* actually working for everything bar one domain. 'accept_unresolvable_domains' wasn't defined but the hosts all mail for the non-existent domain originates from would be listed in /etc/mail/access.
The sendmail.mc is as follows...
define(`confDEF_USER_ID',``8:12'')dnl define(`confTO_CONNECT', `1m')dnl define(`confTRY_NULL_MX_LIST',true)dnl define(`confDONT_PROBE_INTERFACES',true)dnl define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl define(`ALIAS_FILE', `/etc/aliases')dnl define(`STATUS_FILE', `/var/log/mail/statistics')dnl define(`UUCP_MAILER_MAX', `2000000')dnl define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl define(`confAUTH_OPTIONS', `A')dnl define(`confTO_IDENT', `0')dnl FEATURE(`no_default_msa',`dnl')dnl FEATURE(`smrsh',`/usr/sbin/smrsh')dnl FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl FEATURE(redirect)dnl FEATURE(always_add_domain)dnl FEATURE(use_cw_file)dnl FEATURE(use_ct_file)dnl FEATURE(local_procmail,`',`procmail -t -Y -a $h -d $u')dnl FEATURE(`access_db',`hash -T<TMPF> -o /etc/mail/access.db')dnl FEATURE(`blacklist_recipients')dnl EXPOSED_USER(`root')dnl FEATURE(`greet_pause', `5000')dnl 5 seconds DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl LOCAL_DOMAIN(`mailscanner1')dnl MAILER(smtp)dnl MAILER(procmail)dnl
I wonder, the other domain we routed mail for via mailertable is also included in /etc/mail/relay-domains, the domain we couldn't route for isn't.
Will.
On Wed, 2006-06-21 at 05:23, Will McDonald wrote:
The MX for one of our domains, blah.com, pointed at an internal Exchange server. Mail relayed to a Sendmail MailScanner which then delivered to Exchange for this domain. The domain expired leading to all its mail queueing in Sendmail. So far so sensible.
While waiting for the domain to be renewed I setup a mailertable entry to bypass DNS and route mail directly to the Exchange server...
blah.com smtp:[192.168.10.10]
I rebuilt mailertable then tried flushing the queue with...
sendmail -q -v -qRblah
... which resulted in a bunch of "Transient parse error -- message queued for future delivery" errors due to DNS resolution failure.
I think files in the queue have already saved the final destination after all lookups in their control files. If that was a name when the first attempt failed it will be a name on the retries.
I thought mailertable entries bypassed DNS?
I can - or the [name] notation can make it take an A record first instead of trying for an MX.
Does Sendmail cache the state of the destination for queued messages somehow? In the qf${msgid} files in the spool?
Yes, I think that is your problem. An entry in /etc/hosts should have allowed the delivery to complete, though.
On 21/06/06, Les Mikesell lesmikesell@gmail.com wrote:
Does Sendmail cache the state of the destination for queued messages somehow? In the qf${msgid} files in the spool?
Yes, I think that is your problem. An entry in /etc/hosts should have allowed the delivery to complete, though.
I should've maybe grubbed around in those queue files a bit more. I did add a hosts entry for mail.blah.com and tried to re-send and that didn't *seem* to help. Perhaps I'll setup some test domains and have a play.
Will.
-
Bart Schaefer -
Fabian Arrotin -
Les Mikesell -
Will McDonald