Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

mail queued and not delivered - looking for wrong DNS server

34 views
Skip to first unread message

Hans Mayer

unread,
Jan 15, 2015, 8:07:32 AM1/15/15
to

Dear All,

For our domain "iiasa.ac.at" I am running 2 e-mail gateways in DMZ network with sendmail version 8.15.1 on Solaris 11.2
These gateways are forwarding all e-mails to an internal SMTP server.
We are processing around one e-mail per second successfully. But sometimes it happens that an e-mail is received but not delivered to internal and therefore it stays in the mail-queue. Now I analyzed one of this issues and I was really wondering. When I run "mailq" I see this:

/var/spool/mqueue (1 request)
-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient-----------
t0F6QIil020885 576347 Thu Jan 15 07:26 <k.sc...@eep.at>
(host map: lookup (begas.at): deferred)
<xxx...@iiasa.ac.at>

( I changed the user name to xxxxxx )

At that moment I was already wondering about the entry "begas.at" because the e-mail is coming from "eep.at" delivered to us "iiasa.ac.at" ( BTW: begas was an energy provider in Burgenland which is now energieburgenland.at )

I run manually:

# /usr/lib/sendmail -v -qRxx...@iiasa.ac.at

Running /var/spool/mqueue/t0F6QIil020885 (sequence 1 of 1)
<xxx...@iiasa.ac.at>... Connecting to jump4.iiasa.ac.at. port 18000 via local...
220 ismtpgw.iiasa.ac.at ESMTP IIASA mta; Thu, 15 Jan 2015 13:27:34 +0100 (CET)
>>> EHLO dzsmtp3.iiasa.ac.at
250-ismtpgw.iiasa.ac.at Hello jump2 [147.125.80.33], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE 50000000
250-DSN
250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5
250-DELIVERBY
250 HELP
>>> MAIL From:<k.sc...@eep.at> SIZE=578698
250 2.1.0 <k.sc...@eep.at>... Sender ok
>>> RCPT To:<xxxxxx>
>>> DATA
250 2.1.5 <xxxxxx>... Recipient ok
354 Enter mail, end with "." on a line by itself
begas.at: Name server timeout
timeout writing message to jump4.iiasa.ac.at.
<xxx...@iiasa.ac.at>... Deferred: Name server: jump4.iiasa.ac.at.: host name lookup failure
Closing connection to jump4.iiasa.ac.at.

Look at the line
begas.at: Name server timeout

Indeed there is no domain name server for begas:

# nslookup -type=ns begas.at
Server: 127.0.0.1
Address: 127.0.0.1#53

** server can't find begas.at: SERVFAIL

But from where it comes ?
I looked in file /var/spool/mqueue/qft0F6QIil020885
In the "To:" field there are about 25 recipients with many different domains. One is the user xxxxxx of our domain and the last line is:
"Stifter Otmar" <otmar....@begas.at>

So I am wondering why is sendmail checking DNS server which are totally not relevant for us.
Any idea what I can do in future to avoid such issues ?

( I modified the q-file in which I removed this line. After that I run sendmail -q and this queued e-mail was immediately forwarded to the internal mail system. )

I backed up the original q- and d- file for possible further analysis.


Kind regards
Hans

--



Claus Aßmann

unread,
Jan 15, 2015, 8:50:03 AM1/15/15
to
Hans Mayer wrote:

> For our domain "iiasa.ac.at" I am running 2 e-mail gateways in DMZ network with sendmail
> version 8.15.1 on Solaris 11.2

> t0F6QIil020885 576347 Thu Jan 15 07:26 <k.sc...@eep.at>
> (host map: lookup (begas.at): deferred)

> >>> DATA
> 250 2.1.5 <xxxxxx>... Recipient ok
> 354 Enter mail, end with "." on a line by itself
> begas.at: Name server timeout

> In the "To:" field there are about 25 recipients with many different domains. One is the
> user xxxxxx of our domain and the last line is:
> "Stifter Otmar" <otmar....@begas.at>

> So I am wondering why is sendmail checking DNS server which are totally not relevant for us.
> Any idea what I can do in future to avoid such issues ?

Did you read the fine documentation, starting with the release notes?

If header rewriting fails due to a temporary map lookup failure,
queue the mail for later retry instead of sending it
without rewriting the header. Note: this is done
while the mail is being sent and hence the transaction
is aborted, which only works for SMTP/LMTP mailers
hence the handling of temporary map failures is
suppressed for other mailers. SMTP/LMTP servers may
complain about aborted transactions when this problem
occurs.
See also "DNS Lookups" in sendmail/TUNING.


--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Hans Mayer

unread,
Jan 15, 2015, 11:16:23 AM1/15/15
to

Dear Claus,

Many thanks for your fast and competent answer.
As far as I can see this is partly a new feature of version 8.15
I have to investigate a little bit more reading the documentation.

I tried to reproduce the situation from home but unfortunately I have there sendmail version 8.15.1 too and the e-mail isn't reaching the office gateway.

Thanks, I will come back if there are additional questions. ( Which will be probably be the situation :-)

// Hans

--

Hans Mayer

unread,
Jan 27, 2015, 5:35:46 AM1/27/15
to

Dear Claus,

Thanks for your feedback.

FEATURE(`nocanonify')

did the trick.


Kind regards
Hans

--
0 new messages