[comp.mail.mush] mush adding commas to addresses

bob@omni.com (Bob Weissman) (05/21/89)

mush seems to insist on adding commas to the end of addresses, so the
receiving end sees bogus addresses.

I.e., I get back messages of the form
	"joe," -- no such address

Has anyone else seen this problem?  If so, what do I do to fix it?

I'm running mush 6.4 of 2/14/89 on a Sun4 running SunOS 4.0.1.

Thanks,

-- 
Bob Weissman

Internet: bob@omni.com
UUCP:	  ...{amdahl,apple,tekbspa,uunet}!koosh!bob

dheller@cory.Berkeley.EDU (Dan Heller) (05/21/89)

In article <39@mondo.omni.com> bob@omni.com (Bob Weissman) writes:
> mush seems to insist on adding commas to the end of addresses, so the
> receiving end sees bogus addresses.

some general info:
RFC822 requires using commas between addresses so as to identify them
from other addresses.  However, some MTAs such as /bin/mail and other
older sys-v and xenix mailers don't like commas between addresses.
As a result you should define NO_COMMAS in your config.h file.

In this case, your system is a sun so I can't figure why you're having
a problem unless you are not using sendmail -- perhaps you're using an
OLD version of smail before it became rfc-compatible?

> I.e., I get back messages of the form
> 	"joe," -- no such address
> Has anyone else seen this problem?  If so, what do I do to fix it?
I've seen this problem whenever someone is using a non-rfc compatible
MTA such as smail 2.0 (or pre-3.0?).

If your system is running sendmail, then you have another problem and
I'd need more info (but I doubt this to be the case).
Dan Heller	<island!argv@sun.com>

dheller@cory.Berkeley.EDU (Dan Heller) (05/22/89)

I think I made an error in this statement:

> some general info:
> RFC822 requires using commas between addresses so as to identify them
> from other addresses.

I am probably wrong about RFC822 because it might not say anything about
multiple addresses on the same line.  I'm at home now, so I can't check
my RFC which is at work :-)  However, it is certainly accepted protocol
to separate addresses with commas -- sendmail requires it as well as many
other RFC-compliant MTAs.  The reason for this is that addresses can have
multiple words in it:
    island!argv (Dan Heller) @ sun.com
and it is all considered one address.  If there is another address
following it, how is any parser going to determine the end of one
address and the beginning of another.  Therefore, the delimeter to
separate addresses can't be spaces.  Commas are used.

This interferes with a valid addressing scheme that Bart and I call
"weird" addresses because altho they are legal, they are inconvenient
because they contain commas.  e.g. a legal address might look like:
    @host.dom.ain,@cad.berkeley.edu:argv@island.uucp
Here, the hostnames are separated by commas, but if you try to use this
address in any mail user agent, then it will probably break because the
commas are the address delimeters.

Sometimes, mush parses a folder that has this style of address in the From_
line (check any mail that comes out of toranto :-).  Mush knows that there
is one and only one address in the From_ line, so it knows how to parse
that address correctly.  What it does is convert it to a more reasonable
type of address (@-format, unless you've configured mush with UUCP defined).

Dan Heller	<island!argv@sun.com>

david@ms.uky.edu (David Herron -- One of the vertebrae) (05/23/89)

In article <14033@pasteur.Berkeley.EDU> dheller@cory.Berkeley.EDU (Dan Heller) writes:
>I think I made an error in this statement:
...
>> some general info:
>> RFC822 requires using commas between addresses so as to identify them
>> from other addresses.
...
>I am probably wrong about RFC822 because it might not say anything about
>multiple addresses on the same line.  I'm at home now, so I can't check
>my RFC which is at work :-)  However, it is certainly accepted protocol
>to separate addresses with commas -- sendmail requires it as well as many
>other RFC-compliant MTAs.  The reason for this is that addresses can have
>multiple words in it:
>    island!argv (Dan Heller) @ sun.com

Comma's *are* required ...




>This interferes with a valid addressing scheme that Bart and I call
>"weird" addresses because altho they are legal, they are inconvenient
>because they contain commas.  e.g. a legal address might look like:
>    @host.dom.ain,@cad.berkeley.edu:argv@island.uucp

Actually you're required to put <>'s around that construct -- I suppose
to hide the "," from being seen by an address parser.  What I wonder is
why they wanted to use comma's here in the first place?  It's as clear
to use :'s where they want to use comma's.



-- 
<- David Herron; an MMDF guy                              <david@ms.uky.edu>
<- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<- By all accounts, Cyprus (or was it Crete?) was covered with trees at one time
<- 		-- Until they discovered Bronze

comp-mail-mush@srhqla.uucp (05/23/89)

From: "Barton E. Schaefer" <island!ucbcad!ogccse.ogc.edu!schaefer>

In article <14033@pasteur.Berkeley.EDU> you write:
} I think I made an error in this statement:
} 
} > some general info:
} > RFC822 requires using commas between addresses so as to identify them
} > from other addresses.
} 
} I am probably wrong about RFC822 because it might not say anything about
} multiple addresses on the same line.  I'm at home now, so I can't check

