--On Thursday, 18 December, 2008 13:48 +0200 Ivar Lumi
<[email protected]> 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] "<" addr-spec ">" [CFWS]
>
> mailbox syntax allows: 3 value combinations.
> 1) [email protected]
> 2) <[email protected]>
> 3) john <[email protected]>
> --
> Is that allowed(without quotes): 4) john doe
> <[email protected]>
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
