The breaking up of a large TXT record in a zone file would look like this: mail._domainkey IN TXT "foo" "bar baz" "blivit"
...which would be treated by libdkim as "foobar bazblivit" (i.e. the substrings are simply concatenated). However, libdkim does expect every TXT reply to be a complete record. To wit, the nameserver is free to return those TXT records in any order, and libdkim has no idea how to reassemble them in that case. The words in quotes in that example can't each exceed 255 characters, but the record as a whole can by having more than one of those strings in it. Unfortunately it sounds like AT&T's software provides a pretty serious limitation. Fortunately smaller keys (e.g. 512 bits) do fit inside a single TXT character string; you're just limited to those smaller keys until they either remove the limitation or you delegate your _domainkey subdomain to a nameserver over which you have more direct access. Were you able to get any evidence of a crash of the filter? ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ dkim-milter-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