Dan was correct.  From RFC822, section 2 (Notational Conventions), page 4:

    2.7.  #RULE:  LISTS

	A construct "#" is defined ... as follows:

			    <l>#<m>element

    indicating at least <l> and and most <m> elements, each separated
    by one or more commas (",").  ....

And from section 4.1 (Message Specification, Syntax), page 18:

    destination =  "To"          ":" 1#address  ; Primary
		/  "Resent-To" ....

Therefore a "To:" field has at least one and at most an unspecified
number of addresses, separated by one or more commas.

} The reason for this is that addresses can have
} multiple words in it:
}     island!argv (Dan Heller) @ sun.com
} and it is all considered one address.

I might point out that mush itself wouldn't understand the example Dan
gave there unless it were fully RFC822-compliant, which means it has to
be in <> as in:

	<island!argv (Dan Heller) @ sun.com>

and even then I wouldn't guarantee mush will figure it out in all cases
(though the ones where it fails are largely cosmetic, such as doing
autosigns and alternates).

} This interferes with a valid addressing scheme that Bart and I call
} "weird" addresses because altho they are legal, they are inconvenient
} because they contain commas.  e.g. a legal address might look like:
}     @host.dom.ain,@cad.berkeley.edu:argv@island.uucp

Actually, *I* call them "stupid". :-)  Sendmail doesn't seem to like <>
on its From_ lines, so it strips them out.  To make this "legal", you
have to put <> around it, just like the one with the comment in the
middle that was given above.  <> has higher precedence than commas.

} Dan Heller	<island!argv@sun.com>
                ^                   ^
		!		    !

-- 
Bart Schaefer       "And if you believe that, you'll believe anything."
							-- DangerMouse
CSNET / Internet                schaefer@cse.ogc.edu
UUCP                            ...{sequent,tektronix,verdix}!ogccse!schaefer

tneff@bfmny0.UUCP (Tom Neff) (05/23/89)

In article <663@srhqla.UUCP> comp-mail-mush@srhqla.uucp writes:
)    2.7.  #RULE:  LISTS
)
)	A construct "#" is defined ... as follows:
)
)			    <l>#<m>element
)
)    indicating at least <l> and and most <m> elements, each separated
)    by one or more commas (",").  ....
)
)And from section 4.1 (Message Specification, Syntax), page 18:
)
)    destination =  "To"          ":" 1#address  ; Primary
)		/  "Resent-To" ....
)
)Therefore a "To:" field has at least one and at most an unspecified
)number of addresses, separated by one or more commas.

The problem I had with Sys V mail(1) as an MTA with Mush 6.4 a while
back was that Mush seemed to be APPENDING a comma even to a SINGLE
address!  I.e. 'mush joe' yielded an error message from mail(1)
saying 'Unknown address "joe,"'.  I switched to Smail 2.5 and the
problem went away, possibly because Smail is nicer.  I didn't look
too hard, had enough other problems in my life. :-)

I don't think a singleton of the form "joe," fits the above
syntax rule, do you?
-- 
Tom Neff				UUCP:     ...!uunet!bfmny0!tneff
    "Truisms aren't everything."	Internet: tneff@bfmny0.UU.NET

schaefer@ogccse.ogc.edu (Barton E. Schaefer) (05/24/89)

In article <14340@bfmny0.UUCP> tneff@bfmny0.UUCP (Tom Neff) writes:
} In article <663@srhqla.UUCP> schaefer@cse.ogc.edu (Bart Schaefer) writes:
} )
} )			    <l>#<m>element
} )
} )    indicating at least <l> and and most <m> elements, each separated
} )    by one or more commas (",").  ....
} )
} )    destination =  "To"          ":" 1#address  ; Primary
} 
} The problem I had with Sys V mail(1) as an MTA with Mush 6.4 a while
} back was that Mush seemed to be APPENDING a comma even to a SINGLE
} address!  I.e. 'mush joe' yielded an error message from mail(1)
} saying 'Unknown address "joe,"'.

I don't remember for certain any more, but I believe there may have been
a bug in 6.4 that caused trailing commas to be left in the addresses in
certain cases.  I believe it had something to do with using "replyall".

} I don't think a singleton of the form "joe," fits the above
} syntax rule, do you?

The paragraph in section 2.7 about the # rule continues:

		   ... Wherever this construct is used, null elements
    are allowed, but do not  contribute  to  the  count  of  elements
    present.   That  is,  "(element),,(element)"  is  permitted,  but
    counts as only two elements.  Therefore, where at least one  ele-
    ment  is required, at least one non-null element must be present.
    ...

So apparently "joe," or even ",,joe,,," fits the rule.  Nevertheless,
it *was* considered a bug that mush appended an extra comma, and as far
as I can tell this has been fixed.
-- 
Bart Schaefer       "And if you believe that, you'll believe anything."
							-- DangerMouse
CSNET / Internet                schaefer@cse.ogc.edu
UUCP                            ...{sequent,tektronix,verdix}!ogccse!schaefer