Just curious, is the dns resolving to the mail records correctly?  A delay could be caused by incorrect settings.

in your reslvcnf.net.sys, what's the name server set to and once you have that, check nslookup from a pc to see if the server resolves the records correctly

nslookup
server <<server set in reslvcnf.net.sys>>
set type=mx
and verify it points to the correct server and it has the right IP.

possible that the setting in reslvcnf are pointing to an outdated dns.

just at thought, bob

On Tuesday, October 12, 2004 12:43 PM, Johnson, Tracy <[log in to unmask]> wrote:
>Number 3 looks like a winner!
>(Success is measured easily here.)
>
>BT
>
>
>Tracy Johnson
>MSI Schaevitz Sensors 
>
>> -----Original Message-----
>> From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On
>> Behalf Of Emerson, Tom
>> Sent: Tuesday, October 12, 2004 2:14 PM
>> To: [log in to unmask]
>> Subject: Re: [HP3000-L] Sendmail Delay?
>> 
>> 
>> Two possibilities [maybe even more...]
>> 
>>    1) Mark only noted this was the "recommended" file 
>> permissions -- if you know and understand the risks 
>> associated with a less-than-secure setup, then by all means 
>> change it so "normal" users could "check" the queue [this may 
>> require a bit more in-depth knowledge of sendmail than you or 
>> your users are willing to deal with, however...]
>> 
>>    2) make an SM monitoring JOB -- the part that is CHECKING 
>> to see "is the queue emptying fast enough?" is the part that 
>> needs SM.  Of course, if it isn't emptying, then you have to 
>> figure out an ALTERNATE way of notifying you (perhaps by 
>> pager?) since sending an e-mail saying "hey, the queue is 
>> backed up" won't really be all that effective, now will it? ;) 
>> 
>>    3) just do a listf against /var/spool/mqueue (or 
>> wherever...) and count the number of files in that directory 
>> -- if non-zero, things are not clearing out...  (in other 
>> words, you don't need to know what is "in" the directory, 
>> just the fact that there ARE files there and they ARE NOT 
>> going away)  A pure count of files may be too simplistic if 
>> the number of e-mails sent at any given time is excessive (in 
>> other words, every time you check there are one or more 
>> files, just not the SAME files)  So a "fancier" way might be 
>> to do a listf of just the filenames into a temp file on the 
>> first pass, then on the second pass another listf followed by 
>> a compare between the two files -- if files persist from one 
>> pass to the next, then you know they are not clearing...
>> 
>> * To join/leave the list, search archives, change list settings, *
>> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>> 
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit
>http://raven.utc.edu/archives/hp3000-l.html *
>

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *