Return to BSD News archive
Xref: sserve comp.mail.sendmail:7411 comp.os.386bsd.bugs:598 Newsgroups: comp.mail.sendmail,comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!pacbell.com!iggy.GW.Vitalink.COM!wetware!spunky.RedBrick.COM!psinntp!psinntp!monymsys!sonyd1.broadcast.sony.com!blilly.uucp!bruce From: bruce@blilly.uucp (Bruce Lilly) Subject: Re: arpatounix() fix for sendmail 5.67a/IDA-1.5 References: <1r04pe$7bg@werple.apana.org.au> Organization: Bruce Lilly Date: Tue, 27 Apr 93 23:18:06 GMT Message-ID: <1993Apr27.231806.15158@blilly.uucp> Reply-To: lilb@sony.compuserve.com (Bruce Lilly) Lines: 34 In article <1r04pe$7bg@werple.apana.org.au>, posted to comp.mail.sendmail,comp.os.386bsd.bugs, andrew@werple.apana.org.au (Andrew Herbert) wrote: >Recently my sendmail was having a really hard time with a message arriving >with a date field "Date: Wed, 14 Apr 1993 16:36:25 +119304028 (CDT)". The >huge timezone offset was resulting in a corrupted state structure in the >ctime(3) library routines (presumably from the call to asctime() made at the >end of arpatounix()). The offset must be of the form HHMM (i.e. there must be precisely 4 digits). See RFC822 section 5.1 (and RFC1123 section 5.2.14 (which incorrectly references RFC822 section 3 instead of the aforementioned section 5.1)). There is no restriction on the values of the HHMM digits. I recommend that you send mail to the site originating the bogus header informing them of the problem so that they can correct their software (which is clearly not in compliance with the RFCs). The correct numeric offset for CDT (assuming the comment is appropriate) is "-0500". I don't belive that your patch would generate the equivalent time. Any non-comment, non-whitespace left over after 4 digits of a numeric zone should probably trigger an ``unparseable date'' warning, since there is no reasonable interpretation of more than 4 digits. -- Bruce Lilly ...uupsi!monymsys!sonyd1!blilly!bruce