Mailing List Archive

On Fri, Jan 23, 2004 at 01:02:28PM +0100, Julian Mehnle wrote:
|
| Meng, could we have a new, official release of M:S:Q soon, please? I'm just waiting for that, then I'm going to set up logging on my mail server to gauge the effect SPF testing will have on my incoming mails.
|

I will put out a new release as soon as I can. I am on the campaign
trail right now. Maybe late tomorrow or Sunday.


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

On Fri, Jan 23, 2004 at 01:02:28PM +0100, Julian Mehnle wrote:
|
| Meng, could we have a new, official release of M:S:Q soon, please? I'm just waiting for that, then I'm going to set up logging on my mail server to gauge the effect SPF testing will have on my incoming mails.
|

I have uploaded the new version, 1.99.

It should be on CPAN soon.

Philip, is it backward compatible with existing invocation syntax?




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

----- Original Message -----
From: "Meng Weng Wong" <mengwong@dumbo.pobox.com>
To: <spf-devel@v2.listbox.com>
Sent: Saturday, January 24, 2004 2:57 AM
Subject: Re: [spf-devel] 1.98 released

> On Fri, Jan 16, 2004 at 08:18:28PM +0000, Mark wrote:
>
> > Ok, here it is, as promised, the new spf-milter 1.2. :)
> >
> > I took the "sendmail-milter" now bundled with SPF::Query 1.98, and made
> > substantial changes to it. This is now a merged version, which allows an
> > optional second parameter, "mx". When run in "mx" mode, it will call
> > SPF-Query and result2() from envrcpt_callback. In default mode, it will
> > call SPF-Query and result from envfrom_callback, as usual. When in MX
> > mode, it will show up in 'ps ax' as follows:
> >
> > "spf-milter [mx mode] (perl)"
>
> I have put this in as the new version. Thanks!

Thanks a lot! :)

Before you upload it to CPAN, though, I attached a small patch-file here (a
diff) to the version you bundled with 1.99. It adds an abort_callback to
deal with RSET properly.

If you are still interested, I will also write a small document on how to
use spf-milter (and supply some m4 stuff too). A lot of people install
Milters these days; so, it seems pretty straightforward. But a good doc
never hurts. :)

- 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

On Sat, Jan 24, 2004 at 03:21:39AM +0000, Mark wrote:
|
| Before you upload it to CPAN, though, I attached a small patch-file here (a
| diff) to the version you bundled with 1.99. It adds an abort_callback to
| deal with RSET properly.
|
| If you are still interested, I will also write a small document on how to
| use spf-milter (and supply some m4 stuff too). A lot of people install
| Milters these days; so, it seems pretty straightforward. But a good doc
| never hurts. :)
|

docs would be great. i'll put that patch into 1.991.

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

Yes, the patches that I provided make 1.99 compatible with the old-style
uses of 1.98. The result2() and message_result2() have returns that now
match result() -- by request of Meng.

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

* Integrated support for best_guess -- just set guess=>1 on the 'new'
method

* Integrated support for sanitizing the return data -- just set sanitize
on the 'new' method.

This last item is worth some discussion. It occurred to me that the data
that comes back in the smtp_comment and the header_comment is actually
under the control of the domain of the sender. As such it should be
treated with the utmost suspicion.

Consider what would happen if you managed to get a newline into one of
these fields. Would your MTA still work as expected. Note that getting a
newline into the smtp_comment is easy as that data comes from the exp=
field. I can't (currently) see how to get it into the header_comment,
but that is probably because I haven;t thought long enough. Note that
DNS names can include newlines. Actually, I now think that if I set my
DNS up so that my address: (say) 1.2.3.4 PTR stuff\nmore.my.domain and
the forward mapping is also present, then I can use the 'ptr' mechanism
to get the domain name into the header comment (I think).

The default sanitizer strips out all characters likely to be
troublesome. You can specify your own sanitizer. See the man page for
the gory details.

* There are also a bunch of bug fixes that shouldn't hurt anyone -- but
will make it interpret my personal SPF record correctly!

Enjoy

Philip

Meng Weng Wong wrote:

