[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[cobalt-users] Sending email to AOL - timezone problem
- Subject: [cobalt-users] Sending email to AOL - timezone problem
- From: "Ryan Gray" <ryan@xxxxxxxxxxxxxxx>
- Date: Fri Jan 5 15:58:01 2001
- List-id: Mailing list for users to share thoughts on Cobalt products. <cobalt-users.list.cobalt.com>
Hello,
I've read threads in the archive that relate to this issue, but
not any that have fixed it. Also, I'm dealing with Gateway Microservers
here, which to my understanding *are* Cobalt Cubes with the exception of
the Gateway logo and the color. I am posting this hear because I've seen
the threads discussing this in the cobalt-users archive, but have seen no
fixes. This may be an OS issue, but I've got 7+ Cubes in this city alone
that are having this issue, and I've never seen this issue with standard
Linux installs.
This is a bit long, but here it goes . . . .
I've run into about 7 or 8 clients that have Gateway Microservers (Cobalt
Cubes) and are unable to send mail to aol.com addresses. I've spoken to
the email admins at AOL and they inform me that their mail servers are not
sending the mail because of a discrepancy in the header of the messages
that are being sent from these Microservers. Unfortunately, it took me a
month to get to what the problem is because AOL doesn't bounce this type
of problem, they just send it off to /dev/null or some other black hole.
The problem is in the
timestamp that's being placed on the mail. Here's a header from the
Microserver:
Return-Path: <mblackburn@xxxxxxxxxxxxxxx>
Received: from mail.allpowerinc.com (mail.allpowerinc.com
[207.177.63.199]) by
rly-na03.mx.aol.com (v77.27) with ESMTP; Tue, 02 Jan 2001 11:26:02 -0500
Received: from Mark ([192.9.200.153])
by mail.allpowerinc.com (8.9.2/8.9.2) with SMTP id LAA26331
for <BILLRPFD@xxxxxxxxxxxx>; Tue, 2 Jan 2001 11:25:04 -0600 (EST)
Message-ID: <00ea01c074d8$e1aad0c0$99c809c0@xxxxxxxxxxxxxxx>
From: "Mark Blackburn" <mblackburn@xxxxxxxxxxxxxxx>
The problem is the "-0600 (EST)". That doesn't exists. Eastern Standard
Time is -0500. The time and date on the Microservers in question is
correct from the command line. In other words, issuing the 'date' command
yields the correct time, date, year and time zone (in this case CST). I've
even updated the time on the Microserver using NTP just to make sure.
If you send mail from the console (from the command line), the timestamp
is correct, and aol.com servers will process it. However, if you send
mail from a client machine on the network, using the Microserver as the
SMTP server, the timestamp is incorrect, and aol.com's servers will not
process the mail.
I thought I could force Sendmail to a specific timezone using the "O
TimeZoneSpec=" parameter. Please note that by default on the
Microservers, this is undefined, and with it undefined Sendmail is
supposed to use the system default which is reporting correctly via the
'date' command. I defined it and set it to CST6CDT. This did not help.
I could still send mail to aol.com from the command line, but not from a
client using the Microserver as its SMTP server.
I then started looking at the /usr/share/zoneinfo hierarchy. This is
where I found what I think to be the core of the problem. A 'zdump
/usr/share/zoneinfo/CST6CDT' yields the correct day, month, time, year,
but not the correct time zone. For example:
~# zdump /usr/share/zoneinfo/CST6CDT
/usr/share/zoneinfo/CST6CDT Fri Jan 5 10:40:16 2001 EST
The Central Standard Time zone file is reporting EST! I'm not sure how to
proceed.
If I can provide any more information, please let me know. As far as
reproducing this issue, that's no problem because there are a half dozen
Microservers in this city alone that are doing the exact same thing.
Regards,
Ryan Gray
Catalyst Solutions, Inc.