[Info-vax] bizarre SMTP problem

[Phillip Helbig---remove CLOTHES to reply]

In article <49de59df$0$31194$c3e8da3 at news.astraweb.com>, JF Mezei
<jfmezei.spamnot at vaxination.ca> writes: 

> Bob Eager wrote:
> 
> > Then it appears to be a bug, since '+' is perfectly valid as a character
> > in an email address, as per RFC 2822 section 3.4.1.
> 
> VMSmail is NOT and never has been an SMTP mail client.  It has a foreign
> mail transport to allow messages to be sent to the outside world.

Right, but...see below.

> the "+" seems to be a basic function of VMSmail to allow multiple
> destinations to be specified on a single line. So the "+" gets processed
> by VMSmail well before the address is handed over to the SMTP% foreign
> transport.

Yes.  But is the "+" documented anywhere?

> So this isn't a RFC822 problem. It is just a feature of MAIL.

Right.

> Note that while MAIL isn't RCF822 aware, one of the very few
> improvements made to MAIL since last century was to assume smtp%
> whenever it found an @ in an address. 

Except at the very beginning, when it denotes a distribution list.

> I guess they could have provide
> for better support of email addresses systax at that point.

My point exactly.

> HOWEVER: removing the "+" function to allow multipe addresses to be
> specified would have negatively affected some users who did make use of
> the "+" sign. (was it ever documented ?)

That's the interesting question.  Of course, even if it is not 
documented, it still has to be supported, otherwise stuff will break.  
:-|

However, it doesn't have to be removed if the parsing is done more
intelligently.  Anyone using the "+" must have been using it for
non-SMTP addresses, so asking him to not use it if he does use SMTP 
addresses wouldn't break anything.  In other words, if there is "@" 
anywhere but at the beginning, assume SMTP and don't use + as a list 
separator.

I wonder if it is EXACTLY the same as using the comma?  I'm reminded of 
the arguments to the FORTRAN command:

FORTRAN

  Parameters


     file-spec-list

     Specifies the source files containing the program units to be
     compiled.  If you do not specify a file type, the compiler uses the
     default file type of FOR, unless /LIBRARY is specified in which
     case the default file type is TLB.

     You can specify more than one input file.  If source file
     specifications are separated by commas (,), the programs are
     compiled separately and an object module is produced for each file.
     If source file specifications are separated by plus signs (+), the
     files are concatenated and compiled as a single input file,
     producing one object file and, if /LIST is specified, one listing
     file.