Archive-Date: Wed, 11 Jan 1995 21:48:57 GMT Subject: TCPware can silently lose incoming SMTP mail. Message-ID: From: mikewd@leica.co.uk (Mike Wilmot-Dear) Date: Wed, 11 Jan 1995 21:48:57 GMT I have discovered what I regard as a rather serious problem in TCPWare's SMTP server that can cause the loss of incoming mail when it can't be delivered to a local user. I'm posting this, both because other users may wish to be aware of this problem and also because I regard this behaviour as broken and contrary to the RFCs and would welcome other comments and support in getting Process S/W to do something about it. The specific case I have found is that if the disk containing the users mail file is unavailable (e.g. it's dismounted) the TCPWare will accept an incoming SMTP message for the user without generating an SMTP error. It then tries to deliver it to the local user (which fails within VMS mail). The incoming message is then simply lost. It is *not* requeued for later deliver, *nor* is any error message generated either to the originator or the local postmaster. In fact there is no indication anywhere that the message has been lost! This is in TCPWare V4.05 but I'm advised by our distributor that this behaviour is unchanged in V4.1. They also say that Process S/W don't regard it as a bug or contradicting the RFCs. However my interpretation of RFC821 is that if the SMTP reception is succesful but then subsequent delivery fails the an "undeliverable mail" message should be generated (q.v. RFC821 sections 3.6 and 4.1.1). So I would welcome any comments on this. I would like to add that I'm in general very satisfied with TCPware and have advocated its use both here and on systems we supply to customers. Which is why I am so disappointed to find this problem. I'm also concerned that it will also cause a loss of confidence in the reliability of e-mail amongst my users. Mike. -- ------------------------------------------------------------------------------ Mike Wilmot-Dear (MW342) e-mail: mikewd@leica.co.uk Leica Cambridge Ltd. Tel: +44-1223-411411 (x347) Clifton Road Fax: +44-1223-210692 Cambridge, CB1 3QH, UK ================================================================================ Archive-Date: XXX, 15 Jan 1995 12:17:41 -0400 From: volz@process.com (Bernie Volz) Subject: Re: TCPware can silently lose incoming SMTP mail. Message-ID: <1995Jan15.121741.907@process.com> Date: 15 Jan 95 12:17:41 -0400 References: > I have discovered what I regard as a rather serious problem in > TCPWare's SMTP server that can cause the loss of incoming mail when it > can't be delivered to a local user. > > The specific case I have found is that if the disk containing the users > mail file is unavailable (e.g. it's dismounted) the TCPWare will accept > an incoming SMTP message for the user without generating an SMTP > error. It then tries to deliver it to the local user (which fails > within VMS mail). The incoming message is then simply lost. > > It is *not* requeued for later deliver, *nor* is any error message > generated either to the originator or the local postmaster. In fact > there is no indication anywhere that the message has been lost! > > This is in TCPWare V4.05 but I'm advised by our distributor that this > behaviour is unchanged in V4.1. They also say that Process S/W don't > regard it as a bug or contradicting the RFCs. > I (from Process Software) would regard this as a bug. I don't recall this issue ever being reported - but will check with the SMTP maintainer. A quick test appears to confirm that the message is indeed lost if the user's "mail" device isn't available. We should be returning the message to the sender in this case (we don't queue it up); either approach can be argued to be good or bad. If we can't return the mail (such as invalid from information), it would go to the POSTMASTER. - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: XXX, 20 Jan 1995 04:33:45 GMT Subject: REQUEST : looking for a document Message-ID: <3fnef9$sld@news.kreonet.re.kr> From: nasol2@mgt.kaist.ac.kr (nasol) Date: 20 Jan 1995 04:33:45 GMT I am looking for a document (file) about KA9Q program. Since, in my ability, without it, to interpretate and analyse the whole program is a very difficult task and even felt impossible. If someone knows how to get this document, please tell me the way. We will appreciate your help. Good luck. If possible, please send me a `e-mail' to the address below, not reply message. ===================================================================== from : Do-hoon, Kim Department of Management Science Korea Advanced Institute of Science and Technology e-mail : kimdh@telmal.kaist.ac.kr ===================================================================== ================================================================================ Archive-Date: XXX, 17 Jan 1995 19:18:40 +0200 Subject: DNS worries Message-ID: <1995Jan17.191840.44@elmrd6.ineab.ikea.se> From: anos@elmrd6.ineab.ikea.se (Anders Ostling) Date: 17 Jan 95 19:18:40 +0200 Hi I have been trying (with some success) to set up a bunch of nameservers using TCPware 4.0/4.1. There is some problems, specifically with zone transfers and reverse mapping, that I can't figure out (yes, I've rtfm'd). Our organisation (and IP network) looks like this; 1. Head office in Helsingborg, Sweden 2. Country offices in 6 european countries 3. End-node systems (stores, offices and warehouses) in (1) and (2). 4. Connections to other IKEA organisations via (1) I've planned to use a DEC-7610 as "root" name server for all systems in our domain (ineab.ikea.se) and a secondary server in each country. These secondary servers would serve from a dozen up to a couple of hundred IP hosts. I plan to use a Mvax 3100-95 in each country as name server since we already has one on each "country head office". Is this a suitable machine ? I expect a moderat load of DNS queries. This also means that most end-node systems will talk DNS over 19200 and 64 kpbs WAN links. Any problems with this? Is caching DNS answers the solution ? Q1. If I appoint the DEC 7610 as primary server, can I later add another level, i.e use a "ikea common" root name server. Q2. Do I have to create the NAMED.REV and NAMED.CA files by hand, or are they also distributed by zone transfers ? Does this apply for both primary and secondary servers ? Q3. How much knowledge of the lowest level of the network is suitable to insert at root level. To be more specific, should I register Belgian print boxes and terminal servers in the central root server ? If I don't do that, how do I merge local and central DNS information ? Boy, a lot of questions. Guess some of this is to be found in the manual set. If so, please direct me to it. Some other questions is more of general interest (at least for me), and I would appriceate some advise here. /Anders -- +-------------------------------------------------------------------------+ | Internet anos@ineab.ikea.se | | _ _ Voice +46-42-25 73 08, Fax 25 73 70, Attn: Anders Ostling | | \ \ \ IKEA Northern Europe AB, Sweden | | _/ _/ _/ | +-------------------------------------------------------------------------+ ================================================================================ Archive-Date: Thu, 26 Jan 1995 04:49:54 GMT Subject: ANNOUNCE: SOCKETSHR 0.9D - a TCP/IP package independent socket library Message-ID: <3g72j9$41v@ra.ibr.cs.tu-bs.de> From: meyer@ifn.ing.tu-bs.de Date: Thu, 26 Jan 95 04:49:54 GMT ANNOUNCEMENT: SOCKETSHR V0.9D 25-Jan-1995 This is to announce the fourth beta release of SOCKETSHR, a TCP/IP product independent BSD socket library (shared image) based on Matt Madison's NETLIB. It is available for OpenVMS VAX and AXP. NOTE: The SOCKETSHR image for NETLIB has been renamed to SOCKETSHR_NETLIB1.EXE to reflect that it is built for NETLIB V1. Future versions of SOCKETSHR may be built for the new NETLIB V2. PLEASE UPDATE YOUR DEFINITION OF THE LOGICAL "SOCKETSHR"! There is also a UCX native version, which is merely an interface to UCX' socket library with some routines added. Both versions are interchangable since they share the same transfer vector. Currently the NETLIB version is the recommended implementation of SOCKETSHR. SOCKETSHR has been created to make distribution of binaries easier, since only one executable has to be built. This executable then runs on all TCP/IP products without relinking. Note that NETLIB V1.7 or higher is required for UDP applications to work. V1.7 implements asynchroneous UDP transfer which is necessary to implement select() (Many thanks to Matt Madison for his cooperation). NETLIB V1.7 is the current (and last) version of NETLIB V1. Matt has created NETLIB V2 which has V1 compatible routines. SOCKETSHR should also works with NETLIB V2 though it does not currently use the new features of NETLIB V2. SOCKETSHR may be obtained via anonymous ftp from: ftp.ifn.ing.tu-bs.de in directory [.VMS.SOCKETSHR] SOCKETSHR_BIN_09D.ZIP VAX and AXP shared images SOCKETSHR_SRC_09D.ZIP sources NETLIB017.ZIP Matt Madison's NETLIB (UNZIP.EXE can be found in [.VMS]) Older versions can be found in [.VMS.SOCKETSHR.OLD]. There is a mailing list for discussion: socketshr@ifn.ing.tu-bs.de To subscribe, send mail to socketshr-request@ifn.ing.tu-bs.de containing one line: subscribe Feel free to test socketshr and please report bugs. --Eckart ------------------------------------------------------------------------------- Changes for V0.9D: (1) Added missing files with BUILD.COM. This procedure was rewritten. (2) Added time stamp on trace output. (3) Don't use VAXC$INET_NTOA and VAXC$INET_ADDR but supply our own routines (INET.C). Although independent of any networking software they seem to need UCX$IPC_SHR which is only available with UCX (thanks to Charles Streible). (4) Wrong internal declarations of fgetc(), fputc() etc. Changed to use integers instead of char's (thanks to Charles Streible). (5) The NETLIB version was renamed to NETLIB1 to reflect that it is built on NETLIB V1. Matt has developed a complete new version of NETLIB (V2) with a new interface. A future version of SOCKETSHR will use the new interface. (6) New socketshr.h: Not only defines routine names but also define the prototypes - but only if the original prototype definition has already been done. It is now recommended to include socketshr.h after all other related includes (like socket.h etc). (7) fileno() can now be used as it is defined in stdio.h, i.e. as a macro referring to the FILE struct (_iobuf). It is no longer defined in socketshr.h. The entry point for fileno() will be retained for compatibility. (8) The two example and test programs client.c and server.c are now ANSI-C compatible and may be compiled on DECC without /standard=vaxc. (9) Corrected bugs with accept() when used with select(). The correct event flag was not set when a connect was coming in while waiting in select(). Also, the "ready bit" was not cleared in accept() resulting in an immedeate return from subsequent select on this (listen) socket. (10) You may now link SOCKETSHR from the binary distribution (SOCKETSHR_BIN_09D.ZIP) by simply extracting all files into a temporary directory and typing "@LINK". (11) TYPES.H, IOCTL.H and FILE.H have been added to the binary distribution. In the source distribution they have been moved from [.netlib] to the base directory. ------------------------------------------------------------------------------- Changes for V0.9C: (1) Corrected bug with select() when the timeout parameter is NULL. Under certain circumstances select() could go into a loop instead of waiting (thanks to Andy Harper). (2) Added some routines: Services: getservent - get next service from database setservent - set open/close flag endservent - close database Note: All service database routine including getservbyname() and getservbyport() now use the file pointed to by logical SOCKETSHR_SERVICES or SYS$LIBRARY:SERVICES. if the logical does not exist. The old logicals INET$... are no longer used! Protocols: getprotobyname - get protocol from database getprotobynumber- get protocol from database getprotoent - get next protocol from database setprotoent - set open/close flag endprotoent - close database Note: All protocol database routines use the file pointed to by logical SOCKETSHR_PROTOCOLS or SYS$LIBRARY:PROTOCOLS. if the logical does not exist. Hosts: gethostent setservent endservent These routines are added for completeness but they actually do nothing. gethostent() always returns the NULL pointer, since NETLIB does not provide this information. SOCKETSHR.H has been updated to include the new routines. Due to the addition of these routines, the transfer vector has changed. The routines have been appended at the end. The minor id of the shared images has been increased. Programs linked against previous versions of SOCKETSHR will run with this versions. ------------------------------------------------------------------------------- Changes for V0.9B: (1) Corrected bug with tracing in select() when the timeout parameter is NULL (thanks to Andy Harper). (2) Corrected bug in recvfrom() where the user's from-buffer is not filled completely. The SIN_FAMILY item was set to 0 instead to AF_INET (2) (thanks to Andy Harper). Also, the actual length of the address information was not returned in the last parameter. (3) Corrected bug in gethostbyname/gethostbyaddr with returned alias lists. The alias name list returned NULL instead of a pointer to NULL (thanks to David Denholm). Note that SOCKETSHR_NETLIB never returns alias names since NETLIB does not provide them. (4) Corrected bug in gethostbyname/gethostbyaddr with returned address list. The returned address list was made up as a list of addresses instead of a list of pointers to addresses (thanks to Daved Denholm). Obviously UCX always returns only one address. CMU/IP correctly returns all adresses. I don't know if this is UCX' fault or a NETLIB bug. This problem will be addressed in a future version of SOCKETSHR. ----------------------------------------------------------------------------- Eckart Meyer Address: Schleinitzstr. 23 Institute for Telecommunication 38092 Braunschweig Technical University of Braunschweig Germany Phone: +49 531 391 2454 E-Mail: meyer@ifn.ing.tu-bs.de FAX: +49 531 391 5192 VMSmail: PSI%26245050551130::MEYER (DATEX-P) ----------------------------------------------------------------------------- ================================================================================ Archive-Date: Fri, 27 Jan 1995 18:29:32 GMT Subject: Re: DNS worries Message-ID: From: mikewd@leica.co.uk (Mike Wilmot-Dear) Date: Fri, 27 Jan 1995 18:29:32 GMT References: <1995Jan17.191840.44@elmrd6.ineab.ikea.se> I wouldn't claim to be a DNS expert put I can perhaps answer some of your questions. Anders Ostling (anos@elmrd6.ineab.ikea.se) wrote: : Hi : I have been trying (with some success) to set up a bunch of nameservers : using TCPware 4.0/4.1. There is some problems, specifically with zone : transfers and reverse mapping, that I can't figure out (yes, I've rtfm'd). You might like to look at the book "DNS and BIND" by Albitz & Liu published by O'Reilley. Which I gather is regarded as the DNS "manual". Although the bits on BIND (this UNIX DNS implementation) won't be directly relevant I would think the general DNS stuff would be useful. : Our organisation (and IP network) looks like this; : 1. Head office in Helsingborg, Sweden : 2. Country offices in 6 european countries : 3. End-node systems (stores, offices and warehouses) in (1) and (2). : 4. Connections to other IKEA organisations via (1) : I've planned to use a DEC-7610 as "root" name server for all systems in : our domain (ineab.ikea.se) and a secondary server in each country. These : secondary servers would serve from a dozen up to a couple of hundred IP : hosts. I plan to use a Mvax 3100-95 in each country as name server since : we already has one on each "country head office". Is this a suitable : machine ? I expect a moderat load of DNS queries. This also means that : most end-node systems will talk DNS over 19200 and 64 kpbs WAN links. Any : problems with this? Is caching DNS answers the solution ? We have a MV3100-30 as secondary server here and it seems to cope o.k. I don't think DNS is particularly CPU intensive but it can require largish amounts of Virtual Memory if the databases get large. I don't think the bandwidth of DNS queries is likely to be a problem if these are permanent links (i.e. leased lines or X25) but if they are dialup then the time taken to start up a connection could cause DNS queries to time out. In any case caching DNS servers on each site would probably be a good idea to avoid delays in resolving local addresses due to loading on your WAN links. It would be better to make each country office at least a secondary server for your local domains so that it could carry on in the event of a loss of the WAN link. : Q1. If I appoint the DEC 7610 as primary server, can I later add another : level, i.e use a "ikea common" root name server. : I'm not sure esactly what you mean by this but I assume what you mean is that initially you would just have "ineab.ikea.se" delegated to this machine but without anything handling "ikea.se" and subsequently add a server for "ikea.se". There would be no problem with this you would just have to arrange it with the Internet regsitry for the ".se" domain (SWIPnet I believe). Once "ikea.se" had been delegated to your server then it would need the delegation records (NS and A) for the ineab.ikea.se server. You should arrange with your Internet service provider to continue to provide an offsite secondary server for all your domains. : Q2. Do I have to create the NAMED.REV and NAMED.CA files by hand, or are : they also distributed by zone transfers ? Does this apply for both : primary and secondary servers ? NAMED.CA is simply used for bootstraping the server so that it can find a root server. Once it has found one it will get the real information from it. So it doesn't matter too much if it's not completely up to date but you do have to create it manually and it doesn't automatically get updated. The best way to get a current on is to FTP it from the InterNIC. The "NAMED.REV" file needs to be created by hand on the primary server with the reverse mappings for your hosts. But will be updated by zone transfers on secondary servers. : Q3. How much knowledge of the lowest level of the network is suitable to : insert at root level. To be more specific, should I register Belgian : print boxes and terminal servers in the central root server ? If I : don't do that, how do I merge local and central DNS information ? I would suggest delegating the individual countries into sub-domains which were locally administered. However it depends on the degree of skill available in the local country offices. You might want to still administer them centrally but I would still recomend keeping them in seperate sub-domains to make adminstration easier and allow delegation later if required. There's no problem with having your primary server serve several zones just create seperate zone files and but the relevant entries into your NAMED.BOOT file. One point you need to be aware of is that you can only delegate reverse addresses on octet boundaries so it would be best to allocate seperate class C networks for each country so you can easily delegate both forward and reverse domains to the server. : Boy, a lot of questions. Guess some of this is to be found in the manual : set. If so, please direct me to it. Some other questions is more of : general interest (at least for me), and I would appriceate some advise : here. -------------------------------------------------------------+ Hope this helps. If you've got any more detailed questions you can e-mail me directly if you want. Cheers, Mike. -- ------------------------------------------------------------------------------ +*I'm not paid to make official comments for Leica, so the above isn't one.*+ Mike Wilmot-Dear (MW342) e-mail: mikewd@leica.co.uk Leica Cambridge Ltd. Tel: +44 1223-411411 (x347) Clifton Road Fax: +44 1223-210692 Cambridge, CB1 3QH, UK