f



8.15.1, about header rewriting fails due to a temporary map lookup failure

Hello.

RELEASE_NOTES of 8.15.1 contains warning:

|   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.

It seems to me that it's not a good change for a some of cases.
Can it be disabled in sendmail.cf or in compile time ?

Additionally. Is it difficult to specify exactly what domain is
causing the error ? The error message is not informative now:

Dec  2 10:18:23 mail sm-msp-queue[1402]: uAT1Nkk3567536: to=mail@example.com, delay=3+05:23:07, xdelay=00:00:04, mailer=relay, pri=
138992339, relay=localhost.localdomain. [127.0.0.1], dsn=4.0.0, stat=Deferred: Name server: localhost.localdomain.: host name lookup failure

-- 
Regards, Sergey

0
Sergey
12/5/2016 1:02:06 PM
comp.mail.sendmail 13518 articles. 1 followers. jfretby (35) is leader. Post Follow

6 Replies
123 Views

Similar Articles

[PageSpeed] 37

Sergey  wrote:

> RELEASE_NOTES of 8.15.1 contains warning:

> |   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.

There's more in that entry, esp.

	See also "DNS Lookups" in sendmail/TUNING.

> It seems to me that it's not a good change for a some of cases.
> Can it be disabled in sendmail.cf or in compile time ?

follow the hint to "see also" and you'll find:

  Note: starting with 8.15, sendmail will not ignore temporary map
  lookup failures during header rewriting, which means that DNS lookup
  problems even for headers will cause messages to stay in the queue.
  Hence it is strongly suggested to use the nocanonify feature;
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

BTW: there could also be some trick to redefine the host map
to ignore temp.errors, e.g., quoting op.*

      -t        Normally, when a map attempts to do a lookup
                and  the  server   fails   (e.g.,   sendmail
                couldn't  contact  any  name server; this is
                not the same as an entry not being found  in
                the  map),  the  message  being processed is
                queued for future processing.  The  -t  flag
                turns  off this behavior, letting the tempo-
                rary failure (server down) act as though  it
                were  a permanent failure (entry not found).
                It is particularly useful for  DNS  lookups,
                where   someone  else's  misconfigured  name
                server can cause problems on  your  machine.
                However,  care  must be taken to ensure that
                you don't bounce mail that would be resolved
                correctly  if  you  tried  again.   A common
                strategy is to forward such mail to another,
                possibly better connected, mail server.


> Additionally. Is it difficult to specify exactly what domain is
> causing the error ? The error message is not informative now:

If someone has a patch, please send it.

-- 
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.
0
Claus
12/5/2016 2:42:04 PM
Claus Aßmann wrote:

>> RELEASE_NOTES of 8.15.1 contains warning:
> 
>> |   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.
> 
> There's more in that entry, esp.
> 
>       See also "DNS Lookups" in sendmail/TUNING.

Sorry. Somehow I thought about op/TUNING.

>   Note: starting with 8.15, sendmail will not ignore temporary map
>   lookup failures during header rewriting, which means that DNS lookup
>   problems even for headers will cause messages to stay in the queue.
>   Hence it is strongly suggested to use the nocanonify feature;
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I seems that I already read and used this some years ago... Hm.
I try it now (added it to mc and rebuilt sendmail.cf), but it's
not working for me.

About the situation in more detail. Some messages (which received
by MTA) are redirected to special archive mailbox via bin/sendmail
by milter. Some of it stays in spool/clientmqueue due to a problem
with one of the e-mail in "To" field. Somewhere there is a difference
in the delivery from Internet and from localhost.

I use 8.15.2 now.

-- 
Regards, Sergey

0
Sergey
12/6/2016 2:24:08 PM
Sergey  wrote:
> Claus Aßmann wrote:

> >   Hence it is strongly suggested to use the nocanonify feature;

> About the situation in more detail. Some messages (which received
> by MTA) are redirected to special archive mailbox via bin/sendmail
> by milter. Some of it stays in spool/clientmqueue due to a problem
> with one of the e-mail in "To" field. Somewhere there is a difference
> in the delivery from Internet and from localhost.

Looks like your submit.mc needs the same feature?

-- 
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.
0
Claus
12/6/2016 4:34:23 PM
Claus Aßmann wrote:

>> >   Hence it is strongly suggested to use the nocanonify feature;
> 
>> About the situation in more detail. Some messages (which received
>> by MTA) are redirected to special archive mailbox via bin/sendmail
>> by milter. Some of it stays in spool/clientmqueue due to a problem
>> with one of the e-mail in "To" field. Somewhere there is a difference
>> in the delivery from Internet and from localhost.
> 
> Looks like your submit.mc needs the same feature?

Why (but I tried it. unsuccessfully) ? bin/sendmail accepted mail and
sm-msp-queue attempt to process it. MTA process receive but drop connection:

Dec  7 18:19:32 sendmail[9251]: uB7EJQOI009251: --- 250 2.1.5 <arh@mail>... Recipient ok
Dec  7 18:19:32 sendmail[9251]: uB7EJQOI009251: <-- DATA
Dec  7 18:19:32 sendmail[9251]: uB7EJQOI009251: --- 354 Enter mail, end with "." on a line by itself
Dec  7 18:19:37 sm-msp-queue[9243]: uB61gokx022204: SYSERR(root): timeout writing message to localhost.localdomain.
Dec  7 18:19:37 sm-msp-queue[9243]: uB61gokx022204: to=arh@mail, delay=1+12:36:47, xdelay=00:00:11,
   mailer=relay, pri=28023025, relay=localhost.localdomain. [127.0.0.1], dsn=4.0.0,
   stat=Deferred: Name server: localhost.localdomain.: host name lookup failure
Dec  7 18:19:37 sendmail[9251]: uB7EJQOI009251: collect: premature EOM: unexpected close
Dec  7 18:19:37 sendmail[9251]: uB7EJQOI009251: collect: unexpected close on connection from localhost.localdomain, sender=<>

Ou, possible I need to increase timeouts in submit.mc.
I'll try later today or tomorrow morning.

-- 
Regards, Sergey

0
Sergey
12/7/2016 2:33:11 PM
Sergey  wrote:

> Dec  7 18:19:37 sm-msp-queue[9243]: uB61gokx022204: to=arh@mail, delay=1+12:36:47, xdelay=00:00:11,
>    mailer=relay, pri=28023025, relay=localhost.localdomain. [127.0.0.1], dsn=4.0.0,
>    stat=Deferred: Name server: localhost.localdomain.: host name lookup failure

This seems to indicate that sm-msp-queue has the "problem".
So you could run it in verbose mode with some debugging
and see what's going on, e.g., something like:

sendmail -Ac -qIuB61gokx022204 -v -d8.9 -d9.1

(see TRACEFLAGS for more "interesting" debug settings).
0
Claus
12/7/2016 4:28:04 PM
Claus Aßmann wrote:

> sendmail -Ac -qIuB61gokx022204 -v -d8.9 -d9.1
> 
> (see TRACEFLAGS for more "interesting" debug settings).

The problem domain was fixed tonight. I lost opportunity
to try, I will have to wait next case.

-- 
Regards, Sergey

0
Sergey
12/8/2016 5:41:55 AM
Reply: