Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uflorida!mlb.semi.harris.com!thrush.mlb.semi.harris.com!del From: del@thrush.mlb.semi.harris.com (Don Lewis) Newsgroups: comp.mail.uucp Subject: Re: uucp mail question Summary: Berkeley sendmail is broken Keywords: uucp mail somewhere address paths Message-ID: <1990Aug17.051854.25525@mlb.semi.harris.com> Date: 17 Aug 90 05:18:54 GMT References: <987@fico2.UUCP> <863@gvlv2.GVL.Unisys.COM> <1990Aug13.221553.17992@mp.cs.niu.edu> Sender: news@mlb.semi.harris.com Distribution: usa Organization: Harris Semiconductor, Melbourne FL Lines: 105 In article <1990Aug13.221553.17992@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <863@gvlv2.GVL.Unisys.COM> tim@gvlf9.GVL.Unisys.COM (Timothy Scharping) writes: >> >>The problem that I am having is caused by an improper From (no colon) line >>being received by rmail on the BSD machine. A proper From line is composed >>of an address followed by a date. >> >>From chris@ADMS-RAD.Unisys.COM Mon Aug 13 15:01:00 1990 This is an improper envelope From_ line (see RFC976). From_ lines use band paths, not @'s. The header From: line is governed by RFC822 and should contain an address in @ format. The From_ line above is probably due to a sendmail deficiency. In stock Berkeley sendmail, the same rewriting rules are used for both the envelope and body addresses. If the sendmail.cf is written to make the header From: address a valid RFC822 address, it munges the envelope From_ into the above invalid format. The IDA sendmail enhancements provide for separate header and envelope rewriting rules which can prevent this from happening. It is also possible to provide a filter to fix the envelope, but it sure would seem to be desirable if Berkeley picked up this particular enhancement to sendmail so that it would be RFC complient. >> >>When mail is sent via uucp something (uux??) should tack a "remote from" >>piece on the end of the From line. A correct example looks like: >> >>From ADMS-RAD.Unisys.COM!chris Mon Aug 13 15:00:46 1990 remote from imagine >> This is correct. >...... >>The somewhere entry is created when rmail receives a message that doesn't >>have the "remote from" portion of the From line. The rmail source is written >> > I did some test on my rmail. The following seems to be the story: > > Firstly, neither uux nor rmail provides the 'remote from'. This comes from >the sending MTA. For example, in a 'sendmail' based system, it is the >responsibility of 'sendmail' to add the 'remote from' to the end of the >Unix from line. > > Secondly, many versions of 'rmail' do not require the 'remote from'. In my >4.3 based system, the vendor's version of rmail does not insist on a >'remote from'. I suspect this is a common state of affairs in BSD systems. > > HOWEVER - rmail DOES insist on having a sending host name. Because it is >used for UUCP transport, it uses a '!' to determine this system. > > Thus the line: > >From chris@ADMS-RAD.Unisys.COM Mon Aug 13 15:01:00 1990 > >does not have a 'remote from' nor a '!'. Hence many rmail versions will >add a 'remote from somewhere'. > >From chris@ADMS-RAD.Unisys.COM Mon Aug 13 15:01:00 1990 remote from imagine > >will not generate a 'somewhere', but will be converted by rmail into the >incorrect 'imagine!chris@ADMS-RAD.Unisys.COM' as the sender. But if the From_ line was originally correct (like the one below) then ... > >From ADMS-RAD.Unisys.COM!chris Mon Aug 13 15:01:00 1990 remote from imagine > >is OK. It will generate a sender address of 'imagine!ADMS-RAD.Unisys.COM!chris' >which is correct, but is not a valid RFC822 address. If you unleash this as >a sender address some Internet hosts will refuse to accept the mail. But it doesn't matter that this is not a valid RFC822 address. The pertinent RFC is 976, and it says that this line is correct. Remember, there is still a valid RFC822 From: line, or at least there had better be! From: chris@ADMS-RAD.Unisys.COM > >From chris Mon Aug 13 15:01:00 1990 remote from ADMS-RAD.Unisys.COM > > This might work. It is risky with some systems, because of the periods, and >the length of the 'remote from' host name, which violate UUCP standards. > >From ADMS-RAD.Unisys.COM!chris Mon Aug 13 15:01:00 1990 > > This is the best choice in many cases. Many versions of 'rmail' will accept >it, in spite of their being no 'remote from' because there is at least an '!'. >Furthermore, if this is pumped into 'sendmail', most versions of 'sendmail.cf' >will convert 'ADMS-RAD.Unisys.COM!chris' to 'chris@ADMS-RAD.Unisys.COM' >leaving a valid RFC822 address. Well, sendmail should'nt be mucking with the From_ line at all, and the From: line (chris@ADMS-RAD.Unisys.COM) should be untouched by its travels. If the recipient is using a RFC822 complient mailer, then he can reply to the From: address since it is in RFC822 format. If the recipient is using some sort of brain dead mailer, then he is going to need an unmangled address in the From_ line. The last example won't work, since his mailer won't know that it needs to forward the mail to imagine in order to get to ADMS-RAD.Unisys.COM. The From_ line From ADMS-RAD.Unisys.COM!chris Mon Aug 13 15:01:00 1990 remote from imagine which gets translated into From imagine!ADMS-RAD.Unisys.COM!chris ... is the correct one. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901