ietf-smtp
[Top] [All Lists]

Re: Received,mailbox-list,address-list parsing.

2008-12-18 07:43:39



--On Thursday, 18 December, 2008 13:48 +0200 Ivar Lumi
<ivar(_at_)lumisoft(_dot_)ee> wrote:

Here for can be path / or mailbox, detecting if value is apth
or angle-addr isn't problem. But if
value is mailbox.

///         mailbox    = name-addr / addr-spec
    ///     name-addr  = [display-name] angle-addr
    ///     angle-addr = [CFWS] "&lt;" addr-spec "&gt;" [CFWS]

mailbox syntax allows: 3 value combinations.
1) john(_dot_)doe(_at_)domain(_dot_)com
2) <john(_dot_)doe(_at_)domain(_dot_)com>
3) john <john(_dot_)doe(_at_)domain(_dot_)com>
--
Is that allowed(without quotes): 4) john doe
<john(_dot_)doe(_at_)domain(_dot_)com>

Where display names are permitted at all, both (3) and (4) are
allowed without quotes.  The quotes are needed only if special
characters appear in the string.

But please do not confuse the mailbox syntax of SMTP (5321,
etc.) with that of the message body and headers (5322, etc.).
The former doesn't recognize that name phrase at all.


If i get right, the only way to parse received value is block
by block from left to right.

Please reread the text that discourages machine interpretation
of trace fields.  But, yes, you do need to proceed from left to
right with considerable look-ahead.

So how to distinguish what address type it is ? Is the only
way to read ahead and then to guess whats it is ?

I wouldn't say "guess", because it is deterministic.

Similar case is with address-list, it may contain mailbox or
group addresses, so who to distinguish address here ?

    ///     address-list = (address *("," address))
    ///     address      = mailbox / group

String split can't be used to split addresses and then process
each as block, so addresses must be read continuously. Or i
miss some thing.

You are confusing the envelope and the headers.  SMTP has never
heard of an address list and, consequently, neither have the
trace header fields.   I hope that, in moving definitions
between 2822 and 2821, we didn't foul this up.  If we did, it is
a bug.

I'm trying to find bullet-proof way to parse this values.

Why?  (Again, see the text that prohibits trying to interpret
these fields for much of anything besides debugging by humans.)

     john