Professional Software Engineering wrote:
At 07:55 2006-06-16 -0700, Don Russell wrote:
Primarily as a self-learning exercise, I'm writing a procmail script to
look at the List-ID: header (RFC 2919)
(Ref: http://ietfreport.isoc.org/idref/rfc2919/)
Dunno how you're parsing it, but the List-ID on _this_ very list doesn't
parse right down to a hostname - you have to grab the part in <>, then
strip out the first apparent domain component from the result.
Well, yes... I left those details out of my original post because they
are not really part of my problem....
But, for the sake of anybody else curious about this header....
The List-ID: header is made up of several parts:
an optional "Phrase", which precedes the <
and a "List ID" which is contained within < and > with no whitespace.
The List-ID is further defined in two parts:
The first part is the List Label, and ends with the first dot (but does
not include the dot)
The List Name Space is the part of the List ID after the first dot.
So, this _very_ list uses:
List-Id: discussion of the procmail program <procmail.lists.RWTH-Aachen.DE>
So, from the RFC...
Phrase: discussion of the procmail program
List ID: procmail.lists.RWTH-Aachen.DE
List Label: procmail
List Name Space: lists.RWTH-Aachen.DE
The List ID is case in-sensitive.
The List Name Space is something to look up via DNS.
My problem is then determining whether a dns lookup is successful or not.
[snip]
... nslookup doesn't return an error code, so it always looks
successful (=0). Procmail doesn't parse the returned text - it looks to
the program completion code.
Yes... I was counting on a non-zero return code when a "non existant
domain" condition was detected.
Program return codes are very useful, but only if they mean something.
:-) If it is always zero, it's no use as an API. :-)
With all the code "out there" that does reverse look ups, forward look
ups and what have you... and increasing use of DNS for purposes other
than "name/address translation", I thought there might be a quick/light
tool similar to "test -f" used to check the existence of a file.
Maybe I need to write one. :-)
testdns name type
And it ends with a return code indicating found, not found, or DNS
server unavailable/timeout.
Unfortunatley, dig and host are both in the same boat:
host -t MX foo.lists.RWTH-Aachen.DE ; echo $?
Remove "foo." and you'll get the same error code (0), despite the
successful output.
In general, "host" is a lighter app to use than nslookup, and nslookup is
deprecated anyway - if your system doesn't tell you as much when you run
nslookup, you must have a very old distribution of BIND, or someone altered
the source and recompiled nslookup so that it wouldn't report the warning
(which is quite possible - it's a very handy tool).
Maybe I can suggest a change to host/dig people to include a return
code.... but I suspect that won't be well received...
Cheers,
Don
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail