The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Tuesday, September 25, 2007

Abstraction for its own sake

This is a rather small and unfocused rant on unnecessary abstractions. It may be related to this wiki page on abstraction not scaling; it may not be (told you this was unfocused).

I'm in the process of writing the Sendmail interface for the greylist daemon, and as far as that goes, it's very simple for this application—it just requires the writing of four functions, one that's given the IP address of the remote SMTP server, one that's given the sender email address, one that's given the recipient email address, and one to clean up any resources allocated from the other functions.

Like I said, pretty easy and straightforward.

The oddness comes in the first function's definition. It's:

sfsistat xxfi_connect(SMFICTX *ctx,char *hostname,_SOCK_ADDR *hostaddr);

The _SOCK_ADDR variable contains the IP address of the remote SMTP server. What is it? I dunno. What does it contain? I dunno. All I care about is the actual IP address, and I presume it's somewhere in this variable (most likely a structure of some kind). But there's no further API for pulling any useful information out of this _SOCK_ADDR.

Well, let's dive into the header files:

#ifndef _SOCK_ADDR
# define _SOCK_ADDR     struct sockaddr
#endif /* ! _SOCK_ADDR */ 

For some reason, the writers of Sendmail felt it prudent to hide the definition of the IP address behind another name. Presumably to make their code more portable to other non-BSD-derived network stacks that don't use struct sockaddr to store IP addresses.

But that does my code no good. I don't care about the hostname, I care about the IP address, yet without further information, I don't know exactly what I have. Is it the binary form of the address? How big? (there's IPv4, in which each address is 32 bits long, and IPv6, in which each address is 128 bits long) I had to dive into the header files to find out what exactly I'm given.

And it's not like the above definition of _SOCK_ADDR is wrapped around other #ifdef's checking for various operating systems or network stacks. The above definition is it! That's all there is.

So I really have to wonder why they felt this further abstraction for their code was necessary. It seems to be abstraction for abstraction's sake. Here's a hint: you aren't going to need it.


Reason #98,333,323 why I hate control panels

[The following is a trouble ticket submitted by me into the Company Internal Trouble Ticket Queue System™. It should be of no real surprise to anyone here, but it still makes for decent blog fodder.]

I have the graylist sendmail module written, so I go to install it for the XXXXXXXXXXXXX domain. The initial module does nothing but log the requests and let the email through—I did the same for the postfix module to ensure that the module worked before hooking it up to the greylist daemon.

Anyway, I'm going to install the sendmail module for XXXXXXXXXXXXX. XXXXXXXXXXXXX is on XXXXXXXXXXXXXXXXXX, which is a box managed by Insipid. Now, the instructions for installing the sendmail module are easy—just modify /etc/mail/sendmail.mc with the following lines:

define(`_FFR_MILTER', `1')dnl.
INPUT_MAIL_FILTER(`filter1', `S=unix:/tmp/milter')

And run make in /etc/mail to generate the new sendmail.cf file. Fortunately for us, I made a backup copy of both the sendmail.cf and sendmail.mc files. So I do thusly. And then I compare the new sendmail.cf file with the one supplied by Insipid.

[root@XXXXXX ~]# cd /etc/mail
[root@XXXXXX mail]# diff -y sendmail.cf sendmail.cf.milter

(if you run that, make sure your terminal window is W I D E, since it shows both versions side-by-side)

Lots o' differences.

And while I can merge the two, will an upgrade of Insipid break sendmail.cf? What about our warranty? Or are we forever doomed to manually patch the sendmail.cf file?

Obligatory Picture

Trying to get into the festive mood this year

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

Obligatory AI Disclaimer

No AI was used in the making of this site, unless otherwise noted.

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.