Conference lassie::ucx

>>    If I'm not mistaken, it's the SMTP mail client that adds/interprets the
>>    time and zone
>    
>    True. And that's the point. SMTP is not in the loop when the sender is
>    using VMSmail over DECnet. The POP server detects this and "converts"
>    the VMSmail message to an SMTP message as best it can (because the POP
>    RFC requires that messages be RFC822 compliant).
 
    I think the question that the UCX folks will have to answer is "For the
    paths VMSmail->(local)->UCX/POP and VMSmail->DECnet->VMS/POP, is it
    possible that UCX is adding an _incorrect_ timezone to the date header
    or other envelope information?" As you note, those are the paths
    that do not pass through an SMTP gateway per se. For reasons noted
    below, a totally missing date header may not actually be a problem.
    Short of that, I can only suggest that you double check the problem PC
    for correct timezone and daylight savings settings and for any unusual
    clock skew compared to the other hosts.
    
>>    UNIX mailx. In all cases, there is no time zone anywhere on the message
>>    as received by the Windows Messaging client
>    
>    I would expect that internally there is no timezone on the one sent via
>    VMSmail/DECnet and there is a timezone on the other two. However
>		...
>    Are you able to confirm that for a message sent locally at, say, noon by all
>    three means, the Windows Messaging client displays the correct send
>    time for the two sent via SMTP and an incorrect (out by 5 hours in your
>    case) send time for the one sent via VMSmail/DECnet?
    
    Unfortunately, using a UNIX POP server, I haven't found a path that
    _doesn't_ add a correct date header with timezone into the actual
    message. It's just that Windows Messaging doesn't show the timezone
    even when it does exist. As I noted, our POP server is on UNIX, and
    DECnet->UNIX passes through mail11d, which adds the complete date
    header.
    
    However, I did manually remove the date header from the message in the
    POP queue. The results are not quite what you might expect and they
    _are_ confusing, so you might just want to stop here. The resulting
    message in Windows Messaging shows the time of receipt by the POP
    server's relay in the inbox and shows no date/time information on the
    message itself. Same with Netscape mail. The time is _not_ the sending
    time on the VMS host nor the receiving time on the NT client as nearly
    as I can tell. This (time shown in the inbox=POP server's receipt time)
    seems to also be true for "normal" SMTP messages originated on VMS,
    even when the date header is present and shows a different, later,
    origination time. I can only guess that Windows Messaging gets its time
    from the sendmail postmark or some other envelope information. If I also
    remove the postmark, the Windows Messaging client then instead appears
    to show the local time of receipt in the inbox and, again, no date/time
    in the message itself. In all cases the times are "correct", but these
    are all staying within the same timezone. I should probably also note
    that the clock skew between the POP server and the NT client is very
    small but the NT clock is ahead of the POP server's clock. The VMS
    clock on which the messages originate is several minutes ahead of both.
    
>>    If I instead collect the mail on the same NT client with Netscape mail,
>>    or Eudora they show the complete date with timezone that was in the
>>    original date header.
>    
>    But in the case of the mail sent via VMSmail/DECnet there is no
>    timezone displayed by Netscape Mail? Is that what you observe?
>    (I don't have Eudora.)
 
    No, they're all complete because they all eventually pass through
    sendmail (and, for DECnet, mail11d).   
    
>>    If you have been sending VMSmail to the POP server via DECnet, you
>>    might try instead sending to the POP server via SMTP to see if the
>>    results are different.
>    
>    The results are different. But that is not a viable workaround. One can't
>    expect the sender to adjust the email address used on the basis of the
    
    Sorry. I didn't mean to suggest that that was a workaround. Just a way
    of narrowing down the problem. If the results are different, then there
    does appear to be a path (probably local or DECnet delivery to the POP
    server) that has a hole somewhere.

    -Tom

Its not possible to create a working mail system by implementing in accordance
to the RFCs because no mail system that works conforms to the RFCs because
doing so would produce bogus results because no mail system conforms to the RFCs.

The complexity in sendmail is due to the view that its not legitimate to
expect that broken mail implementations be fixed, so it is necessary to
include options to make a correct implementation correctly violate the specs.

    I just happened to spot this and it seemed relevant to your problem:
    
Path: nntpd.lkg.dec.com!leggy.zk3.dec.com!orb!news.ultranet.com!zombie.ncsc.mil!newsgate.duke.edu!news.mathworks.com!worldnet.att.net!news.dra.com!news.starnet.net!news.starnet.net!news.hn.netlink.co.nz!clear.net.nz!d1-u55.acld.clear.net.nz!user
From: [email protected] (Olof Olsson)
Newsgroups: comp.mail.sendmail
Subject: Re: Timezone +1300, is this acceptable?
Date: 22 Jan 1997 10:26:19 GMT
Organization: CLEAR Net
Message-ID: <[email protected]>
References: <[email protected]>
NNTP-Posting-Host: d1-u55.acld.clear.net.nz
Xref: nntpd.lkg.dec.com comp.mail.sendmail:40633

In article <[email protected]>, "Horne, Mike"
<[email protected]> wrote:

> I cannot find anywhere if a timezone of +1300 should be acceptable to
> SMTP mail systems (New Zealand daylight saving time is GMT +1300).
> While most mail systems appear able to cope with a timezone of +1300
> others - such as M$ Exchange do not appear to cope.
> 
> Any help appreciated.
> 
> Mike Horne.

This is a known bug with MS Exchange Client. It does not recognise
timezone "comments", like "(NZDT)", in the mail headers. I believe there
is a patch available on the MS web site.

   --Olof

-- 
Olof Olsson, Internet Product Specialist, mailto: [email protected]
CLEAR Net, CLEAR Communications Ltd, Auckland, New Zealand.

re .9
    
>                            -< Its a MS problem... >-
    
    Certainly a change to Windows Messaging that allowed the user to
    configure how invalid Date: headers (i.e. missing time zone) should be
    interpretted (i.e. what time zone to assume) would remove the problem
    for the user in this case.
    
>it's not legitimate to expect that broken mail implementations be fixed
    
    For J. Random Software Company perhaps. I wasn't aware that such an
    expectation (or lack thereof) was appropriate for Digital supplied
    software although there does seem to be a lack of comment from anyone
    on the UCX team i.e. someone who actually has access to the sources...

I Took a look at this and the POP server doesn't add a timezone to the dummied
up Date header that it creates for non-SMTP mail.

I have to confess that I know nothing about the timezone stuff since it hasn't
been a problem up to this point. In an effort to determine whether the time zone
clause of the Date: RFC header field was required I looked at RFC's 821 and 822.
According to the syntax specification in RFC 822 for the Date: header the
timezone information is not optional. Therefore Derek's assertion that the Date:
header created by the POP server is not compliant in this regard is correct. It
is not compliant.

>it's not legitimate to expect that broken mail implementations be fixed

Although I wouldn't agree with this statement as phrased I think the idea behind
it is a fairly well accepted philosophy of good software design.  Be liberal in
what you accept and conservative in what you send.  Regardless of this
philosophy though I still consider this more of a UCX POP server bug than an MS
bug so I have put the bug into the UCX POP server worklist.

I am assuming it would be satisfactory to create a timezone string in the same
manner that the UCX SMTP client does. Following is a snippet from RFC 822 that
defines the time zone string. (the '/' character means a logical OR.):

      zone        =  "UT"  / "GMT"                ; Universal Time
                                                 ; North American : UT
                 /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
                 /  "CST" / "CDT"                ;  Central:  - 6/ - 5
                 /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
                 /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
                 /  1ALPHA                       ; Military: Z = UT;
                                                 ;  A:-1; (J not used)
                                                 ;  M:-12; N:+1; Y:+12
                 / ( ("+" / "-") 4DIGIT )        ; Local differential
                   ^^^^^^^^^^^^^^^^^^^^^^^       ;  hours+min. (HHMM)
                              |
   This is the one UCX -->----+
   SMTP uses 

The UCX SMTP client generates a Date: field like this:

  Date: Wed, 5 Mar 1997 14:48:49 -0500
                                 ^^^^^
Unless I hear any objections	   |
we will use the same syntax	   |
in the POP server  ----------------+

Karol

RE: Note 5082.12 by UCXAXP::ZIELONKO -< Put into POP server bug list >-

>The UCX SMTP client generates a Date: field like this:
>
>  Date: Wed, 5 Mar 1997 14:48:49 -0500
>                                 ^^^^^
> Unless I hear any objections       |
> we will use the same syntax        |
> in the POP server  ----------------+

	Hello Karol,

I have no objection at all, this reply is just to be sure you are 
aware too of the "time" formats we may see in Asia, Europe ... :

a) The STARS article 
     [DECnet/OSI] Understanding & Customizing DTSS Time Zone Rules             
   provides a complete list of the various "TIME ZONE RULES" formats 
   and values that may be received;

b) You could also take a look to the LASSIE::CONNECTION Note 4710.9 
     "creation file's time wrong"  9 of 10  2-MAR-1994 
    -< Experiment UCX SET CONF TIME & timezone parsing >-
  in which I described various syntaxes for "$ UCX Set Conf Time "
  that appeared to work, in example
        UCX> SET CONF TIME "MET-1MET_DST-2,M3.5.0/2,M9.5.0/2"
  (if POP was to be modified, it would be nice if this was OK with 
  this today's UCX SMTP time format).

Sorry, I guess that you already had these information.
Best regards,
Pierre-Etienne