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 at 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 at centos.org > http://lists.centos.org/mailman/listinfo/centos-- Fabian Arrotin <fabian.arrotin at arrfab.net> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20060621/74e2eb58/attachment-0002.sig>
On 21/06/06, Fabian Arrotin <fabian.arrotin at 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 at 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 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. -- Les Mikesell lesmikesell at gmail.com