[comp.protocols.tcp-ip] Mail/sendmail/RFC822 Question

mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (06/29/89)

This is a question concerning the use of an embedded space within a recipient
name.  RFC822 states on page 11 that the following is a legal address construct

		"first last"@domain

and I would assume that

		"first last"%demesne@domain

is also a valid construct.  The problem that I am having is that either Mail
or sendmail complains about an unbalanced quoted string when the above construct
is used and then attempts to deliver the message to

		first, last%demesne@domain

which is not the intended action.  Is this action a "feature" of the 4.3bsd
Mail or sendmail?

Merton

MRC@CAC.WASHINGTON.EDU (Mark Crispin) (07/06/89)

In <8906291656.AA03318@WLV.IMSD.CONTEL.COM>, mcc@wlv.imsd.contel.com writes:
>This is a question concerning the use of an embedded space within a recipient
>name.  RFC822 states on page 11 that the following is a legal address construct
>		"first last"@domain
>and I would assume that
>		"first last"%demesne@domain
>is also a valid construct.  The problem that I am having is that either Mail
>or sendmail complains about an unbalanced quoted string when the above construct
>is used and then attempts to deliver the message to
>		first, last%demesne@domain
>which is not the intended action.  Is this action a "feature" of the 4.3bsd
>Mail or sendmail?

You neglected to read the BNF on the final pages of RFC 822.  The string
	first last%demesne
is the local-part of an addr-spec in a mailbox.  A local part is a sequence of
one or more words delimited by "." (the stuff with "." being a word delimiter in
this case is a compromise between an ancient and now abandoned syntax in MMDF
that used period as the "%-hack" character and those folks who considered period
to be an ordinary character in a mailbox).  A word is either an atom or a quoted
string.

So, your string
	"first last"%demesne
violates this rule; it would have to be
	"first last".%demesne
but I seriously doubt if it would have the effect you desire.  Sendmail's
behavior was bizarre, but typical of Garbage In, Garbage Out compounded with
the Unix-ish syntax of space as a mailbox delimiter.

What you have to do, therefore, is quote the entire local part if you have any
special characters, that is,
	"first last%demesne"
or one of these alternates:
	\"first\ last\"%demesne
	"\"first last\"%demesne"
if you want the %-hack parser to see explicit quotes.

Note that the phrase which preceeds a broketed route-addr is simply a sequence
of words, so you could have:
	"first last"%demesne <"first last%demesne"@domain>

-- Mark --

-------

mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (07/12/89)

First, I would like to thank those that responded to my Mail/sendmail/RFC822
query.  Given the existing RFC822 address syntax rules, everyone pointed out
that

                "first last"%demesne@domain

should be

                "first last%demesne"@domain

Unfortunately, the latter produces the same error unless the embedded space is
explicitly quoted with a "\".  The problem is in the parsing performed in Mail
needed to support a space separated rather than comma separated list of
addressees.

As our sendmail has been configured for demesne addressing (%-hack) either of
the above forms is acceptable to sendmail.  [I think that demesne sounds better
than %-hack and is more appropriate in the sense of lands ((sub-)network)
granted to or retained by a feudal lord to administer as he wishes.]  In our
local environment, mail which specifies the ELIS demesne "%ELIS" is passed to a
mail gateway for ELIS which is responsible for routing the mail to the specific
system on which the addressee has an account.  This mechanism allows users to
be moved, readily, from system to system due to changes in jobs or equipment
failure (unfortunately a too frequent problem on the ELIS systems) without
impacting mail to and from the Internet.

The unpublished (still?) host requirements RFC suggests that demesne address-
ing should be used as an alternative to the current source routing mechanism.
This implies that the "%" is to be added to the list of special characters and
implies that the quoting used in the first of the above addresses is correct.

Based on the responses that I received and, of course, re-reading the RFC;
there appears to be some problems or inconsistencies in the RFC between the
text and the BNF.  The common problem was to misuse the term "atom" when
discussing an address--addresses are comprised of "word"s not "atom"s.  Of
course that statement is only valid if one assumes that the BNF is the correct
definition of the syntax and that the text is only there to clarify the BNF.

In the discussion on domain-dependent local strings (pp 30,31), the RFC does
identify another solution for space separated mailbox names which is to use
a "." in place of the space.  The problem with quoting address information
came about when I attempted to send a mail item to our site's Digital Account
Representative.  It seems that account rep's while they have VMS Mail accounts
prefer to use their ALL-IN-ONE mail.  ALL-IN-ONE mail addresses are in the
form:

                First Last@office

and can be accessed from VMS Mail by the following:

                MTS$::"First Last@Office"

Normal semantics for sending mail from the Internet to VMS Mail through the
decwrl gateway is to use the following:

        user%node.DEC@decwrl.DEC.COM  or  user@node.decwrl.DEC.COM

The latter instance is for sites which understand MX records.  Which led
to several attempts on my part to get a quoted string to node MTS$ which
of course was wrong and introduced the problems with the embedded space.
The correct syntax is

        First.Last%office.MTS@decwrl.DEC.COM

During the sendmail parsing of the address, the "%" will be replaced by an
"@" and the following tokens will be defined

        "First" "Last" "@" "office" "MTS"

At which point MTS (Mail Tranlation Service) has the "First Last@office"
needed to route the mail item.

Anyway, thanks for your responses again.

Merton