|
From: | Sam Roberts |
Subject: | The state I'm in - rfc 822 parsing. |
Date: | Mon, 12 Mar 2001 23:40:30 -0500 |
User-agent: | Mutt/1.3.16i |
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
[Prev in Thread] | Current Thread | [Next in Thread] |