RCPT To: timeouts problem

Hello.
I am facing RCPT TO timeouts problems with Sendmail 8.13.1 on a centos 4
machine.

The time delay between the "RCPT TO:" command and it's answer from sendmail
is about 2-3 minutes on my side, which is obviously far too long and
indicates a problem somewhere.
However, for the "MAIL FROM:" command, the answer is immediate.
This happens only when I send an e-mail to a virtual domain on the server
(defined in the /etc/mail/access.db file). When using the main domain then
this problem isn't there.
It has been working great for months and now suddenly it has been broken.
I just moved the server to another IP address and it might be related, but I
just changed the IP adresses so I this shouldn't be coming from this.

Could someone help me on that?
Some other people had the same problem already in the past, but no solution
is provided:
http://groups.google.ch/group/comp.mail.sendmail/browse_thre ad/thread/3439a754d9926371/6c914be783546c7d?hl=fr&lnk=st&q=s endmail+%22rcpt+to%22+very+slow&rnum=14

Thanks for any help.
Daniel

Re: RCPT To: timeouts problem

In article <4a380$470cf768$55da0a86$31663@news.hispeed.ch>,
"doolyo" wrote:

> Hello.
> I am facing RCPT TO timeouts problems with Sendmail 8.13.1 on a centos 4
> machine.
>
> The time delay between the "RCPT TO:" command and it's answer from sendmail
> is about 2-3 minutes on my side, which is obviously far too long and
> indicates a problem somewhere.
> However, for the "MAIL FROM:" command, the answer is immediate.
> This happens only when I send an e-mail to a virtual domain on the server
> (defined in the /etc/mail/access.db file). When using the main domain then
> this problem isn't there.
> It has been working great for months and now suddenly it has been broken.
> I just moved the server to another IP address and it might be related, but I
> just changed the IP adresses so I this shouldn't be coming from this.
>
> Could someone help me on that?
> Some other people had the same problem already in the past, but no solution
> is provided:
> http://groups.google.ch/group/comp.mail.sendmail/browse_thre ad/thread/3439a754
> d9926371/6c914be783546c7d?hl=fr&lnk=st&q=sendmail+%22rcpt+to %22+very+slow&rnum
> =14

You might want to run a ktrace, strace, or whatever kernel call trace
you have and display the results with timestamps. That way you can see
where in the process the delay occurs. That should help focus your
investigation.

RCPT To: timeouts problem

> You might want to run a ktrace, strace, or whatever kernel call trace
> you have and display the results with timestamps. That way you can see
> where in the process the delay occurs. That should help focus your
> investigation.

Agreed. Also get on the host, run

/usr/sbin/sendmail -d21.1 -bs

and type the helo, mail, rcpt commands. 21.1 shows rewriting, Maybe
you can catch what rule it is doing when it gets stuck.

I wonder if you might have a huge virtusertable and no db version, or
something like that. We once accidentally had a host running with
aliases and no aliases.db and reading a flat file sure slows things
down.

Joseph Brennan
Columbia University IT

Re: RCPT To: timeouts problem

Joe Brennan wrote:
>> You might want to run a ktrace, strace, or whatever kernel call trace
>> you have and display the results with timestamps. That way you can see
>> where in the process the delay occurs. That should help focus your
>> investigation.
>
> Agreed. Also get on the host, run
>
> /usr/sbin/sendmail -d21.1 -bs
>
> and type the helo, mail, rcpt commands. 21.1 shows rewriting, Maybe
> you can catch what rule it is doing when it gets stuck.
>
> I wonder if you might have a huge virtusertable and no db version, or
> something like that. We once accidentally had a host running with
> aliases and no aliases.db and reading a flat file sure slows things
> down.

But the OP mentioned a sudden problem that occurred after an IP number
change. A delay caused by large flat file lookups doesn't come first
in my mind in this case.

The OP didn't supply much detail, only:
The time delay between the "RCPT TO:" command and it's answer
from sendmail is about 2-3 minutes on my side, which is obviously
far too long and indicates a problem somewhere.
However, for the "MAIL FROM:" command, the answer is immediate.
This happens only when I send an e-mail to a virtual domain on the
server (defined in the /etc/mail/access.db file). When using the
main domain then this problem isn't there.

I'm wondering what exactly is defined in /etc/mail/access.db and
what other checks are performed to validate recipient addresses.
The fact that the delay doesn't occur "when using the main domain"
indicates that access to /etc/mail/access.db probably isn't the
problem. There must be other checks involved in validating the
recipient's address. Common (network based) checks include LDAP
lookups of the recipient's address and SMTP connections to the
final destination host. Issues to check when an IP number change
causes trouble include: dns/resolver problems and firewall settings.

It would be helpful if the OP showed more detail about his sendmail
configuration. The full contents of the *.mc file that was used to
generate his sendmail.cf, but with the comments removed, would be great.
Something like the output of: grep -v '^dnl' sendmail.mc

Regards,

Kees.

--
Kees Theunissen.

Re: RCPT To: timeouts problem

>> Agreed. Also get on the host, run
>>
>> /usr/sbin/sendmail -d21.1 -bs
>>
>> and type the helo, mail, rcpt commands. 21.1 shows rewriting, Maybe
>> you can catch what rule it is doing when it gets stuck.

I tried to do this, but then the client is refused the access, I don't know
why:

telnet: Unable to connect to remote host: Connection refused

I normally run sendmail with "service sendmail start".

> It would be helpful if the OP showed more detail about his sendmail
> configuration. The full contents of the *.mc file that was used to
> generate his sendmail.cf, but with the comments removed, would be great.
> Something like the output of: grep -v '^dnl' sendmail.mc
>

Ok, here is the file in details.
Please note that I have "poprelay" installed, which explains the strange
lines. However this has been working for months with no problems and hasn't
changed since.

--------------------------
divert(-1)dnl
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl
VERSIONID(`setup for Red Hat Linux')dnl
OSTYPE(`linux')dnl
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,/etc/mail/sympa_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 -o /etc/mail/access.db')dnl
Klocalip hash -a /etc/mail/access
Kpopip hash -a /etc/mail/popip
LOCAL_RULESETS
SLocal_check_rcpt
R$* $: $>Parse0 $>3 $1
R$* < $* > $* $: $1 < $2 . > $3
Pretend it's canonical.
R$* < $* . . > $* $1 < $2 . > $3
Remove extra dots.
R$* $: < $&{client_addr} > Get client
IP address.
R<> $#OK Local is ok.
R< $* . $- > $* $(localip $1.$2 $: < $1 > . $2 $) Check last
three octets.
R$* < MATCH > $#OK
R< $- > $* $: $(localip $1 $: < > $1 $2 $) Check first
octet.
R$* < MATCH > $#OK
R$* $: < $&{client_addr} > Get client
IP address.
R< $* > $(popip $1 $) Check full
address.
R$* < MATCH > $#OK


FEATURE(`blacklist_recipients')dnl
EXPOSED_USER(`root')dnl
FEATURE(`accept_unresolvable_domains')dnl
LOCAL_DOMAIN(`localhost.localdomain')dnl
MAILER(smtp)dnl
MAILER(procmail)dnl

---------------------

Also, my access file shows only this:
defaultsite.com OK
virtualsite.com OK


Thanks Kees.
Daniel

Re: RCPT To: timeouts problem

"doolyo" wrote in
news:420c0$470fecea$55da0a86$798@news.hispeed.ch:

>>> Agreed. Also get on the host, run
>>>
>>> /usr/sbin/sendmail -d21.1 -bs
>>>
>>> and type the helo, mail, rcpt commands. 21.1 shows rewriting,
>>> Maybe you can catch what rule it is doing when it gets stuck.
>
> I tried to do this, but then the client is refused the access, I don't
> know why:
>
> telnet: Unable to connect to remote host: Connection refused
>


Have you updated all your DNS entries to match the new IP address?

Andy

Re: RCPT To: timeouts problem

> Agreed. Also get on the host, run
>
> /usr/sbin/sendmail -d21.1 -bs
>
> and type the helo, mail, rcpt commands. 21.1 shows rewriting, Maybe
> you can catch what rule it is doing when it gets stuck.

I have executed this command.
The behaviour is a little bit different: The delay is reduced at 14 seconds
instead of 3 minutes. I have retested that with both techniques and these
daleays are reproducable.

After the "rcpt to:" command, onyl the first two lines are printed out
immediately (canonify and Canonify2), then it stays stuck for 14 seconds,
and then it prints out all the rest.
Below is the whole result just after the "rcpt to:" command:

rcpt to:dan@virtualdomain.com
rewrite: ruleset canonify input: dan @ virtualdomain . com
rewrite: ruleset Canonify2 input: dan < @ virtualdomain . com >
rewrite: ruleset Canonify2 returns: dan < @ virtualdomain . com . >
rewrite: ruleset canonify returns: dan < @ virtualdomain . com . >
rewrite: ruleset parse input: dan < @ virtualdomain . com . >
rewrite: ruleset Parse0 input: dan < @ virtualdomain . com . >
rewrite: ruleset Parse0 returns: dan < @ virtualdomain . com . >
rewrite: ruleset Parse1 input: dan < @ virtualdomain . com . >
rewrite: ruleset MailerToTriple input: < > dan < @ virtualdomain . com .
>
rewrite: ruleset MailerToTriple returns: dan < @ virtualdomain . com . >
rewrite: ruleset Parse1 returns: $# esmtp $@ virtualdomain . com .
$: dan < @ virtualdomain . com . >
rewrite: ruleset parse returns: $# esmtp $@ virtualdomain . com .
$: dan < @ virtualdomain . com . >
rewrite: ruleset 2 input: dan < @ virtualdomain . com . >
rewrite: ruleset 2 returns: dan < @ virtualdomain . com . >
rewrite: ruleset EnvToSMTP input: dan < @ virtualdomain . com . >
rewrite: ruleset PseudoToReal input: dan < @ virtualdomain . com . >
rewrite: ruleset PseudoToReal returns: dan < @ virtualdomain . com . >
rewrite: ruleset MasqSMTP input: dan < @ virtualdomain . com . >
rewrite: ruleset MasqSMTP returns: dan < @ virtualdomain . com . >
rewrite: ruleset EnvToSMTP returns: dan < @ virtualdomain . com . >
rewrite: ruleset final input: dan < @ virtualdomain . com . >
rewrite: ruleset final returns: dan @ virtualdomain . com
rewrite: ruleset check_rcpt input: dan @ virtualdomain . com
rewrite: ruleset Basic_check_rcpt input: dan @ virtualdomain . com
rewrite: ruleset Rcpt_ok input: dan @ virtualdomain . com
rewrite: ruleset ParseRecipient input: dan @ virtualdomain . com
rewrite: ruleset CanonAddr input: dan @ virtualdomain . com
rewrite: ruleset canonify input: dan @ virtualdomain . com
rewrite: ruleset Canonify2 input: dan < @ virtualdomain . com >
rewrite: ruleset Canonify2 returns: dan < @ virtualdomain . com . >
rewrite: ruleset canonify returns: dan < @ virtualdomain . com . >
rewrite: ruleset Parse0 input: dan < @ virtualdomain . com . >
rewrite: ruleset Parse0 returns: dan < @ virtualdomain . com . >
rewrite: ruleset CanonAddr returns: dan < @ virtualdomain . com . >
rewrite: ruleset ParseRecipient returns: dan < @ virtualdomain . com >
rewrite: ruleset Rcpt_ok returns: dan < @ virtualdomain . com >
rewrite: ruleset Relay_ok input: dan @ virtualdomain . com
rewrite: ruleset Relay_ok returns: RELAY
rewrite: ruleset Basic_check_rcpt returns: RELAY
rewrite: ruleset check_rcpt returns: RELAY
rewrite: ruleset localaddr input: dan @ virtualdomain . com
rewrite: ruleset Local_localaddr input: dan @ virtualdomain . com
rewrite: ruleset ParseRecipient input: dan @ virtualdomain . com
rewrite: ruleset CanonAddr input: dan @ virtualdomain . com
rewrite: ruleset canonify input: dan @ virtualdomain . com
rewrite: ruleset Canonify2 input: dan < @ virtualdomain . com >
rewrite: ruleset Canonify2 returns: dan < @ virtualdomain . com . >
rewrite: ruleset canonify returns: dan < @ virtualdomain . com . >
rewrite: ruleset Parse0 input: dan < @ virtualdomain . com . >
rewrite: ruleset Parse0 returns: dan < @ virtualdomain . com . >
rewrite: ruleset CanonAddr returns: dan < @ virtualdomain . com . >
rewrite: ruleset ParseRecipient returns: dan < @ virtualdomain . com >
rewrite: ruleset Local_localaddr returns: $# relay $@ [ 127 . 0 . 0 . 1 ]
$: dan < @ virtualdomain . com >
rewrite: ruleset localaddr returns: $# relay $@ [ 127 . 0 . 0 . 1 ]
$: dan < @ virtualdomain . com >
rewrite: ruleset 2 input: dan < @ virtualdomain . com >
rewrite: ruleset 2 returns: dan < @ virtualdomain . com >
rewrite: ruleset MasqSMTP input: dan < @ virtualdomain . com >
rewrite: ruleset MasqSMTP returns: dan < @ virtualdomain . com >
rewrite: ruleset final input: dan < @ virtualdomain . com >
rewrite: ruleset final returns: dan @ virtualdomain . com
250 2.1.5 dan@virtualdomain.com... Recipient ok

Any idea?
Daniel

Re: RCPT To: timeouts problem

In article <1afa6$4710d6e1$55da0a86$23707@news.hispeed.ch> "doolyo"
writes:
>> Agreed. Also get on the host, run
>>
>> /usr/sbin/sendmail -d21.1 -bs
>>
>> and type the helo, mail, rcpt commands. 21.1 shows rewriting, Maybe
>> you can catch what rule it is doing when it gets stuck.
>
>I have executed this command.
>The behaviour is a little bit different: The delay is reduced at 14 seconds
>instead of 3 minutes. I have retested that with both techniques and these
>daleays are reproducable.
>
>After the "rcpt to:" command, onyl the first two lines are printed out
>immediately (canonify and Canonify2), then it stays stuck for 14 seconds,
>and then it prints out all the rest.

That indicates a DNS lookup problem, though 14 seconds is a bit "weird"
- it's too long for a successful lookup (or proper "no such domain"
response), but failing servers will normally result in a longer delay.
During "canonification", sendmail will try to look for one or more of A,
AAAA, and MX records - make sure that you get immediate responses for
all (try e.g. with 'dig').

The longer delay when you connect to the daemon could be due to it
having more severe DNS problems (2-3 minutes is quite normal if multiple
servers don't respond), due to using an outdated /etc/resolv.conf. When
you run 'sendmail -bs', it will use the current contents of resolv.conf,
but the daemon will be using the contents as of when it was started (due
to caching by the resolver library). Try restarting the daemon if you
haven't already.

--Per Hedeland
per@hedeland.org

Re: RCPT To: timeouts problem

>>After the "rcpt to:" command, onyl the first two lines are printed out
>>immediately (canonify and Canonify2), then it stays stuck for 14 seconds,
>>and then it prints out all the rest.
>
> That indicates a DNS lookup problem, though 14 seconds is a bit "weird"
> - it's too long for a successful lookup (or proper "no such domain"
> response), but failing servers will normally result in a longer delay.
> During "canonification", sendmail will try to look for one or more of A,
> AAAA, and MX records - make sure that you get immediate responses for
> all (try e.g. with 'dig').
>
> The longer delay when you connect to the daemon could be due to it
> having more severe DNS problems (2-3 minutes is quite normal if multiple
> servers don't respond), due to using an outdated /etc/resolv.conf. When
> you run 'sendmail -bs', it will use the current contents of resolv.conf,
> but the daemon will be using the contents as of when it was started (due
> to caching by the resolver library). Try restarting the daemon if you
> haven't already.
>
> --Per Hedeland
> per@hedeland.org

Hello everyone and Per.

Thanks for your support!
You were right: my DNS configuration had a serious problem.
To be more precise, I had the DNS host ns1.mydomain.com IP address which had
the old IP address. This made a strange behaviour which was to have the
proper websites displayed, but yet not the proper DNS to be used.. or at
least there were hiccups there.
This was probably due to the fact that it tool the DNS data from the cache
on the second DNS server, but yet the first one had wrong informations...

I updated the IP address from the DNSmadeeasy.com hosting where it is, but
yet it was not enough, because this one must be changed especially on the
network solutions website, it cannot be changed below this level, I don't
know why....

Maybe displaying an error message indicating that the domain name was not
valid would be better rather than waiting 2-3 minutes to finally accept the
command.
Maybe this can be seen as a bug, even if I obviously did myself the mistake,
and it could be an idea to check further into this error message report,
what do you think?

Thanks again to every one for the great help provided!

Regards,
Daniel

Re: RCPT To: timeouts problem

In article <84dde$4713d108$55da0a86$5410@news.hispeed.ch> "doolyo"
writes:
>
>Maybe displaying an error message indicating that the domain name was not
>valid would be better

You think that sendmail should just guess something that might be
completely untrue in the absence of actual information? "Temporary"
failures are inherent in the design of DNS, you *must* treat them as
such - i.e. give an indication of "I couldn't find an answer, try later"
rather than pretending "the answer is 'no'".

> rather than waiting 2-3 minutes to finally accept the
>command.

The timeouts/retries are configurable in sendmail and, depending on your
resolver library, possibly in /etc/resolv.conf (the sendmail config is
more fine-grained, though). However it's a bit tricky to figure out the
values since the resolver library will try multiple servers (if
configured) multiple times. Often the problem is mainly one of listing
an excessive number of servers in resolv.conf.

>Maybe this can be seen as a bug, even if I obviously did myself the mistake,
>and it could be an idea to check further into this error message report,
>what do you think?

No.:-)

--Per Hedeland
per@hedeland.org

Re: RCPT To: timeouts problem

>>Maybe displaying an error message indicating that the domain name was not
>>valid would be better
>
> You think that sendmail should just guess something that might be
> completely untrue in the absence of actual information? "Temporary"
> failures are inherent in the design of DNS, you *must* treat them as
> such - i.e. give an indication of "I couldn't find an answer, try later"
> rather than pretending "the answer is 'no'".

Well, the thing which is strange is that there is no error message at all,
and the recipient is just normally accepted, after the timeout occurs.
If you want to do things the proper way, you should send an error message
after the timeout occurs, instead of accepting the recipient just because it
could not check what it was checking.
So maybe a good rule would be to either accept it, and accept it immediately
(and disabling the current check that is performed), or else to have a
timeout like it is now and then sending an error message back once it
occurs.
It is the mixture between both which bothers me, but maybe it is still the
best thing to do as we could imagine a situation where no DNS can be reached
and then it would be good not to stop sendmail working.
This is a problem to know what to do exactly in this situation. Now if the
current behaviour is the best one (even if not rigorous), then lowering the
timeout so that the mail clients don't timeout automatically would be the
thing to change. there is normally 60 seconds, so putting 50 seconds here
would be a good option.

This is just a suggestion.
Regards,
Daniel

Re: RCPT To: timeouts problem

In article "doolyo"
writes:
>
>Well, the thing which is strange is that there is no error message at all,
>and the recipient is just normally accepted, after the timeout occurs.
>If you want to do things the proper way, you should send an error message
>after the timeout occurs, instead of accepting the recipient just because it
>could not check what it was checking.

For lookups that aren't critical to the processing of the message,
whether to accept w/o error or warning is basically a policy decision
(e.g., not your case, but most people don't want to even tempfail
legitimate mail because a DNS spam-blocklist is unreachable). But you
can't determine if it's a "temporary" or "permanent" problem, or even
whether there is a problem at all, without trying the lookup - a common
"temporary problem" is precisely that the lookup times out.

>This is a problem to know what to do exactly in this situation. Now if the
>current behaviour is the best one (even if not rigorous), then lowering the
>timeout so that the mail clients don't timeout automatically would be the
>thing to change.

Exactly.

> there is normally 60 seconds, so putting 50 seconds here
>would be a good option.

Hm, don't know where those numbers are coming from, but *sendail*
doesn't have any specific timeouts for DNS lookup by default - those
that are there come from the resolver library of your OS, and using
those is surely the only reasonable default. But you can override them
in the sendmail config if you want to - or (possibly) fix everything on
your OS by putting them in resolv.conf.

--Per Hedeland
per@hedeland.org

Re: RCPT To: timeouts problem

> Hm, don't know where those numbers are coming from, but *sendail*
> doesn't have any specific timeouts for DNS lookup by default - those
> that are there come from the resolver library of your OS, and using
> those is surely the only reasonable default. But you can override them
> in the sendmail config if you want to - or (possibly) fix everything on
> your OS by putting them in resolv.conf.
>

Hello, per.
This timeout is just the empiric default of outlook express.

Thanks for the advice you gave.

Best regards,
Daniel

Re: RCPT To: timeouts problem

In article "doolyo"
writes:
>> Hm, don't know where those numbers are coming from, but *sendail*
>> doesn't have any specific timeouts for DNS lookup by default - those
>> that are there come from the resolver library of your OS, and using
>> those is surely the only reasonable default. But you can override them
>> in the sendmail config if you want to - or (possibly) fix everything on
>> your OS by putting them in resolv.conf.
>>
>
>Hello, per.
>This timeout is just the empiric default of outlook express.

Ah, I see. OK, for some other random default:-), I haven't tried with
RCPT To:, but 'date | sendmail user@example.com' which should be mostly
equivalent I think, hangs for 30 seconds before accepting the "message"
if I have a single, unreachable name server in resolv.conf. Sendmail
8.13.6 (uh, I should upgrade:-), FreeBSD 5.3 (that too), no resolver
timeout settings in either resolv.conf or sendmail.cf.

Actually the resolver timeout/retry stuff seems quite broken on this
system based on tcpdumping the queries, so it may not be all that useful
as a data point, but it seems like a somewhat reasonable total timeout.
Waiting more than a minute for DNS resolution is clearly not useful, if
you haven't got a reply within 30 seconds there's surely no point trying
any more.

--Per Hedeland
per@hedeland.org

Re: RCPT To: timeouts problem

> Ah, I see. OK, for some other random default:-), I haven't tried with
> RCPT To:, but 'date | sendmail user@example.com' which should be mostly
> equivalent I think, hangs for 30 seconds before accepting the "message"
> if I have a single, unreachable name server in resolv.conf. Sendmail
> 8.13.6 (uh, I should upgrade:-), FreeBSD 5.3 (that too), no resolver
> timeout settings in either resolv.conf or sendmail.cf.
>
> Actually the resolver timeout/retry stuff seems quite broken on this
> system based on tcpdumping the queries, so it may not be all that useful
> as a data point, but it seems like a somewhat reasonable total timeout.
> Waiting more than a minute for DNS resolution is clearly not useful, if
> you haven't got a reply within 30 seconds there's surely no point trying
> any more.
>
> --Per Hedeland
> per@hedeland.org

Yes, I believe that 30 seconds are enough, thus having some tweak inside
sendmail to continue it's process after that timeout instead of 2-3 minutes
would probably be a good thing, at least if possible. You seem to indicate
that this is related to the server's config, either will be good.

But to me now everything is working great, I have solved the DNS problem so
it is fine.
Thanks for having helped.
Best regards,
Daniel

Re: RCPT To: timeouts problem

In article <305b8$471cfa5f$55da0a86$15755@news.hispeed.ch> "doolyo"
writes:
>[I wrote:]
>> Ah, I see. OK, for some other random default:-), I haven't tried with
>> RCPT To:, but 'date | sendmail user@example.com' which should be mostly
>> equivalent I think, hangs for 30 seconds before accepting the "message"
>> if I have a single, unreachable name server in resolv.conf. Sendmail
>> 8.13.6 (uh, I should upgrade:-), FreeBSD 5.3 (that too), no resolver
>> timeout settings in either resolv.conf or sendmail.cf.
>>
>> Actually the resolver timeout/retry stuff seems quite broken on this
>> system based on tcpdumping the queries, so it may not be all that useful
>> as a data point, but it seems like a somewhat reasonable total timeout.
>> Waiting more than a minute for DNS resolution is clearly not useful, if
>> you haven't got a reply within 30 seconds there's surely no point trying
>> any more.

>Yes, I believe that 30 seconds are enough, thus having some tweak inside
>sendmail to continue it's process after that timeout instead of 2-3 minutes
>would probably be a good thing, at least if possible. You seem to indicate
>that this is related to the server's config, either will be good.

No, that's not what I meant, sendmail shouldn't have a builtin override
of your OS settings just because someone thought "you should never need
more than this". Fix your OS/resolver settings, or if you can't or
won't, override them in the sendmail *config* - that's The Sendmail Way
(fixing everyone else's problem, but you should ask for it:-).

--Per Hedeland
per@hedeland.org

Re: RCPT To: timeouts problem

> No, that's not what I meant, sendmail shouldn't have a builtin override
> of your OS settings just because someone thought "you should never need
> more than this". Fix your OS/resolver settings, or if you can't or
> won't, override them in the sendmail *config* - that's The Sendmail Way
> (fixing everyone else's problem, but you should ask for it:-).
>
> --Per Hedeland

Well, I would have expected it to be done at the sendmail level, but ok,
that is fine also to me, either way..

Regards,
Daniel