Mailing List Archive

On Sun, 2004-01-25 at 15:07, Phil Howard wrote:
> I was reading the concern about package maintainers regarding adding SPF
> capability in MTA packages (where the original source does not do so).
> Thinking about this, I can see where many people would not want to have
> this enabled "by surprise" (and least not until it is universally in use).
>
> What I was think that could be done is to have a centrally administered
> flag that would apply to SPF libraries running under MTAs to enable SPF
> or leave it disabled (so as to function as if SPF were not deployed).
> That might be the existance of a file "/etc/spf-enabled-in-mta" that the
> library could stat() to see if it should proceed. If the file exists,
> do the SPF thing. If it does not exist, behave as if there is no SPF,
> which I guess would be like "?all". SPF command line tools would not be
> affected, other than to mention:
>
> File "/etc/spf-enabled-in-mta" not found, so SPF is not active in your MTA.
>
> Compile-time options could rename the file or disable this feature.
>
> Being more of a system administrator than a programmer (despite 31 years
> experience programming, of which 21 is in C and 17 on Unix), I tend to
> think in terms of sysadmin flexibility, and like to have "control knobs"
> like this. My still-being-written DNS server will have stuff like this
> in it.

Thats a tough issue to deal with Phil. While the "by surprise" can be
irritating, just as irritating are the number of trolls who say the
exact opposite, who bitch that its NOT active. Its a two edged sword of
stupidity if you ask me... I can see it now, people compiling or
installing packages, IGNORING the manual like most of them do, and
freaking out because they didn't know they had to set some flag in a
file, or even create that file in /etc or wherever..

People shouldn't being installing software such as an MTA as a package.
People should be required to know wtf they are doing before they turn
something on, and quite frankly, if they are too ignorant to read the
bloody manual before turning on something such as an MTA, then they
deserve whatever it is that they get. If you manage to get DNS setup,
with proper MX records, then suffice to say you should be capable of
reading the manual or howto for whatever MTA you implement, and so this
could also be said of whatever SPF implementation is used... Quite
frankly, how hard is ./configure --with-spf or --enable-spf anyway?

Cheers,

James

--
James Couzens,
Programmer

Current projects:
http://libspf.org

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ï#ÄÏÉæGã!'Rzš´ˆ»£‡Æ~3com

In <1075072957.11549.27.camel@code3> James Couzens <jcouzens@obscurity.org> writes:

> Quite frankly, how hard is ./configure --with-spf or --enable-spf anyway?

Much harder than changing a config file.

I think all SPF support for MTAs should be able to have config file
options that support at least disabled, create Received-SPF: headers
only, and full-filtering.

I could see a lot of sysadmins that would want to start out only
creating Received-SPF headers until such time as they feel comfortable
with the results. I could also see sysadmins wanting to be able to
*VERY* quickly scale back from full-filtering to headers only if they
detect a problem.



-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

> > Quite frankly, how hard is ./configure --with-spf or --enable-spf anyway?
> Much harder than changing a config file.

I disagree, you can fuck up a config file just as easily as you can ./configure.
I see little difference conceptually or otherwise between them. I just don't
see the need go there. As Microsoft has clearly demonstrated, you do not put
powerful tools in the hands of complete imbeciles, or all hell breaks loose.
I think there should be some "breaking point" where "I'm sorry you are too
lazy/stupid/ignorant to use this software, RTFM!!!" appears on the screen. And
that isn't the BOFH in me talking either, I genuinely believe there should be
some requirement here, or else this could backfire.

> I think all SPF support for MTAs should be able to have config file
> options that support at least disabled, create Received-SPF: headers
> only, and full-filtering.

I thought we spoke about this today Wayne, I don't think we want people
fudging the headers putting whatever they want in place of the compliant
Received-SPF: header. Otherwise third party parsing programs aren't
going to know what to expect and we all know how much fun dynamic
content is.

Unless by 'create Received-SPF: headers' you mean:

spf_apply_headers=1

