The state I'm in - rfc 822 parsing.

[Sam Roberts]

As I as thinking, what possible use could there be for
the route part of a route-addr in this day and age, I
was trying to get mail to a friend at local.domain.edu.
It was bouncing, and I couldn't nslookup any MX records
for local.domain.edu, which seemed problematic, but I
groped around and found the MX records for domain.edu,
telneted to their smtp servers, and found they were willing
to accept mail for @local.domain.edu, as well as for
@domain.edu. Hey, I thought, couldn't I use a route
addr for that? Joe <@domain.edu: address@hidden>.

Alas, nullmailer didn't accept that...

Anyhow, I'm parsing everything that's allowed, I think,
plus the comment at the end of an addr-spec (when it's
at the end of a mailbox).

I'm particularly proud of:

Sam <@[matrix (smtp)], @[nexus: \[node 12\]]:address@hidden>

Which I'm convinced is syntatically valid. Not that it'd
ever get delivered... 8-)

The old address-create() is still there, and mine is called
address_create0(), other than that the apis are the same.

I've also added apis to get the local-part, the domain,
and the route.

If I find the awful comment, I put it where I would have
put a phrase.

I accept route-addrs without a phrase in front.

Groups just look like more addresses, I discard their names.

I have to construct the email address from the local-part
and domain, and I haven't ported my quoter, so right now
the email address can be wrong.

 (in the attached files, search for "b- ", looks like the
 author of qmail has a sense of humour)

I wrote a little test app, addr.c, that uses the old (-1)
or my (-0, by default of course :)) parser, and prints
what it finds.

I scoured my mailboxes for interesting addresses, and
Addrs is what I found. Attached is the result of running
addrs on it, once with create0(), and one with the
existing create().

Note:

<strings.h> is needed under Nto for one of the non-standard
string functions in mbx_imap.c, so I conditionally included
it.

---

Next:

- I'm ok with this being checked in, I think it lives nicely
to the side of whats there, so it won't screw anybody, but
people can play with it. If you want. 8-)

- <>, valid in SMTP "rcpt from:", should I parse and ignore it?

- I don't accept > 127 chars as ascii anywhere, should I allow
them in the personal name? Can somebody send me example fields
that have them?

- I don't check for memory failure (duck). My excuse: no
feedback on whether the reallocations I'm doing make people
cringe. I.e, whether I need to rework the building up of strings.
I can think of some other ways to do it, but I don't want to
if I don't have to.

- proper prototypes and naming conventions, maybe even a more
abstract api for the parser, C++ comments -> C comments, etc.

- Read through djb's pages, try and find anything he thinks
might be worth parsing even though its non-standard.

- rfc 2047 translator?

Good night.
Sam

-- 
Sam Roberts <address@hidden> (http://www.emyr.net/Sam)

parser.diff
Description: Text document

parse822.c
Description: Text document

addr.c
Description: Text document

Addrs
Description: Text document

addr0
Description: Text document

addr1
Description: Text document