> On Fri, Jan 23, 2004 at 01:02:28PM +0100, Julian Mehnle wrote:
> |
> | Meng, could we have a new, official release of M:S:Q soon, please? I'm just waiting for that, then I'm going to set up logging on my mail server to gauge the effect SPF testing will have on my incoming mails.
> |
>
> I have uploaded the new version, 1.99.
>
> It should be on CPAN soon.
>
> Philip, is it backward compatible with existing invocation syntax?
>
>
>
>
> -------
> To unsubscribe, change your address, or temporarily deactivate your subscription,
> please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h
>
>

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

On Fri, Jan 23, 2004 at 10:35:56PM -0500, philip-spf@gladstonefamily.net wrote:
|
| * Integrated support for sanitizing the return data -- just set
| sanitize on the 'new' method.
|

Good thinking! In your next patch can you turn it on by default?

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

----- 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.

> This last item is worth some discussion. It occurred to me that the data
> that comes back in the smtp_comment and the header_comment is actually
> under the control of the domain of the sender. As such it should be
> treated with the utmost suspicion.
>
> Consider what would happen if you managed to get a newline into one of
> these fields. Would your MTA still work as expected?

Probably not. So you will be glad to learn that I already integrated that
suspicion in the very first spf-milter 1.1. :) That sanity filter looks like
this:

--------------------------------------------------------------------------
# Since $smtp_comment can be whatever is returned, we consider it highly
# tainted, and first run it through a 'garbage' filter, so as to clear it
# of weird characters, newlines, etc., that could potentially crash your
# mailer (possible exploits?).

($priv_data->{'spf_smtp_comment'} = $smtp_comment) =~
tr/\000-\010\012-\037\200-\377/ /s;
($priv_data->{'spf_header_comment'} = $header_comment) =~
tr/\000-\010\012-\037\200-\377/ /s;
--------------------------------------------------------------------------

Other MTA plugins should probably take similar precautions.

- 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

Meng, Philip, others,

Meng Weng Wong [mengwong@dumbo.pobox.com] wrote:
> I have uploaded the new version, 1.99.
>
> It should be on CPAN soon.
>
> Philip, is it backward compatible with existing invocation syntax?

philip-spf@gladstonefamily.net wrote:
> Yes, the patches that I provided make 1.99 compatible with the old-style
> uses of 1.98. The result2() and message_result2() have returns that now
> match result() -- by request of Meng.
>
> 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
>
> * Integrated support for best_guess -- just set guess=>1 on the 'new'
> method
>
> * Integrated support for sanitizing the return data -- just set sanitize
> on the 'new' method.
> [...]
>
> * There are also a bunch of bug fixes that shouldn't hurt anyone -- but
> will make it interpret my personal SPF record correctly!

Thanks guys for the excellent work!

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

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. Once SRS becomes widely deployed, it becomes less clear that
it is the right setting.

I've hacked on the qpsmtpd spf plugin, and I'm proposing that there is a
'trust 0' and a 'guess 0' option. This is to encourage people to
configure it correctly.

I think it certainly desirable to make it configurable, but make the
default the recommended option.

Philip

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

In <401320EF.70809@gladstonefamily.net> <philip-spf@gladstonefamily.net> writes:

> 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. Once SRS becomes widely deployed, it becomes less clear that
> it is the right setting.

I think that defaulting to using t-f.org is the right thing at this
time. Sometime in the future, the the right thing will be to default
to not using t-f.org. Further down the road, the right thing will be
to remove all support of t-f.org.


-wayne

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

----- 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

The 'everything matches' was only in one of my patches to 1.98. It
should be gone in 1.99.

If you still get a wacky answer, then let me know.

Philip

Mark wrote:

> 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:
>


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

----- Original Message -----
From: <philip-spf@gladstonefamily.net>
To: <spf-devel@v2.listbox.com>
Sent: Sunday, January 25, 2004 8:58 PM
Subject: Re: [spf-devel] New Mail::SPF::Query release -- some details


> The 'everything matches' was only in one of my patches to 1.98.
> It should be gone in 1.99.

My mistake, Philip. My apologies. I thought the patched version of 1.98 was
the same one bundled with 1.99. Everything is working again.

Which means, that with my latest Milter patch to 1.99, there are currently
no outstanding issues any more that need immediate attention. We got the
secondaries integrated now, the trusted-forwarders, and pretty much
everything else. :)

- 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