> I could see a lot of sysadmins that would want to start out only
> creating Received-SPF headers until such time as they feel comfortable
> with the results. I could also see sysadmins wanting to be able to
> *VERY* quickly scale back from full-filtering to headers only if they
> detect a problem.

I just don't know how much of a good idea this is.. if we give it TOO
much flexibility perhaps it will never be put in place properly.. on the
other hand if there isn't enough people may be afraid to use it. I just
know how the majority of admins really have little knowledge as is quite
evident for example through how long these code-red, nimda, and other
worms remain prevalent. Such admins may just put it up without ever
configuring it properly. If its just cut and dry, as in, if its SPF
result is FAIL and the email gets dropped/bounced, then thats pretty
hard to fuck up. I suppose with well defined defaults it would be ok...
I dunno feel free to explore this issue more with me, I'd like to know
more of your take on this.

James

--
James Couzens,
Programmer

Current projects:
http://libspf.org

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ï#ÄÏÉæGã!'Rzš´ˆ»£‡Æ~3com

begin Monday 26 January 2004 02:05, James Couzens quote:
> > > Quite frankly, how hard is ./configure --with-spf or --enable-spf
> > > anyway?
> >
> > Much harder than changing a config file.
>
> I disagree, you can fuck up a config file just as easily as you can
> ./configure.

While it's correct that it's as easy to f'up a config file than a
compilation setting, nowadays most admins install there boxen from
RPMs (or debs, or whatever), rather than compiling their MTA
themselves. If it takes a recompilation to enable/disable SPF, most
won't bother. If it is a config time setting, it is much more
accessible to the common sysadmin. Thus, being able to switch SPF
on/off at runtime is definately an advantage.

Alain

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

> While it's correct that it's as easy to f'up a config file than a
> compilation setting, nowadays most admins install there boxen from
> RPMs (or debs, or whatever), rather than compiling their MTA
> themselves. If it takes a recompilation to enable/disable SPF, most
> won't bother. If it is a config time setting, it is much more
> accessible to the common sysadmin. Thus, being able to switch SPF
> on/off at runtime is definately an advantage.

You can, by doing it through the MTA that you are working with. For
example (although this is not currently done yet, the framework is
there) with libspf in qmail, you would edit /var/qmail/controls/spf file
perhaps, which would dictate its status, and this goes with any other
MTA in their own given format.

Now, turning SPF on and off is one thing, I think I'm more passionate
about the more internal goings on of SPF here, and this configuration
file being something global and ending up in /etc. I don't really feel
thats appropriate. Were we talking about 'spfd', then yes, thats a
program, not a library. To the best of my knowledge, libraries don't
have configuration files... the configuration of said libraries is
handled through the application that makes use of them, in this case the
MTA.

Cheers,

James
--
James Couzens,
Programmer

Current projects:
http://libspf.org

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ï#ÄÏÉæGã!'Rzš´ˆ»£‡Æ~3com

begin Monday 26 January 2004 11:20, James Couzens quote:
> To the best of my knowledge, libraries don't
> have configuration files...

Not true. Some libraries do have configuration files:

The resolver library (host name lookups) uses /etc/resolv.conf and
/etc/hosts

User lookup (NIS, winbind, ...) is configured in /etc/nsswitch.conf,
also used by a library. Same thing goes with PAM, which is also a
library.

The DB library uses a DB_CONFIG file (AFAIK, located in the same
directory as the .db file being opened)

For your education, run a "strings -a *.so | fgrep /etc" in /lib for
more examples.

As you see, there is plenty of precedent of libraries using
configuration files, without the application being aware of them.

Regards,

Alain

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

> Not true. Some libraries do have configuration files:

I stand corrected.

> The resolver library (host name lookups) uses /etc/resolv.conf and
> /etc/hosts
>
> User lookup (NIS, winbind, ...) is configured in /etc/nsswitch.conf,
> also used by a library. Same thing goes with PAM, which is also a
> library.
>
> The DB library uses a DB_CONFIG file (AFAIK, located in the same
> directory as the .db file being opened)
>
> For your education, run a "strings -a *.so | fgrep /etc" in /lib for
> more examples.
>
> As you see, there is plenty of precedent of libraries using
> configuration files, without the application being aware of them.

