Subject: pine 3.85 cannot handle source routes

From: Erik Lawaetz <[email-masked]>
Date: Thu, 7 Oct 1993 16:42:56 +0100 (MET)

I tried mailing to 2 addresses of the format:

 @vm.uni-c.dk:user@node

which is a fully legal way of mailing to EARN and BITNET users 
(vm.uni-c.dk being my local gateway).

However PINE wouldn't accept it, claiming there to be "Junk at end of 
address". In this case I'll claim the "junk" to be in pine instead.

--Erik

---

From: "Michael J. Corrigan" <[email-masked]>
Date: Thu, 07 Oct 1993 10:48:37 -0700

I agree - pine should not force addresses to be in a certain format.

-Mike Corrigan

      @vm.uni-c.dk:user@node

     
     --Erik

---

From: Steve Hubert <[email-masked]>
Date: Thu, 7 Oct 1993 11:25:52 -0700 (PDT)

Source routes are actually required to be in brackets.  I think if you 
use brackets it will work.

Steve Hubert <[email-masked]>
Networks and Distributed Computing, Univ. of Washington, Seattle

---

From: Mark Crispin <[email-masked]>
Date: Thu, 7 Oct 1993 11:19:14 -0700 (PDT)

> address". In this case I'll claim the "junk" to be in pine instead.

Please review RFC 822 and RFC 1123.  The correct syntax is
  <@vm.uni-c.dk:user@node>
and that works just fine.  If you investigate the other address formats that
Pine attempts to parse, including some very common bogons, you'll see why the
brokets are required; too many ambiguities otherwise.

However, I question why you are using RFC 822 source routing addresses at all.
These have been deprecated, because ``node'' is required to be a valid entity
in the Domain Name System.  So, you have to use something like the infamous %-
hack, e.g. [email-masked], to get around this.

Sigh.  I was one of the individuals, 10+ years ago, who pressured (rather
LOUDLY) for source routing in RFC 822, after the Powers That Be of the time
banned the RFC 733 multiple-@ syntax (which looked like ``user at node at uni-
c-vm'').  When RFC 822 was issued, I went to implement source routes and
immediately ran up against the ``must be a valid name in the  host table
(later DNS)'' rule.  The %-hack was a 2AM fix for the problem.  [Not that the
%-hack was without problems; it was responsible for the entire OS development
group at a major computer vendor being unable to log in the next day...]  :-)

---

From: Erik Lawaetz <[email-masked]>
Date: Fri, 8 Oct 1993 09:14:26 +0100 (MET)

> brokets are required; too many ambiguities otherwise.

Are you seriously suggesting that I should tell my users: "Oh yes, btw 
for some addresses you might need to put it in <>s" ?

I don't posses your intimate knowledge of RFC 822 nor 1123, which I 
assume is the host requiremtns rfc, but from a user's perspective I'd 
rather have PINE accepting the address. The UAs I've used previously 
generously did this, and to the best of my knowledge did not create any 
problems.

> hack, e.g. [email-masked], to get around this.

Looks like my weekend will be spent rereading 822 and reading 1123? ;-)

--Erik

---

From: Mark Crispin <[email-masked]>
Date: Fri, 8 Oct 1993 03:19:25 -0700 (PDT)

> for some addresses you might need to put it in <>s" ?

Unfortunately, yes.  There are ambiguities that occur otherwise.

> generously did this, and to the best of my knowledge did not create any 

How did the other UAs solve the parsing ambiguities?

To be more specific about the problem with source routes, the host
requirements RFC (RFC 1123) explicitly depreciates them (paragraphs 5.2.6,
5.2.19).  Technically, Pine is in violation of the Host Requirements by
permitting their use at all.  We would have no defense to the ``protocol
police'' if someone received a message with one that was generated by Pine
and complained. 

Host Requirements specifies that some means of mail relaying that does not
involve the use of RFC 822 source routing be used instead, e.g.
	[email-masked]
(the so-called %-hack) instead of
	<@uni-c.dk:user@node>
This recommended way (RFC 1123 paragraph 5.2.16) is three characters
shorter and arguably easier to understand! 

So, we're between a rock and a hard place.  We're not supposed to permit
the user to use source routes, there's an officially blessed alternative,
and there's a possibility that it might break something else if source
routes were permitted outside of the angle brackets. 

Would it be possible to use the ``% hack'' instead?