Archive-Date: XXX, 3 Jan 1994 07:35 MST Subject: Re: Call the police ! Message-ID: <3JAN199407352064@hearts.aces.com> From: gavron@hearts.aces.com (Ehud Gavron) Date: 3 Jan 1994 07:35 MST Reply-To: gavron@ACES.COM References: <1993Dec29.152530.194@elmrd6.ineab.ikea.se> <1993Dec30.110254.236@process.com> In article <1993Dec30.110254.236@process.com>, volz@process.com (Bernie Volz) writes... #Our International Sales Manager (Ed Brohm) says that: # # "Unfortunately, the article mixed CPU sizes and prices # incorrectly, and therefore, the prices were not completely # accurate. East Coast Marketing Sleaze company does it again. Are you guys STILL using the ad with the fake review in a fake magazine that hypes about TCPware? Are you still afraid to put your product head to head with other TCP/IP products for VMS? Is your president named Jack or John and if so why does he randomly switched? Why DID Michelle quit? These are tough questions. You don't have to answer them all at once. Today would be nice. /snort #Hope that helps you. # #- Bernie Volz # Process Software Corporation Ehud -- Ehud Gavron (EG76) gavron@aces.com ================================================================================ Archive-Date: Tue, 18 Jan 1994 15:01:32 GMT Subject: Qualifying addresses in SMTP CC: lines Message-ID: <1994Jan18.150132.18315@osg.npl.co.uk> From: MGK@newton.npl.co.uk (M G KIFF CSU BLDG. 93) Date: Tue, 18 Jan 1994 15:01:32 GMT Sender: news@osg.npl.co.uk (Network News Administration) Hello All, Is there anyone reading this group, traffic seems to be sparse.... ? Anyway a problem to consider. I have two VMS machines running TCPware and sending mail back and forth with SMTP. Say there is USER1 and USER2 on the VAX1 and USERA on VAXA If USER1 sends an SMTP message to USERA on VAXA and copies it to USER2 (on his, local, VAX1) this is what is received on VAXA: > From: SMTP%"USER1@VAX1" "Martin Kiff" 11-NOV-1993 10:05:41.49 > To: usera@vaxa > CC: USER2 > Subj: YATM (Yet Another Test Message) > > Received: from VAX1 [139.143.1.1] by vaxa > with SMTP-OpenVMS via TCP/IP; Thu, 11 Nov 1993 10:05 GMT > Date: Thu, 11 Nov 1993 10:04 UT > From: USER1@VAX1 (Martin Kiff) > To: usera@vaxa > Cc: USER2 > Subject: YATM (Yet Another Test Message) > > ....... (Lets hope I haven't mucked up the details while changing the names :-) Note the received 'CC' does not have the full address of USER2, USERA might reply in the assumption that USER2 is on *his* machine (VAXA) whereas he is on VAX1. Surely this is a bug - the sending Mail Transfer Agent should make the address non-ambiguous before it leaves the machine..... Is there anyone from Process watching the group? If not have other people run into this problem and how did they solve it? Regards, Martin Kiff mgk@newton.npl.co.uk ================================================================================ Archive-Date: XXX, 18 Jan 1994 20:11:00 -0400 From: volz@process.com (Bernie Volz) Subject: Re: Qualifying addresses in SMTP CC: lines Message-ID: <1994Jan18.201100.277@process.com> Date: 18 Jan 94 20:11:00 -0400 References: <1994Jan18.150132.18315@osg.npl.co.uk> In article <1994Jan18.150132.18315@osg.npl.co.uk>, MGK@newton.npl.co.uk (M G KIFF CSU BLDG. 93) writes: > Hello All, > (text dropped) > > Note the received 'CC' does not have the full address of USER2, USERA might > reply in the assumption that USER2 is on *his* machine (VAXA) whereas > he is on VAX1. > > Surely this is a bug - the sending Mail Transfer Agent should > make the address non-ambiguous before it leaves the machine..... > Yes, this is a bug. The SMTP agent should be fully qualifying these addresses. It is on our list of items to be addressed. When I've been sending Internet email and using CC, for the time being I've typed STMP%"..." in the CC line. While not very user friendly, it does solve the problem. This of course is not desireable to have to do over the long term. - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: XXX, 18 Jan 1994 18:07:23 GMT Subject: Re: Qualifying addresses in SMTP CC: lines Message-ID: <1994Jan18.120723.765@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 18 Jan 94 18:07:23 GMT Reply-To: dwing@uh01.Colorado.EDU References: <1994Jan18.150132.18315@osg.npl.co.uk> In article <1994Jan18.150132.18315@osg.npl.co.uk>, MGK@newton.npl.co.uk (M G KIFF CSU BLDG. 93) writes: >> From: SMTP%"USER1@VAX1" "Martin Kiff" 11-NOV-1993 10:05:41.49 >> To: usera@vaxa >> CC: USER2 >> Subj: YATM (Yet Another Test Message) >> >> Received: from VAX1 [139.143.1.1] by vaxa >> with SMTP-OpenVMS via TCP/IP; Thu, 11 Nov 1993 10:05 GMT >> Date: Thu, 11 Nov 1993 10:04 UT >> From: USER1@VAX1 (Martin Kiff) >> To: usera@vaxa >> Cc: USER2 >> Subject: YATM (Yet Another Test Message) >> >> ....... > >(Lets hope I haven't mucked up the details while changing the names :-) > >Note the received 'CC' does not have the full address of USER2, USERA might >reply in the assumption that USER2 is on *his* machine (VAXA) whereas >he is on VAX1. > >Surely this is a bug - the sending Mail Transfer Agent should >make the address non-ambiguous before it leaves the machine..... > >Is there anyone from Process watching the group? If not have other people >run into this problem and how did they solve it? I reported this problem on May 12, 1993, when I was evaluating TCPware V3.1. The Process Software log number assigned to it at the time was #4126. the specialist that responded to my report of this problem was CHAPIN. I don't know the final resolution of this problem. -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: XXX, 19 Jan 1994 02:18 MST Subject: Re: Qualifying addresses in SMTP CC: lines Message-ID: <19JAN199402184280@hearts.aces.com> From: gavron@hearts.aces.com (Ehud Gavron) Date: 19 Jan 1994 02:18 MST Reply-To: gavron@ACES.COM References: <1994Jan18.150132.18315@osg.npl.co.uk> <1994Jan18.120723.765@buckie.hsc.colorado.edu> In article <1994Jan18.120723.765@buckie.hsc.colorado.edu>, dwing@uh01.Colorado.EDU writes... # #I reported this problem on May 12, 1993, when I was evaluating TCPware #V3.1. The Process Software log number assigned to it at the time was #4126. #the specialist that responded to my report of this problem was CHAPIN. Well it's January 1994, and the East Coast Marketing Slime Company has yet to take any corrective action. Their fearless leader, Jack or John, whatever his name is today, and his sidekick Michelle "The Internet Fury" have yet to do anything useful. We wait for further news. #I don't know the final resolution of this problem. People are switching to robust TCP/IP Implementations like CMU TCP/IP, Wollongong, NRC Fusion, and TGV MultiNet. #-Dan Wing, Systems Administrator, University Hospital, Denver # dwing@uh01.colorado.edu or wing@eisner.decus.org Ehud -- Ehud Gavron (EG76) gavron@aces.com ================================================================================ Archive-Date: XXX, 19 Jan 1994 18:49:01 GMT Subject: Re: Qualifying addresses in SMTP CC: lines Message-ID: <2hjvat$7m5@nntpd.lkg.dec.com> From: huston@icecub.ako.dec.com (Steve Huston) Date: 19 Jan 1994 18:49:01 GMT Reply-To: huston@icecub.ako.dec.com References: <1994Jan18.150132.18315@osg.npl.co.uk> <1994Jan18.120723.765@buckie.hsc.colorado.edu> <19JAN199402184280@hearts.aces.com> In article <19JAN199402184280@hearts.aces.com>, gavron@hearts.aces.com (Ehud Gavron) writes: >Their fearless leader, Jack or John, whatever >his name is today, and his sidekick Michelle "The Internet Fury" have yet to >do anything useful. .. >People are switching to robust TCP/IP Implementations like CMU TCP/IP, >Wollongong, NRC Fusion, and TGV MultiNet. You are mistaken on every quoted thing you said, from the leader's name through what constitutes a robust implementation. I generally let loud-mouthed people go unanswered, but misrepresented companies, people, and products deserve some backup - you have your facts wrong. -- Steve Huston CompuCraft CompuServe: 72133,2372 61 Nadeau Drive Internet: 72133.2372@CompuServe.COM Wrentham, MA 02093-1618 huston@icecub.ako.dec.com (508) 384-5770 Currently on contract to Digital Equipment Corporation. ================================================================================ Archive-Date: XXX, 20 Jan 1994 11:57 MST Subject: Re: Qualifying addresses in SMTP CC: lines Message-ID: <20JAN199411570437@hearts.aces.com> From: gavron@hearts.aces.com (Ehud Gavron) Date: 20 Jan 1994 11:57 MST Reply-To: gavron@ACES.COM References: <1994Jan18.150132.18315@osg.npl.co.uk> In article <2hjvat$7m5@nntpd.lkg.dec.com>, huston@icecub.ako.dec.com writes... #In article <19JAN199402184280@hearts.aces.com>, I wrote: #>Their fearless leader, Jack or John, whatever #>his name is today, and his sidekick Michelle "The Internet Fury" have yet to #>do anything useful. #... #>People are switching to robust TCP/IP Implementations like CMU TCP/IP, #>Wollongong, NRC Fusion, and TGV MultiNet. # #You are mistaken on every quoted thing you said, from the leader's name #through what constitutes a robust implementation. He calls himself Jack sometimes, John others, so I don't know which his name is today. Michelle is gone so debating her name is moot. However, you're right, I should have said people are switching to MORE robust implementations like CMU TCP, DEC UCX, etc... #I generally let loud-mouthed people go unanswered, but misrepresented #companies, people, and products deserve some backup - you have your #facts wrong. Nagh, but thanks for trying! #Steve Huston CompuCraft # huston@icecub.ako.dec.com (508) 384-5770 #Currently on contract to Digital Equipment Corporation. Ehud -- Ehud Gavron (EG76) gavron@aces.com ================================================================================ Archive-Date: Fri, 21 Jan 1994 08:51:34 GMT Subject: Re: Qualifying addresses in SMTP CC: lines Message-ID: <1994Jan21.085134.19305@aragorn.unibe.ch> From: (Martin Egger) Date: Fri, 21 Jan 1994 08:51:34 GMT Reply-To: egger@ubeclu.unibe.ch Sender: news@aragorn.unibe.ch References: <1994Jan18.150132.18315@osg.npl.co.uk> In article <20JAN199411570437@hearts.aces.com>, gavron@hearts.aces.com (Ehud Gavron) writes: >#... >#>People are switching to robust TCP/IP Implementations like CMU TCP/IP, >#>Wollongong, NRC Fusion, and TGV MultiNet. ># >#You are mistaken on every quoted thing you said, from the leader's name >#through what constitutes a robust implementation. >... >However, you're right, I should have said people are switching to MORE >robust implementations like CMU TCP, DEC UCX, etc... Well, we switched *from* Wollongong *to* TCPware, some time ago because of robustness. Wollongong TCP/IP kept crashing our system and their tech support people didn't react at all. Never had any severe problem like that with TCPware since and their support is great. Martin (No relations, just a satisfied customer) ******************************************************************************* Martin Egger, Ph.D., Computing Services - Head of System/User Support Group University of Bern, Gesellschaftsstrasse 6, CH-3012 Bern, Switzerland Phone: ++41 (0)31 631 38 45, Fax: ++41 (0)31 631 38 65, Telex: 912643 pibe ch RFC: egger@id.unibe.ch, X.400: S=egger;OU=id;O=unibe;P=switch;A=arcom;C=ch; HEPNET/SPAN: 20579::49202::egger, DECnet (Switzerland): 49202::egger ******************************************************************************* ================================================================================ Archive-Date: XXX, 23 Jan 1994 15:34:29 -0600 Subject: Problem with POP3 server? Message-ID: <2huqh5$t1@bashful.cc.utexas.edu> From: samir@bashful.cc.utexas.edu (Samir Mahendra) Date: 23 Jan 1994 15:34:29 -0600 Hi, I was trying to set up eudora to work on my VMS account, and the POP3 server kept on giving me the error "%SYS-E-NOMSG, Message number 1077808A". I wasn't sure whete Eudora was causing the error, so I telnet to the POP3 server directly and entered my USER and PASS, and got the same error. After some playing around, I discovered that the message dissapeared when I used eudora without already being logged on. I want to know if there is anyway of overiding this annoying feature, if possible. Is there something I could tell the POP3 server that wouldn't mind me already being logged on? If not, could anyone tell me why it was made that way? The POP3 server on my UNIX account lets me use it while I'm already logged on. Aaah! I just realized that all my above paragraphs ended in the words logged on! Aaagh! I did it again! Thanks. P.S. For those of you who don't know, Eudora is a mail reading client for the Macintosh. -- Samir Mahendra |"English is just what we use to fill in samir@ccwf.cc.utexas.edu | between the equations." -David Politzer ================================================================================ Archive-Date: XXX, 23 Jan 1994 23:57:12 -0400 From: volz@process.com (Bernie Volz) Subject: Re: Problem with POP3 server? Message-ID: <1994Jan23.235712.291@process.com> Date: 23 Jan 94 23:57:12 -0400 References: <2huqh5$t1@bashful.cc.utexas.edu> In article <2huqh5$t1@bashful.cc.utexas.edu>, samir@bashful.cc.utexas.edu (Samir Mahendra) writes: > Hi, > > I was trying to set up eudora to work on my VMS account, and the POP3 > server kept on giving me the error "%SYS-E-NOMSG, Message number > 1077808A". I wasn't sure whete Eudora was causing the error, so I > telnet to the POP3 server directly and entered my USER and PASS, and > got the same error. After some playing around, I discovered that the > message dissapeared when I used eudora without already being logged > on. > > I want to know if there is anyway of overiding this annoying feature, > if possible. Is there something I could tell the POP3 server that > wouldn't mind me already being logged on? > > If not, could anyone tell me why it was made that way? The POP3 > server on my UNIX account lets me use it while I'm already logged on. > > Aaah! I just realized that all my above paragraphs ended in the words > logged on! > > Aaagh! I did it again! > > Thanks. > > P.S. For those of you who don't know, Eudora is a mail reading client > for the Macintosh. > -- > Samir Mahendra |"English is just what we use to fill in > samir@ccwf.cc.utexas.edu | between the equations." -David Politzer > Which POP3 server are you using and what version? The latest version of IUPOP3 we use here works just fine even if one is already logged on. - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: Mon, 24 Jan 1994 11:35:59 GMT Subject: FQDN's in Received: lines Message-ID: <1994Jan24.113559.14710@osg.npl.co.uk> From: MGK@newton.npl.co.uk (M G Kiff Blg 93) Date: Mon, 24 Jan 1994 11:35:59 GMT Sender: news@osg.npl.co.uk (Network News Administration) Martin Egger writes: > Well, we switched *from* Wollongong *to* TCPware, some time ago because of > robustness. Wollongong TCP/IP kept crashing our system and their tech > support people didn't react at all. Never had any severe problem like that > with TCPware since and their support is great. ... and we had UCX running on one machine and TCPware running on another for some months. It was TCPware which gave us the least grief. O.K. so every product has a 'history' - and UCX did have *quite* a history, it is not an apocryphal story that if you tried to rlogin to a VAX from a PC without a username set up it *halted* the VAX. Years ago now of course but it leaves the product with some hurdles to jump later. I've no doubt that Process have suffered similar embarrassments. We have made the switch to TCPware and, naturally, are now finding niggles with it, hence the question to the group. Here's another one (for your interest and delectation....), the "Received" lines in incoming SMTP mail: This is what I got on a machine (VAXA) running TCPware when it received a message: > Received: from vaxa [139.143.1.1] by vax1.npl.co.uk > with SMTP-OpenVMS via TCP/IP; Thu, 17 Jun 1993 18:40 GMT > Date: Thu, 17 Jun 1993 18:39:23 +0100 > From: usera@vaxa (Martin Kiff) > To: user1@vax1.npl.co.uk > Subject: Mail vaxa->vax1 > X-VMS-To: SMTP%"user1@vax1.npl.co.uk" What's wrong with this? Well, nothing according to my readings of the RFC's but the 'Received' line does not give a fully qualified domain name. Where does that name come from? It seems that it is what is passed over from the calling machine.... Not nice.... The calling machine can decide to be anyone. O.K. so TCPware gives you the IP address so you can do some tracebacks if you want but it isn't the nicest solution. Importantly, this 'Received' line can cause messages to go astray. Some 'MAILER-DAEMON' responses seem to try to get back to their originating machine by worming their way back up the trace of "Received" lines until they get to the top - and our mail relay considers unqualified names as suitable targets for uucp delivery. The MAILER-DAEMON messages come in and get batted back out again immediately. Just occasionally, many days later, we might get a plaintive response from a UUCP site somewhere half way round the world that they *really* didn't want to get copies of our error messages. Also the person who sent the message which caused the error is sitting and wondering why nobody has answered their message... So what is the better way? Why doesn't TCPware do a reverse lookup on the incoming IP address and put in the FQDN? Domain names are, here at least, a darn sight more stable than IP addresses, and *both* are better than believing the client. If you want to record what the client says, put it in square backets after the FQDN..... Regards Martin Kiff mgk@newton.npl.co.uk Computing Services Unit National Physical Laboratory ================================================================================ Archive-Date: XXX, 24 Jan 1994 14:04:46 GMT Subject: Re: FQDN's in Received: lines Message-ID: <2i0khu$ben@nntpd.lkg.dec.com> From: huston@icecub.ako.dec.com (Steve Huston) Date: 24 Jan 1994 14:04:46 GMT Reply-To: huston@icecub.ako.dec.com References: <1994Jan24.113559.14710@osg.npl.co.uk> In article <1994Jan24.113559.14710@osg.npl.co.uk>, MGK@newton.npl.co.uk (M G Kiff Blg 93) writes: >> Received: from vaxa [139.143.1.1] by vax1.npl.co.uk >> with SMTP-OpenVMS via TCP/IP; Thu, 17 Jun 1993 18:40 GMT >> Date: Thu, 17 Jun 1993 18:39:23 +0100 >> From: usera@vaxa (Martin Kiff) >> To: user1@vax1.npl.co.uk >> Subject: Mail vaxa->vax1 >> X-VMS-To: SMTP%"user1@vax1.npl.co.uk" > >What's wrong with this? Well, nothing according to my readings of the RFC's >but the 'Received' line does not give a fully qualified domain name. > >Where does that name come from? It seems that it is what is passed over from >the calling machine.... Not nice.... The calling machine can decide to >be anyone. O.K. so TCPware gives you the IP address so you can do some >tracebacks if you want but it isn't the nicest solution. No, not the nicest solution - but if you find the need to backtrack, you can have evidence that the other host lied. This could be useful. And, it is the main purpose of Received: to track down trouble. Also, it's very expensive to do a DNS lookup while processing the HELO command. >Importantly, this 'Received' line can cause messages to go astray. Some >'MAILER-DAEMON' responses seem to try to get back to their originating >machine by worming their way back up the trace of "Received" lines until >they get to the top Bzzt. Following backwards through Received lines is a major no-no. If your mailer does this, complain loudly to the vendor. It should use only the Return-Path line. Received lines are for diagnosis and info. If the back-host is placed in the Return-Path incorrectly by TCPware, then you can complain loudly to them ;-) -- Steve Huston CompuCraft CompuServe: 72133,2372 61 Nadeau Drive Internet: 72133.2372@CompuServe.COM Wrentham, MA 02093-1618 huston@icecub.ako.dec.com (508) 384-5770 ================================================================================ Archive-Date: XXX, 24 Jan 1994 09:29:25 MDT Subject: Re: FQDN's in Received: lines Message-ID: <1994Jan24.092925.808@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 24 Jan 94 09:29:25 MDT Reply-To: dwing@uh01.Colorado.EDU References: <1994Jan24.113559.14710@osg.npl.co.uk> In article <1994Jan24.113559.14710@osg.npl.co.uk>, MGK@newton.npl.co.uk (M G Kiff Blg 93) writes: >> Received: from vaxa [139.143.1.1] by vax1.npl.co.uk >> with SMTP-OpenVMS via TCP/IP; Thu, 17 Jun 1993 18:40 GMT >> Date: Thu, 17 Jun 1993 18:39:23 +0100 >> From: usera@vaxa (Martin Kiff) >> To: user1@vax1.npl.co.uk >> Subject: Mail vaxa->vax1 >> X-VMS-To: SMTP%"user1@vax1.npl.co.uk" > >What's wrong with this? Well, nothing according to my readings of the RFC's >but the 'Received' line does not give a fully qualified domain name. > >Where does that name come from? It seems that it is what is passed over from >the calling machine.... Not nice.... The calling machine can decide to >be anyone. O.K. so TCPware gives you the IP address so you can do some >tracebacks if you want but it isn't the nicest solution. I don't know if TCPware's SMTP Server does this, but many other mailers will do a reverse DNS lookup and compare that value to what the remote (sending) host claimed its name was in its "HELO nodename" line. If the real nodename and the nodename claimed in the HELO line don't match, the mailer will insert the IP address in the Received headers; this is an attempt to detect one kind of message spoofing. It is mentioned briefly in RFC1123, section 5.2.5, and the inclusion of the source IP address in the Received line is mentioned in section 5.2.8 of the same RFC. >So what is the better way? Why doesn't TCPware do a reverse lookup on the >incoming IP address and put in the FQDN? It is the sender SMTP's responsibility to supply a valid FQDN, not the receive SMTP's responsibility to determine this information. >Domain names are, here at least, >a darn sight more stable than IP addresses, and *both* are better than >believing the client. If you want to record what the client says, put >it in square backets after the FQDN..... -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Tue, 25 Jan 1994 18:01:32 GMT Subject: Re: FQDN's in Received: lines Message-ID: <1994Jan25.180132.28584@osg.npl.co.uk> From: MGK@newton.npl.co.uk (M G Kiff Blg 93) Date: Tue, 25 Jan 1994 18:01:32 GMT Sender: news@osg.npl.co.uk (Network News Administration) References: <1994Jan24.113559.14710@osg.npl.co.uk> <1994Jan24.092925.808@buckie.hsc.colorado.edu> In-Reply-To: dwing@uh01.Colorado.EDU's message of 24 Jan 94 09: 29:25 MDT Dan writes: > I don't know if TCPware's SMTP Server does this, but many other mailers > will do a reverse DNS lookup and compare that value to what the remote > (sending) host claimed its name was in its "HELO nodename" line. If the > real nodename and the nodename claimed in the HELO line don't match, the > mailer will insert the IP address in the Received headers; this is an > attempt to detect one kind of message spoofing. It is mentioned briefly in > RFC1123, section 5.2.5, and the inclusion of the source IP address in the > Received line is mentioned in section 5.2.8 of the same RFC. From the tests I've done it seems that TCPware doesn't do this, it has always given me the machine name as given in the HELO plus the IP address in square brackets. I've compared the behaviour to a Unix box running sendmail 5.65 with a UKsendmail config file. The sendmail system does put in the FQDN (presumably from a reverse DNS lookup) into the "Received:" line and ignores what is given in the HELO. I don't know what's technically right, but I know that the latter behaviour avoids one of our problems. Time for Process to come in again perhaps :-) Regards, Martin Kiff mgk@newton.npl.co.uk ================================================================================ Archive-Date: XXX, 26 Jan 1994 00:23:53 -0400 From: volz@process.com (Bernie Volz) Subject: Re: FQDN's in Received: lines Message-ID: <1994Jan26.002353.292@process.com> Date: 26 Jan 94 00:23:53 -0400 References: <1994Jan24.113559.14710@osg.npl.co.uk> <1994Jan24.092925.808@buckie.hsc.colorado.edu> <1994Jan25.180132.28584@osg.npl.co.uk> In article <1994Jan25.180132.28584@osg.npl.co.uk>, MGK@newton.npl.co.uk (M G Kiff Blg 93) writes: > Dan writes: > >> I don't know if TCPware's SMTP Server does this, but many other mailers >> will do a reverse DNS lookup and compare that value to what the remote >> (sending) host claimed its name was in its "HELO nodename" line. If the >> real nodename and the nodename claimed in the HELO line don't match, the >> mailer will insert the IP address in the Received headers; this is an >> attempt to detect one kind of message spoofing. It is mentioned briefly in >> RFC1123, section 5.2.5, and the inclusion of the source IP address in the >> Received line is mentioned in section 5.2.8 of the same RFC. > > From the tests I've done it seems that TCPware doesn't do this, it has > always given me the machine name as given in the HELO plus the IP address > in square brackets. > > I've compared the behaviour to a Unix box running sendmail 5.65 > with a UKsendmail config file. The sendmail system does put in the > FQDN (presumably from a reverse DNS lookup) into the "Received:" > line and ignores what is given in the HELO. > > I don't know what's technically right, but I know that the latter behaviour > avoids one of our problems. > > Time for Process to come in again perhaps :-) > > Regards, > Martin Kiff > mgk@newton.npl.co.uk We do what RFC-1123 (Host Requirements RFC) - note that we do NOT do the step of doing a reverse domain name query and checking the name; we just provide both the name specified in HELO and the IP address (assuming that a user that wanted to check the authenticity could do so himself). Note also that what the host that is sending you the mail is doing is in violation of the RFC-1123. In this case Martin, complain to the site that sent you the mail - they probably have something configured wrong or have a bad mailer. We don't have any intention of changing this behavoir since it is compliant with the RFC. The only thing we could consider doing in the future is to validate the name and indicate if they don't match in some manner on the received line. From RFC-1123 (Host Requirements): 5.2.5 HELO Command: RFC-821 Section 3.5 The sender-SMTP MUST ensure that the parameter in a HELO command is a valid principal host domain name for the client host. As a result, the receiver-SMTP will not have to perform MX resolution on this name in order to validate the HELO parameter. The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification. DISCUSSION: Verifying the HELO parameter requires a domain name lookup and may therefore take considerable time. An alternative tool for tracking bogus mail sources is suggested below (see "DATA Command"). Note also that the HELO argument is still required to have valid syntax, since it will appear in a Received: line; otherwise, a 501 error is to be sent. IMPLEMENTATION: When HELO parameter validation fails, a suggested procedure is to insert a note about the unknown authenticity of the sender into the message header (e.g., in the "Received:" line). (text cut) 5.2.8 DATA Command: RFC-821 Section 4.1.1 Every receiver-SMTP (not just one that "accepts a message for relaying or for final delivery" [SMTP:1]) MUST insert a "Received:" line at the beginning of a message. In this line, called a "time stamp line" in RFC-821: * The FROM field SHOULD contain both (1) the name of the source host as presented in the HELO command and (2) a domain literal containing the IP address of the source, determined from the TCP connection. * The ID field MAY contain an "@" as suggested in RFC-822, but this is not required. * The FOR field MAY contain a list of entries when multiple RCPT commands have been given. An Internet mail program MUST NOT change a Received: line that was previously added to the message header. - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: Thu, 27 Jan 1994 09:02:00 GMT Subject: Re: FQDN's in Received: lines Message-ID: <1994Jan27.090200.26601@osg.npl.co.uk> From: MGK@newton.npl.co.uk (M G Kiff Blg 93) Date: Thu, 27 Jan 1994 09:02:00 GMT Sender: news@osg.npl.co.uk (Network News Administration) References: <1994Jan24.113559.14710@osg.npl.co.uk> In-Reply-To: volz@process.com's message of 26 Jan 94 00: 23:53 -0400 Bernie said: > We do what RFC-1123 (Host Requirements RFC) - note that we do NOT do the > step of doing a reverse domain name query and checking the name; we just > provide both the name specified in HELO and the IP address (assuming > that a user that wanted to check the authenticity could do so himself). Put it on the wish-list :-) as an option perhaps for people who don't want the overhead of a reverse lookup on each connection.... Personally, I would have no hesitation in setting it. > Note also that what the host that is sending you the mail is doing is in > violation of the RFC-1123. In this case Martin, complain to the site > that sent you the mail - they probably have something configured wrong > or have a bad mailer. If it were so easy .... We have a number of elderly machines around, *really* elderly, maybe 5 years old.... which have little idea of Domains. What's more they don't come with Ansi C compilers so I can compile up new 'sendmail's and don't have enough disc space to compile gcc. But the internet tide sweeps on and we cannot not connect them :-) We are thus stuck between the devil (some strange method of routing error messages back to the source) and the deep blue sea (a collection of intransigent machines). The sendmail concept of being generous in what you accept and strict in what you send makes life a lot easier..... Of course, we do have a sort of solution, and that is to route all mail from the elderly machines to a sendmail host for forwarding, which is what I have set up now. It's just one more step towards an arthritic mail distribution. Regards, Martin Kiff mgk@newton.npl.co.uk ================================================================================ Archive-Date: Thu, 27 Jan 1994 09:05:32 GMT Subject: Re: Problem with POP3 server? Message-ID: <1994Jan27.090532.26653@osg.npl.co.uk> From: MGK@newton.npl.co.uk (M G Kiff Blg 93) Date: Thu, 27 Jan 1994 09:05:32 GMT Sender: news@osg.npl.co.uk (Network News Administration) References: <2huqh5$t1@bashful.cc.utexas.edu> In-Reply-To: samir@bashful.cc.utexas.edu's message of 23 Jan 1994 15: 34:29 -0600 [sound of ears pricking up....] POP3 server? Have I missed a POP3 server? I did look through Process's index for 'POP' and 'Post Office Protocol' but didn't find anything. Do they have a secret version? or is it from elsewhere..... Regards, Martin Kiff mgk@newton.npl.co.uk ================================================================================ Archive-Date: XXX, 27 Jan 1994 09:13:51 -0400 From: volz@process.com (Bernie Volz) Subject: Re: Problem with POP3 server?y Message-ID: <1994Jan27.091351.294@process.com> Date: 27 Jan 94 09:13:51 -0400 References: <2huqh5$t1@bashful.cc.utexas.edu> <1994Jan27.090532.26653@osg.npl.co.uk> In article <1994Jan27.090532.26653@osg.npl.co.uk>, MGK@newton.npl.co.uk (M G Kiff Blg 93) writes: > [sound of ears pricking up....] > > POP3 server? Have I missed a POP3 server? > > I did look through Process's index for 'POP' and 'Post Office Protocol' > but didn't find anything. Do they have a secret version? or is it from > elsewhere..... > > Regards, > Martin Kiff > mgk@newton.npl.co.uk We do not, as of yet, provide a POP server. However, you can get the IUPOP3 (Indiana University) POP3 server, build it for UCX Emulation and run if over TCPware (we use it in-house ourselves). You'll find it on FTP.INDIANA.EDU in the /pub/vms/iupop3 directory (we use v1.8-beta). - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: XXX, 31 Jan 1994 14:13:17 GMT Subject: Serial Line Internet Protocol (SLIP) Message-ID: From: AWILSON@DRUNIVAC.DREW.EDU (Al Wilson) Date: 31 Jan 1994 14:13:17 GMT My division is about to purchase an Alpha 2000. I was wondering if there was a way to invoke SLIP from inside an account, once logged on by modem. I am trying to devise an "remote mail" procedure. On-site will be Ethernet -- ====================================================================== Al Wilson Drunivac.Drew.Edu ====================================================================== ================================================================================ Archive-Date: XXX, 31 Jan 1994 18:46:17 -0400 From: volz@process.com (Bernie Volz) Subject: Re: Serial Line Internet Protocol (SLIP) Message-ID: <1994Jan31.184617.297@process.com> Date: 31 Jan 94 18:46:17 -0400 References: In article , AWILSON@DRUNIVAC.DREW.EDU (Al Wilson) writes: > My division is about to purchase an Alpha 2000. I was wondering if there > was a way to invoke SLIP from inside an account, once logged on by modem. > > I am trying to devise an "remote mail" procedure. On-site will be Ethernet > > -- > ====================================================================== > Al Wilson > Drunivac.Drew.Edu > ====================================================================== If I understand properly what you are asking, the answer is yes. You can issue a NETCU START/IP SLIP-n command once logged in to initiate a SLIP line. The account needs OPER privilege or a "TCPWARE_CONTROL" rights identifier. When the modem line is lost, the SLIP line is automatically dropped. We also provide a SLIPLOGIN.COM, which you can customize, to replace a LOGIN.COM for an account that configures a SLIP line (basically, once the user logs in, it is turned into a SLIP line). The default SLIPLOGIN.COM assumes a traditional TCP/IP network where the SLIP line requires a unqiue IP network number. Other configurations are possible (such as using a single IP address on the existing Ethernet). - Bernie Volz Process Software Corporation