Subject: pine does not handle source route format correctly

From: Alan Thew <[email-masked]>
Date: Wed, 14 Apr 1993 12:18:59 +0100 (BST)

I have an application that uses source route format addresses, e.g.

	@gateway:user@host

While this is old and out of date, it is still used by a number of MTAs
and when 'full headers' is set to 'off', the To: field is not shown if the
field is in source route format. Is this by design or is it a bug?

(pine 3.05)

---

From: Mark Crispin <[email-masked]>
Date: Wed, 14 Apr 1993 11:36:11 -0700 (PDT)

> field is in source route format. Is this by design or is it a bug?

I'm a bit confused by this message.  Pine *does* parse the old (and obsolete,
as the Host Requirements for Mail abolished it) source route format addresses,
although it doesn't do anything particular with the a-d-l (the ``@gateway:'')
information.

Your message, however, implies that Pine did not parse the address at all,
otherwise something would have shown up.  There must have been some syntax
error that caused Pine's parser to reject it.  In RFC-822, source routes can
only appear in a bracketed address of the form:
	personal name <@gateway1,@gateway2,@gatewayn:user@host>
The Host Requirements for Mail made the personal name optional, so
	<@gateway1,@gateway2,@gatewayn:user@host>
is also permitted.  Note the presence of the angle brackets, which are
mandatory.  Pine permits both formats.

If you believe that your application is using source routes correctly, please
forward me a sample message which exhibits the behavior in Pine.

I question the overall utility of source routes in your application.  Many
people were led to believe that source routes would be useful.  They aren't.

[Some history]  Source routes were put into RFC-822 as a quick and dirty
compromise in the wake of the ``multiple-@'' fiasco as a proposed ``solution''
for the problem.  The former mail standard, RFC-733, allowed addresses of the
form
	user at host at gateway1 at gateway2 at gatewayn
This address syntax caused a mailer used by many DCA personnel to crash, and
in typical military fashion they decreed that the syntax be abolished rather
than the program be fixed.  Since they ran the net back then, they got what
they wanted...  As an emergency patch, I changed all but the final ``at'' to
``%'' to work around the DCA restriction.  [Yes, I'm the fellow to blame for
the infamous ``% hack''.]  Source routes were supposed to abolish the ``%
hack'', but a subsequent DCA restriction required that the string to the right
of the @ had to be in the host table (later, the DNS), which crippled source
routes and made them useless.  Consequently many mailers never bothered to
implement them.

I've noticed that more than one site in foreign countries, who couldn't care
in the slightest what DCA wanted (lucky!), implemented (and use) source routes
for more or less the original intended purpose.  However, if you do so, you
end up running up against problems when interoperating outside of your local
environment.  As a practical matter, you can't trust it to work, and because
of their abolition by the Host Requirements for Mail you can't make anyone
else fix their mailer to use them.  It's ultimately a lot less effort to get
the appropriate MX glue into the DNS, or at worst use the %-hack.

Please let me know if I can assist you in any way in figuring out what the
problem is.  Pine does support the source route syntax to the point of parsing
it, even if it doesn't do anything in particular with the data.

-- Mark --