----- Original Message -----
From: <philip-spf@gladstonefamily.net>
To: <spf-devel@v2.listbox.com>
Sent: Sunday, January 25, 2004 2:50 AM
Subject: Re: [spf-devel] New Mail::SPF::Query release -- some details
> Mark wrote:
>
> > ----- Original Message -----
> > From: <philip-spf@gladstonefamily.net>
> > To: <spf-devel@v2.listbox.com>
> > Sent: Saturday, January 24, 2004 4:36 AM
> > Subject: Re: [spf-devel] New Mail::SPF::Query release -- some details
> >
> >> The other key additions to 1.99 (as I see it):
> >>
> >> * Integrated support for spf.t-f.org -- just set trusted=>1 on the new
> >> method
> >
> > I briefly toyed with the idea of adding "trusted => 1", as default, to
> > the spf-milter result() and result2() calls; but it seemed a bit
> > presumptuous, on my part, to overide people's personal choices in such
> > fashion.
>
> The reason that I added the trusted=>1 was to make it easy for MTA
> integrators to add the t-f.org processing. My feeling is that (for now
> at least), we want it enabled, otherwise we will drop perfectly valid
> messages.
The people have spoken. :)
I attached a new patch (against sendmail-milter bundled with
Mail::SPF::Query 1.99), which includes the following updates:
* Per default, spf-milter now queries trusted-fowarder.org (on 'fail' only),
to check whether the trusted-fowarder domain yields a 'pass' after all. And
I added a new parameter, "dt" (disable trust), to override the default
behavior.
* In case of a valid MAIL FROM: <>, SPF::Query checks against the HELO
string, with 'postmaster' as localpart, but will leave an empty
$priv_data->{'from'} variable (which, for instance, shows up in
$header_comment as a double space after "domain of"). I compensated for
that. But, eventually, this should probably be done within SPF::Query
itself.
* Our own hostname, extracted from the j macro, does not need to be grabbed
on each connection. It is now a global variable, set only once, and has been
taken out of the per-connection hash.
* 'spf_smtp_comment' remains a bit problematic. For instance, when I test
for a fail (on one of my own domains), all 'spf_smtp_comment' returns is:
"everything matches". The debug-log shows that a proper 'spf_smtp_comment'
was being prepared, though:
-----------------------
macro_substitute:
http://spf.pobox.com/why.html?sender=%{S}&ip=%{I}&receiver=asarian-host.net ->
http://spf.pobox.com/why.html?sender=admin%40asarian-host.net&ip=209.6.17.217&receiver=asarian-host.net -----------------------
I expected this 'why' URL to surface; but what 'spf_smtp_comment' returns
is: "everything matches". I was tempted to output 'spf_header_comment' in
our reject responses, instead. But I think the best solution is just to fix
the 'spf_smtp_comment' issue.
* The extra abort_callback, to deal with RSET properly, is included in this
patch.
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to
http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h