As I previously stated, I don't feel we should be sticking config files
in /etc. This is not a global library like a resolver. This is MTA
specific, and its configuration files should be where the MTA has its
configuration files, or within the MTA's configuration file. IMHO,
putting it anywhere else is just bad form, and plain messy.

Cheers,

James
--
James Couzens,
Programmer

Current projects:
http://libspf.org

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ï#ÄÏÉæGã!'Rzš´ˆ»£‡Æ~3com

begin Monday 26 January 2004 12:23, James Couzens quote:
> As I previously stated, I don't feel we should be sticking config files
> in /etc. This is not a global library like a resolver. This is MTA
> specific, and its configuration files should be where the MTA has its
> configuration files, or within the MTA's configuration file. IMHO,
> putting it anywhere else is just bad form, and plain messy.

We could put the config file into the /etc/mail/ directory instead, or
/etc/sysconfig/spf or whatever.

IMHO, it's not so important where it is stored, but that it is
possible to configure this thing at all, without needing to recompile
the MTA.

Alain

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

> We could put the config file into the /etc/mail/ directory instead, or
> /etc/sysconfig/spf or whatever.
>
> IMHO, it's not so important where it is stored, but that it is
> possible to configure this thing at all, without needing to recompile
> the MTA.

I think you are missing my point here. If its spfd, then its a
standalone application, and something like /etc/mail is then
appropriate, but as a library being installed who's calls are only going
to be made by the MTA, its configuration files should be wherever the
MTA's configuration files are.

I think this issue has gone way off track. I'll leave it like this,
libspf can configured from the appropriate place, which will for Qmail
happen to be /var/qmail/control/spf for example. This is not only
logical, but common practise.

Cheers,

James

--
James Couzens,
Programmer

Current projects:
http://libspf.org

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ï#ÄÏÉæGã!'Rzš´ˆ»£‡Æ~3com

In <1075079126.11700.87.camel@code3> James Couzens <jcouzens@obscurity.org> writes:

>> > Quite frankly, how hard is ./configure --with-spf or --enable-spf anyway?
>> Much harder than changing a config file.
>
> I disagree, you can fuck up a config file just as easily as you can ./configure.

The point is that in order to do a compile, you must make sure that
you have all the correct source, all the correct libraries, that the
libraries haven't changed since the last time you installed the MTA
into production, that the new compile passes regression tests, etc.


>> I think all SPF support for MTAs should be able to have config file
>> options that support at least disabled, create Received-SPF: headers
>> only, and full-filtering.
>
> Unless by 'create Received-SPF: headers' you mean:
>
> spf_apply_headers=1

I guess I wasn't very clear. I wasn't mentioning three different
options for SPF, but rather one SPF option that can be in three
different states.

Also, as I said, this option should be in the MTA config. There
shouldn't be a global config file for libspf. Heck, I'm not sure that
libspf needs to even know about the option, it is the MTA support that
will decide to do all the work.


-wayne



-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

On Mon, Jan 26, 2004 at 03:23:06AM -0800, James Couzens wrote:

| As I previously stated, I don't feel we should be sticking config files
| in /etc. This is not a global library like a resolver. This is MTA
| specific, and its configuration files should be where the MTA has its
| configuration files, or within the MTA's configuration file. IMHO,
| putting it anywhere else is just bad form, and plain messy.

In principle I agree. But making the library know where to look is the
hard part. You don't know where that would be at code time.

BTW, I have a better idea for the file name :-)

/etc/spf-will-not-work-for-those-who-do-not-read-the-manual

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

> In principle I agree. But making the library know where to look is the
> hard part. You don't know where that would be at code time.
>
> BTW, I have a better idea for the file name :-)
>
> /etc/spf-will-not-work-for-those-who-do-not-read-the-manual

phil++;

lol

--
James Couzens,
Programmer

Current projects:
http://libspf.org

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ï#ÄÏÉæGã!'Rzš´ˆ»£‡Æ~3com