[rbldnsd] AAAA Queries?

[Steven F Siirila]

On Sat, Jul 29, 2006 at 04:25:19PM +1200, Amos Jeffries wrote:
> ----- Original Message ----- 
> From: "Steven F Siirila" <sfs at tc.umn.edu>
> To: "Small Daemon for DNSBLs" <rbldnsd at corpit.ru>
> Sent: Saturday, July 29, 2006 5:54 AM
> Subject: Re: [rbldnsd] AAAA Queries?
> 
> 
> >On Fri, Jul 28, 2006 at 01:49:05PM -0400, Victor Duchovni wrote:
> >>On Fri, Jul 28, 2006 at 12:41:33PM -0500, Steven F Siirila wrote:
> >>
> >>> We are currently using this snippet to query DNSbls.
> >>> We do not yet run IPv6 though, so it shouldn't be an issue anyways.
> >>>
> >>> #define UC(b)   (((int)b) & 0xff)       /* converts char to int (0-255) 
> >>> */
> >>>
> >>> /*
> >>>  * dnsbl - read DNS block list data
> >>>  */
> >>> struct hostent *
> >>> dnsbl(char *domain, in_addr_t ipaddr)
> >>> {
> >>>     char *cp;                           /* general purpose */
> >>>     char hbuf[MAXHOSTNAMELEN];          /* temporary host name buffer 
> >>> */
> >>>     struct hostent *hp;                 /* host node pointer */
> >>>
> >>>     cp = (char *)&ipaddr;
> >>>     sprintf(hbuf, "%d.%d.%d.%d.%s",
> >>>             UC(cp[3]), UC(cp[2]), UC(cp[1]), UC(cp[0]), domain);
> >>>     if (debug) {
> >>>         errmsg("Querying %s", hbuf);
> >>>     }
> >>>     if ((hp = gethostbyname(hbuf)) == NULL && h_errno == TRY_AGAIN) {
> >>>         errmsg("Temporary error querying %s", domain);
> >>>     }
> >>>     return(hp);
> >>> }
> >>
> >>This code is wrong, it will make queries for "IP.RBL.<parent_domain>" for
> >>each domain on your search list. It will on IPv6 capable systems make
> >>"AAAA" queries, ... It is not capable of reading the corresponding TXT
> >>record. Rewrite using res_init(3), res_search(3), ...
> >
> >Granted, it is not ideal.  It should probably be changed.  But until there
> >is a real need to, it's not going to happen due to other time commitments.
> >
> >We don't use TXT records either, we write a custom 550 5.7.1 message with
> >a URL containing encrypted data, allowing the sender to initiate a three-
> >way handshake process, etc...
> 
> Which is in itself not the correct way of doing things. !!

By whose definition of correct?  The way we do things has proven to be
immensely helpful and takes the mail administrator out of the loop.
If the remote user follows the URL, they are given the opportunity to
have an explanation e-mailed to the originator address which they used
(not an address of their choice) -- which is obtained from the encrypted URL.
In this explanation they are told why they were blocked and how to request
a block exception from their intended recipient.  This has been in use since
2002 and has been very successful here at the University of Minnesota.

> The whole point of the TXT field in RBL is to provide a way for the sender 
> to know why their email did not get through.

We provide a lot more, including a URL to the RBL site, in the above.

> The biggest problem I have as an I/ESP is the number of other providers who 
> re-write the 554 (gmail.com being the most annoying with "554 Delivery 
> failed"). Simply locating the fault in the delivery chain is vastly 
> complicated, since its usually done over the phone to a non-tech.
> 
> 
> >
> >Thanks for the tips!  BTW, I'm an old-timer when it comes to C coding 
> >(1991).
> >
> >P.S. I hate HTML-only e-mail with a passion as well.  :)
> >
> >-- 
> >
> >Steven F. Siirila Office: Lind Hall, Room 130B
> >Internet Services E-mail: sfs at umn.edu
> >Office of Information Technology Voice: (612) 626-0244
> >University of Minnesota Fax: (612) 626-7593
> >_______________________________________________
> >rbldnsd mailing list
> >rbldnsd at corpit.ru
> >http://www.corpit.ru/mailman/listinfo/rbldnsd
> >
> 
> _______________________________________________
> rbldnsd mailing list
> rbldnsd at corpit.ru
> http://www.corpit.ru/mailman/listinfo/rbldnsd

-- 

Steven F. Siirila			Office: Lind Hall, Room 130B
Internet Services			E-mail: sfs at umn.edu
Office of Information Technology	Voice: (612) 626-0244
University of Minnesota			Fax: (612) 626-7593