Subject: [PARSE] Junk at end of address

From: Ken Weaverling <[email-masked]>
Date: Wed, 14 Jul 1993 18:45:24 PDT

I am typing this with the new PC version of Pine. That's the good news!

It is giving me parse errors when loading my inbox. They occur on some
funky To: lines that I get on mail from Digital's "Easynet"

The error message looks like...

[{pima.dtcc.edu}INBOX [PARSE] Junk at end of address: @cop.dec.com (@kw)]

The actual mail in my mail file looks like...

To: mail11.;@cop.dec.com (@kw)

The way pine displays it is....

To: [email-masked];

Pine 3.07 doesn't give the error, but munges the line identically.

Other mail agents don't choke on it, including mailx, elm, and mush.

The sender claims she sets up a mail alias for me on their VMS mail and 
she just sends to the alias.  It always arrives without a problem.

P.S. On the authentication problem, I realize that it is easy to spoof 
mail, but we shouldn't make it TOO easy.  One should be required to login 
to the imapd server to send mail and then use that login id at least to
construct the From: line.

---

From: Terry Gray <[email-masked]>
Date: Thu, 15 Jul 1993 00:03:31 -0700 (PDT)

> construct the From: line.

Ken,
Mark has given the big-picture answer, but I wanted to add one point:
Tying the "From: " line to the IMAP login has several serious problems:

  1. Many people have more than one acct where they receive mail, and
     the acct names differ.  Pine has no way of knowing which, if any,
     of those login names should be used for constructing the From: line.

  2. Even with a single acct, it is *usual* but not *guaranteed* that
     your preferred outgoing username be the same as your login name.

  3. Some people who act in different *roles* need to be able to change
     From line info depending on what type of mail they are answering.

  4. The fact that you might tie the *username* to a login doesn't give
     as much security as you might hope, as usernames are not unique
     across systems.  That is, you need to worry about the "right side"
     of the "From: " address as well as the left side.

Having said that, let me reiterate Mark's point that we *are* concerned
about authentication, but we need to solve the problem at the transport
(MTA) level, rather than the user-agent (MUA) level.  Either that or
simply wait for end-to-end solutions such as PEM. 

-teg

---

From: "D.K.Brownlee" <[email-masked]>
Date: Thu, 15 Jul 1993 10:31:06 +0100 (BST)

1 & 3 could be taken care of by permitting the user to specify a
	'from' account they wish to use, and this is checked as an IMAP login.
	If they change this during a session, an new validation is performed.
	(If needed). So they can be whoever they want - as long as they are
	validated.

	Specifying a 'Reply-To:' line would probably get past problem 2
	(At least if the remote end mailer is not *too* dumb :)
	
	Again -all your aiming for is to make it harder to fake mail using
	pine than to go direct to the telnet port... (Untill we get real
	security at the mda end)

	David

  |\/| [email-masked]. Network Analyst. Postmaster. Hostmaster.
  |  | Telephone: (+44) 71 477 8000 Ext:3757.
 Snailmail: E308, City University, Northampton Sq, Islington, London ECIV 0HB.

---

From: Mark Crispin <[email-masked]>
Date: Thu, 15 Jul 1993 15:19:13 -0700 (PDT)

Ken -

The address string
	mail11.;@cop.dec.com (@kw)
is not in compliance with RFC-822 (or to my knowledge any other e-mail
standards).

The problem is the semicolon; this is explicitly defined as a ``special'' in
RFC-822.  Consequently, it has to be quoted.  Ref: RFC-822, pp 44-47,
definitions of ``local-part'', ``atom'', ``specials''.  The string:
	"mail11.;"@cop.dec.com (@kw)
would have parsed successfully.

In order to deal with the buggy mail programs that still fail to write the
host field in the mailbox (e.g. ``To: Joe, Fred, Sally''), Pine will try to
parse an address with a missing host field.  Thus, it reads ``mail11.'', sees
a special other than an @, and assumes this is a missing host address and
substitutes the local host name.  Having now finished the address parse, it
goes further, encounters the semicolon when it was not expecting one (it is
only permitted as a group list terminator), and reports an error.

To be truly pedantic, Pine should have choked at the period.  Technically,
period is also a special, but can be used to attach multiple words (e.g.
foo.bar.zap).  However, words cannot be null, so ``mail11.'' isn't valid since
there is nothing after the period.

I have no trouble believing that mailx, elm, and mush ignore this syntax error
instead of reporting it to the user as Pine does.  That doesn't mean that
these programs do the ``right thing'', because there is no right thing in
parsing this address.

I do not believe that any useful information exists with this address.  It's
totally garbaged.  I suggest that you report it as a bug in your site's
mailer, and be thankful that Pine took the trouble to alert you to the problem
instead of ignoring it.