RE: socketmapd.0.31.pl file system location

Mark, thank you very much. This will help tremendously, of course. See 
below, please, for more.

On Mon, 19 Dec 2005, Mark wrote:

>
>> -----Original Message-----
>> From: Robert Muchnick [mailto:[email protected]]
>> Sent: maandag 19 december 2005 1:00
>> To: [email protected]
>> Subject: [srs-discuss] socketmapd.0.31.pl file system location
>>
>> Sorry if this is a stupid question, but I'm brand new to this list and
>> to SRS. I'm trying to install the latest stable socketmap method but the
>> tarball has no detail files whatsoever and unfortunately sendmailsrs.htm
>> isn't helping either.

<< snipped >>

>> Can anyone shed some light on these issues?
>
> Yes, I can; as I wrote the srs socketmapd. :)
>
> For starters, you can run socketmapd.0.31.pl from any location, as
> communication takes place via a UNIX domain socket (so the place to put
> socketmapd.0.31.pl is immaterial).

In the spirit of Open Source software, wouldn't this be material to put 
into a README or INSTALL file in the tarball?

> You do not need perlsrs.m4, envfrom2srs.pl, or srs2envtol.pl. These are
> only for the (obsoleted) program map support.

Seems to me, to keep the confusion factor down -- especially since this 
has to be integrated with SPF in any event, for fully functional 
production servers, which I'm trying to run -- that that should be stated 
CLEARLY upfront in sendmailsrs.htm.

> The only thing you [need], next to
> socketmapd.0.31.pl itself, of course, is socketmap.m4 (to be placed as
> 'hack' in you .mc file, so its settings become part of your sendmail.cf.)

This is a very important piece of information, since Sendmail is a VERY 
complex program! Especially in a production environment. As a sys admin, I 
am trying to make or keep efficient every process related to web service. 
Perhaps this information should also be in an updated sendmailsrs.htm? Or 
better yet, an INSTALL or README file included with the tarball?

> Then you can just start socketmapd.0.31.pl (from any location), and
> presto, you are doing SRS. :)

As in an entry in a startup file such as /etc/rc.d/rc.local? Another 
suggestion that would help loads of people adopt the SPF/SRS protocol.

I am 1,000% behind SPF/SRS -- I've published SPF records for almost a year 
and have implemented SPF fully for several months -- but I gotta tell you, 
the lack of a coherent, comprehensive EXPLANATION of how this all fits 
together is really, IMO, retarding its universal adoption -- especially a 
clear, unmistakeable statement that SPF without sender rewriting kills 
forwarding! This has caused me personally huge problems.

I can implement the most complex software in the world in a matter of 
hours. I spent many hours Sunday afternoon and still couldn't be sure 
about where all the files in your latest tarball fit into the scheme of 
things, only to find out three of them were obsolete and unnecessary. This 
isn't right, nor in the spirit of Open Source.

> - Mark
>
>        System Administrator Asarian-host.org
>
> ---
> "If you were supposed to understand it,
> we wouldn't call it code." - FedEx

Not really. Open Source is about replacing stupid, broken, bloated and 
utterly useless code that doesn't work (translation: Microsnot, aka 
Microshit) with good, understandable and improveable code. There's a 
reason virtually all Open Source comes with README and INSTALL files. If 
you need some help with that, how about writing me off-list?

Robert Muchnick
Xenterra.net
720-276-7917