sendmail - timezone problem

[Tim Krego_1]

sendmail 8.8.6 on hpux 11.00

I send a message to 4194444444@messaging.nextel.com and user@hotmail.com. The message to hotmail shows correct time, the message on the nextel phone shows the time as 4 hours earlier.

The TIMEZONE env is correct.

The O'Reilly sendmail book says, "Because sendmail is often run as an SUID root program, it cannot (and should not) trust its environment variables."

OK, so I will use the sendmail.cf file to set the tz.

Our server is in EST5EDT timezone (GMT-5). I tried to set the TimeZoneSpec=EST5EDT in sendmail.cf with no sucess.

Messages sent from our MS Exchange Server to the nextel phones show the correct time.

This is a big issue for us that I need to fix. We have 150 nextel phones that send job requests from an Oracle database. The correct time is crucial for us.

I am assuming the nextel server uses the timezone and/or time from the sending server.

I have not found anyone with this issue when searching man pages, docs, ITRC, etc.

Thanks.

[Sridhar Bhaskarla]

Do you use a Smart Relay in your configuration?.

-Sri

[Tim Krego_1]

I don't think I am using a Smart Relay host.

How would that matter?

[someone_4]

what happends if you send it an AOL or Yahoo
address ?

Richard

[linuxfan]

Hi Tim,


From what you said/did, things seem to be ok and the fact that you set the TimeZoneSpec in the sendmail.cf avoids any user set environment variables. I was just wondering did you try talking to the nextel's tech support. Maybe the problem is on their end.

-Regards
I am RU

[someone_4]

Ok we dont have nexttel phones but we have att phones. I sent an email from my mailserver
to mycellnumber@att.mobile.net
and to aol.com and to my regular email. They all came in at the same time. we are CST.
Here are my time options I dont know if they have anything to do with it all I did was grep for Time* in sendmail.cf. I am using Version 8.8.6 (PHNE_17190)

# Timeouts (option Timeout.*): #

# O Timeout.queuewarn=4h #

# O Timeout.queuereturn=5d #

O ConnectionCacheTimeout=5m
# Timeout Meaning
#O Timeout.initial=5m
#O Timeout.connect=5m
#O Timeout.iconnect=5m
#O Timeout.helo=5m
#O Timeout.mail=10m
#O Timeout.rcpt=1h
#O Timeout.datainit=5m
#O Timeout.datablock=1h
#O Timeout.datafinal=1h
#O Timeout.rset=5m
#O Timeout.quit=2m
#O Timeout.misc=2m
#O Timeout.command=1h
#O Timeout.ident=30s
#O Timeout.fileopen=60s
O Timeout.queuereturn=5d
#O Timeout.queuereturn.normal=5d
#O Timeout.queuereturn.urgent=2d
#O Timeout.queuereturn.non-urgent=7d
O Timeout.queuewarn=4h
#O Timeout.queuewarn.normal=4h
#O Timeout.queuewarn.urgent=1h
#O Timeout.queuewarn.non-urgent=12h
#O Timeout.hoststatus=30m
O TimeZoneSpec=

[A. Clay Stephenson]

Hi Tim:

Let's see if we can't narrow the problem down a bit and look at the formatted mail itself.

Do this:

echo "Big Bad Wolf" | sendmail
-ODeliveryMode=q tim@xxx.com

This will queue the file but not send it:

cd to /var/spool/mqueue. You should see 2 files
- 1 small; 1 a bit bigger - which are your mail files. Copy the larger file to /tmp and them remove both of these so that they don't get sent.

Examine the file in /tmp and look at two Header Lines:
HReceived should indicate the timezone and H?D?Date: should indicate the time zone.

Both of these should indicate the local time plus an offset HHMM from UTC. The offset may be negative. If these values are correct we need to look downstream to another mail server
but if they are wrong, you've located the problem. In any event, this will definitely pin down the problem for you.

Happy Hunting, Clay

[Tim Krego_1]

Thanks to everyone for all the help. The problem still exists.

Clay,

I followed your directions. The headers show the local time with an offset of -0400. That is correct as I am in EST.

If it is a Nextel problem I cannot verify that yet. Though the same message to any of my other email addresses shows the correct time. That would make me think that Nextel is causing the problem.

The odd part is that messages sent from our Exchange server to the Nextel phones show the correct time.

I have two K460 boxes running hpux 11.00 and they both do the same thing.

I am going to change the TimeZoneSpec in the sendmail.cf to a value that will show the correct time on the phones if I cannot figure out the problem. It won't be a big issue since we only use sendmail to send messages to the phones. We don't send any other mail from this machine and no incoming mail is needed.

Thanks again,
Tim.

[A. Clay Stephenson]

Hi Tim:

I had already thought of simply adding the time
(preferably UTC to avoid confusion) to the message text but that is not a very elegant solution. If your email is now sent from your server directly to Nextel you need to send the file you saved to their technical staff. If you send email to still another server within your company you need to repeat the process there.

Just to be safe, I would send the "Big Bad Wolf" message exactly as you did before but without the "-ODEliveryMode" option and address it to your Nextel pager. Note the time display. This method bypasses any other mail frontend programs and isolates the problem to sendmail.

Regards, Clay

[Tim Krego_1]

This is one of the headers.

---
Received: from [208.204.165.69] by hotmail.com (3.2) with ESMTP id MHotMailBD454F4C007C40043198D0CCA545F9D10; Thu, 16 Aug 2001 10:35:14 -0700
Received: (from root@localhost)by guppy.healthnetstaffing.com (8.9.3 (PHNE_18546)/8.8.6) id NAA21693;Thu, 16 Aug 2001 13:30:15 -0400 (EDT)
From timsu@guppy.healthnetstaffing.com Thu, 16 Aug 2001 10:41:26 -0700
Message-Id: <200108161730.NAA21693@guppy.healthnetstaffing.com>
X-Mailer: ELM [$Revision: 1.17.214.2 $]
---

I just noticed that there was a -0700 in that header.

[A. Clay Stephenson]

Hi Tim:

If I am reading your posdtins correctly, it appears that sendmail correctly processed the message but elm failed. You appear to have a front-end problem.

Clay

[Tim Krego_1]

Clay,

Elm sends the message without a problem. It just seems that somewhere there is a problem with the timezone. The messages through the Nextel phone show as 4 hours behind.

I am going to try qmail to see if the problem still exists. That should rule out sendmail as the culprit.

If that doesn't work I am at a dead end. We have never been able to contact the right people at Nextel to get answers. We have a Nextel rep that has offered zero help with development problems that we have had. When Nextel switched their phones to a WAP 4.0 browser we couldn't log into our app anymore until they upgraded their UP.Link server software. Argh!

Thanks