Mailing List Archive: Polishing Mail::SPF::Query

Polishing Mail::SPF::Query

julian at mehnle

Nov 28, 2005, 5:11 PM

Post #1 of 27 (9248 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[.Please follow up to spf-devel unless you want to discuss related but
non-devel issues.]

Hi all,

Meng sent me his Mail::SPF::Query CVS repository. I turned it into a
Subversion repo[1,2] and imported all the past M:S:Q releases from
CPAN[3].

Now that this has been done, we can start polishing M:S:Q. I think there
should be at least one more release, 1.998, and possibly a final 1.999.
After that, Mail::SPF[4] should take over in M:S:Q's place.

So the current M:S:Q trunk[5,6] is where we can pick up Meng's work. I
have already made some changes from 1.997 (rev 107:110):

trunk/Query.pm
* `local`ized $@ when `eval`ing to satisfy SpamAssassin (closes Debian
bugs #332952, #337319, #337500).
* Minor updates to POD docs.

trunk/spfd
* Pass "trusted" and "local" arguments to Mail::SPF::Query.

trunk/spfquery
* Exit with code 0 and don't print usage hint on '-v' (closes Debian bug
#237751).

trunk/README
* Updated version, result codes descriptions, copyright, etc.

trunk/Changes
* Renamed to "CHANGES" for consistency with other doc files.
* Cleaned up.

If you know of any serious-impact or easy-to-fix bugs, please post them to
spf-devel soon! Patches are especially welcome.

Julian.

References:
1. http://www.openspf.org/svn/mail-spf-query-perl
2. http://www.openspf.org/source/mail-spf-query-perl
3. http://search.cpan.org/dist/Mail-SPF-Query
4. http://search.cpan.org/dist/Mail-SPF
5. http://www.openspf.org/svn/mail-spf-query-perl/trunk
6. http://www.openspf.org/source/mail-spf-query-perl/trunk
7. http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libmail-spf-query-perl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDi6rNwL7PKlBZWjsRAm2qAKCy/8wJBfmUjbnH3+WIz8Egj7UuSQCfdETY
Xr8rQO+dt3bpID/ilu/RkBE=
=4kvS
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Polishing Mail::SPF::Query [ In reply to ]

spf2 at kitterman

Nov 28, 2005, 5:16 PM

Post #2 of 27 (9162 views)

On 11/28/2005 20:11, Julian Mehnle wrote:
> [.Please follow up to spf-devel unless you want to discuss related but
> non-devel issues.]
>
> Hi all,
>
> Meng sent me his Mail::SPF::Query CVS repository. I turned it into a
> Subversion repo[1,2] and imported all the past M:S:Q releases from
> CPAN[3].
>
> Now that this has been done, we can start polishing M:S:Q. I think there
> should be at least one more release, 1.998, and possibly a final 1.999.
> After that, Mail::SPF[4] should take over in M:S:Q's place.
>
> So the current M:S:Q trunk[5,6] is where we can pick up Meng's work. I
> have already made some changes from 1.997 (rev 107:110):
>
> trunk/Query.pm
> * `local`ized $@ when `eval`ing to satisfy SpamAssassin (closes Debian
> bugs #332952, #337319, #337500).
> * Minor updates to POD docs.
>
> trunk/spfd
> * Pass "trusted" and "local" arguments to Mail::SPF::Query.
>
> trunk/spfquery
> * Exit with code 0 and don't print usage hint on '-v' (closes Debian bug
> #237751).
>
> trunk/README
> * Updated version, result codes descriptions, copyright, etc.
>
> trunk/Changes
> * Renamed to "CHANGES" for consistency with other doc files.
> * Cleaned up.
>
> If you know of any serious-impact or easy-to-fix bugs, please post them to
> spf-devel soon! Patches are especially welcome.
>
> Julian.
>
> References:
> 1. http://www.openspf.org/svn/mail-spf-query-perl
> 2. http://www.openspf.org/source/mail-spf-query-perl
> 3. http://search.cpan.org/dist/Mail-SPF-Query
> 4. http://search.cpan.org/dist/Mail-SPF
> 5. http://www.openspf.org/svn/mail-spf-query-perl/trunk
> 6. http://www.openspf.org/source/mail-spf-query-perl/trunk
> 7. http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libmail-spf-query-perl
>
Are you going to bring in Craig Whitmore's updates too?

http://www.gossamer-threads.com/lists/spf/discuss/24938

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Polishing Mail::SPF::Query [ In reply to ]

lennon at orcon

Nov 28, 2005, 5:42 PM

Post #3 of 27 (9134 views)

Most of my updates are due to it parsing SPF records incorrectly (passing
when should be permerror etc)

Thanks
Craig

>>
> Are you going to bring in Craig Whitmore's updates too?
>
> http://www.gossamer-threads.com/lists/spf/discuss/24938
>
> Scott K
>
> -------
> To unsubscribe, change your address, or temporarily deactivate your
> subscription,
> please go to
> http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
>

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Polishing Mail::SPF::Query [ In reply to ]

julian at mehnle

Nov 29, 2005, 3:47 AM

Post #4 of 27 (9172 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[.Please follow up to spf-devel unless you want to discuss related but
non-devel issues.]

Arjen de Korte wrote:
> > If you know of any serious-impact or easy-to-fix bugs, please post
> > them to spf-devel soon! Patches are especially welcome.
>
> Changing the location the $DEFAULT_EXPLANATION should be an easy fix:
>
> - my $DEFAULT_EXPLANATION = "Please see
> http://spf.pobox.com/why.html?sender=%{S}&ip=%{I}&receiver=%{xR}";
> + my $DEFAULT_EXPLANATION = "Please see
> http://www.openspf.org/why.html?sender=%{S}&ip=%{I}&receiver=%{xR}";

Excellent suggestion, thanks. (Of course it won't help us with the
thousands of old installations of M:S:Q out there that still use "spf.
pobox.com", though.)

> In my opinion the CallerID code is obsolete, so this could be removed
> from the code.

No, I think this is a legacy feature that needs to stay in M:S:Q forever so
as not to break existing installations that are going to be upgraded.
There are tons of things that we would like to change, add, or remove in
M:S:Q, but most of that can't be done without risking breaking existing
installations.

Put your hope in Mail::SPF instead. :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDjD/lwL7PKlBZWjsRAhfQAJsEwIIn0qx6T4KdIllIawX3OORbNQCghroI
4a6IqmOMDT0NzldjJk0c7AA=
=PsHk
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Polishing Mail::SPF::Query [ In reply to ]

julian at mehnle

Nov 29, 2005, 4:41 AM

Post #5 of 27 (9129 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Kitterman wrote:
> Arjen de Korte wrote:
> > In my opinion the CallerID code is obsolete, so this could be removed
> > from the code.
>
> Stuart and I removed the equivalent code from pySPF over the summer for
> that reason.

Hmm, and did you get any complaints about the removed "feature"?

I guess the real question is, what would removing C-ID support from the
next (and probably last, forever) release of M:S:Q _gain_ us, or anyone
else for that matter?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDjExlwL7PKlBZWjsRAs06AJ0f6yzwWbMhkrhCLO3Ps/4IYiWDoACgousK
/IZD2LDAaoZXyraEpoRCvVA=
=OtDR
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Polishing Mail::SPF::Query [ In reply to ]

julian at mehnle

Nov 29, 2005, 5:06 AM

Post #6 of 27 (9160 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Kitterman wrote:
> Julian Mehnle wrote:
> > I guess the real question is, what would removing C-ID support from
> > the next (and probably last, forever) release of M:S:Q _gain_ us, or
> > anyone else for that matter?
>
> No. Since I don't know of any more C-ID records, there doesn't seem to
> be much to break. In my view obsolete cruft should be excised.

Hmm. I'll look at how easily C-ID support can be removed.

The issue is, if this is to be the very last release of M:S:Q, we MUST NOT
fuck it up. Thus non-trivial changes should be considered thoroughly.

> OTOH, if we are in fact at the end of M:S:Q, then it's not such a big
> deal. How close is the new reference to being done?

In theory, Mail::SPF should already work. It doesn't have any
documentation yet, though, and it hasn't been tested thoroughly. Last but
not least, the API is entirely different, so existing installations of
Mail::SPF::Query aren't going to be replaced by Mail::SPF anytime soon in
_any_ case. (I could imagine including a wrapper class in the Mail-SPF
package, though.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDjFJQwL7PKlBZWjsRAryUAKDzFaKBprBzne5XX/BsRQi2qCJoJwCgvFte
Jhi51Z5yuFXMX9rk+G8U68Q=
=XXQp
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Re: Polishing Mail::SPF::Query [ In reply to ]

wayne at schlitt

Nov 29, 2005, 5:39 AM

Post #7 of 27 (9120 views)

In <200511291306.24383.julian@mehnle.net> Julian Mehnle <julian@mehnle.net> writes:

> Scott Kitterman wrote:
>> Julian Mehnle wrote:
>> > I guess the real question is, what would removing C-ID support from
>> > the next (and probably last, forever) release of M:S:Q _gain_ us, or
>> > anyone else for that matter?
>>
>> No. Since I don't know of any more C-ID records, there doesn't seem to
>> be much to break. In my view obsolete cruft should be excised.
>
> Hmm. I'll look at how easily C-ID support can be removed.
>
> The issue is, if this is to be the very last release of M:S:Q, we MUST NOT
> fuck it up. Thus non-trivial changes should be considered thoroughly.

I think that the C-ID abuse should be removed.

As pointed out above, you aren't going to break much since there
aren't many C-ID records.

In my opinion, and why I never added it to libspf2, is that the abuse
of C-ID records, which are designed for the 2822.From: context, for
the 2821.MAILFROM context doesn't sound like a good idea to me.

I can't recall ever seeing a request for C-ID re-use for libspf2.

-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Polishing Mail::SPF::Query [ In reply to ]

julian at mehnle

Nov 29, 2005, 6:37 AM

Post #8 of 27 (9149 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arjen de Korte wrote:
> The CallerID feature in Mail::SPF::Query was implemented as a fallback
> mechanism in case a domain had not published an SPF record. This was
> only done if the domain was either (*.)microsoft.com or (*.)hotmail.com.
> Since both Microsoft and Hotmail publish an SPF record, the CallerID
> records will no longer be used by Mail::SPF::Query.
>
> As a side note, Hotmail has effectively pulled its '_ep.hotmail.com'
> record (it references non-existing records), so that leaves only the
> Microsoft CallerID record to query (although I doubt it is still being
> maintained now that they have officially moved to SenderID).
>
> We (the SPF crowd) argue that SenderID is abusing SPF records. Yet at
> our turn we also abuse CallerID records for SPF checks. And since there
> no longer is anything to gain with supporting this ancient code, why not
> remove it. CallerID (and SenderID) are not SPF and as such don't belong
> in a reference implementation.

Note that Mail::SPF::Query hasn't just been playing the role as the
reference implementation, historically it has also been the first SPF
implementation overall and sort of a testbed for experimentation, as can
be seen from M:S:Q's history (browse the Svn repository[1] if you're
interested). M:S:Q being in relatively wide deployment, we can't just
start treating it as if it were nothing but a reference implementation, as
much as we might wish to do so.

But of course all the other arguments of yours hit very good points, so I
guess we can safely remove Caller-ID support. (I was just being a bit
wary, but that was probably too conservative.)

References:
1. http://www.openspf.org/source/mail-spf-query-perl/trunk/Query.pm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDjGeqwL7PKlBZWjsRAlwxAJ9F5OMFUR//5fWd6Yz1CG5iJM+rDQCgtOB3
iQYTcUUn1LxOb2wA3kLLeBw=
=uXnA
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Polishing Mail::SPF::Query [ In reply to ]

julian at mehnle

Nov 29, 2005, 4:44 PM

Post #9 of 27 (9161 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arjen de Korte <arjen@de-korte.org> wrote:
> Julian,
>
> Find attached a unified diff which will
>
> 1) Replace all instances of 'spf.pobox.com' with 'www.openspf.org'.
> 2) Removes all (?) CallerID code.
>
> I used revision 109 from the repository.

Excellent, thank you!

As far as I can see, you got all of the C-ID stuff. I applied your patch
and some additional changes:

http://www.openspf.org/source/mail-spf-query-perl?rev=111&view=rev

I'll wait a few more days before releasing 1.998 to CPAN and to the
website, just in case some additional issues crop up.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDjPXfwL7PKlBZWjsRAtnvAJkBQXKgHfV111++Qzv/fM8MJGWhQwCdGuMv
sRmt+8N+Bsj2Qbd/yUQeDMM=
=yl1Z
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Re: Polishing Mail::SPF::Query [ In reply to ]

spf2 at kitterman

Nov 29, 2005, 7:27 PM

Post #10 of 27 (9129 views)

On 11/29/2005 19:44, Julian Mehnle wrote:
> Arjen de Korte <arjen@de-korte.org> wrote:
> > Julian,
> >
> > Find attached a unified diff which will
> >
> > 1) Replace all instances of 'spf.pobox.com' with 'www.openspf.org'.
> > 2) Removes all (?) CallerID code.
> >
> > I used revision 109 from the repository.
>
> Excellent, thank you!
>
> As far as I can see, you got all of the C-ID stuff. I applied your patch
> and some additional changes:
>
> http://www.openspf.org/source/mail-spf-query-perl?rev=111&view=rev
>
> I'll wait a few more days before releasing 1.998 to CPAN and to the
> website, just in case some additional issues crop up.
>
Craig Whitmore put a lot of effort into his updates (and IIRC they were the
reason you asked Meng for CPAN access in the first place) in order to make
sure M:S:Q matched the current internet draft ABNF for what was and was not a
valid record. We worked through a lot of scenarios to see that both M:S:Q
and pySPF were correct in this regard over the summer.

There was a period where there were more visits from NZ than everywhere else
combined to my validator because he was running tests against both libraries
to be sure.

I would like to strongly encourage you to include those changes in an upcoming
M:S:Q release. If not this one (I can understand wanting to keep your first
one modest), then one soon after. His changes significantly improve the
correctness of M:S:Q significantly WRT the current ABNF.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Re: Polishing Mail::SPF::Query [ In reply to ]

lennon at orcon

Nov 29, 2005, 9:04 PM

Post #11 of 27 (9161 views)

My Changes included (not not limited to)

Checking for a: with numbers
Check for more than 10 DNS Queries
Checking for anything after all
Checking for mx with a valud FQDN
Checking for valid ip4:
Check for people trying to use v=spf2.0/mfrom spf2.0/pra (not really
needed)

----- Original Message -----
From: <spf2@kitterman.com>
To: <spf-devel@v2.listbox.com>
Sent: Wednesday, November 30, 2005 4:27 PM
Subject: Re: [spf-devel] Re: Polishing Mail::SPF::Query

> On 11/29/2005 19:44, Julian Mehnle wrote:
>> Arjen de Korte <arjen@de-korte.org> wrote:
>> > Julian,
>> >
>> > Find attached a unified diff which will
>> >
>> > 1) Replace all instances of 'spf.pobox.com' with 'www.openspf.org'.
>> > 2) Removes all (?) CallerID code.
>> >
>> > I used revision 109 from the repository.
>>
>> Excellent, thank you!
>>
>> As far as I can see, you got all of the C-ID stuff. I applied your patch
>> and some additional changes:
>>
>> http://www.openspf.org/source/mail-spf-query-perl?rev=111&view=rev
>>
>> I'll wait a few more days before releasing 1.998 to CPAN and to the
>> website, just in case some additional issues crop up.
>>
> Craig Whitmore put a lot of effort into his updates (and IIRC they were
> the
> reason you asked Meng for CPAN access in the first place) in order to make
> sure M:S:Q matched the current internet draft ABNF for what was and was
> not a
> valid record. We worked through a lot of scenarios to see that both M:S:Q
> and pySPF were correct in this regard over the summer.
>
> There was a period where there were more visits from NZ than everywhere
> else
> combined to my validator because he was running tests against both
> libraries
> to be sure.
>
> I would like to strongly encourage you to include those changes in an
> upcoming
> M:S:Q release. If not this one (I can understand wanting to keep your
> first
> one modest), then one soon after. His changes significantly improve the
> correctness of M:S:Q significantly WRT the current ABNF.
>
> Scott K
>
> -------
> To unsubscribe, change your address, or temporarily deactivate your
> subscription,
> please go to
> http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
>

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Polishing Mail::SPF::Query [ In reply to ]

julian at mehnle

Nov 30, 2005, 5:02 AM

Post #12 of 27 (9161 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Kitterman wrote:
> Craig Whitmore put a lot of effort into his updates (and IIRC they were
> the reason you asked Meng for CPAN access in the first place)

(Yes, I remember that.)

> in order to make sure M:S:Q matched the current internet draft ABNF for
> what was and was not a valid record. We worked through a lot of
> scenarios to see that both M:S:Q and pySPF were correct in this regard
> over the summer.
>
> There was a period where there were more visits from NZ than everywhere
> else combined to my validator because he was running tests against both
> libraries to be sure.
>
> I would like to strongly encourage you to include those changes in an
> upcoming M:S:Q release. If not this one (I can understand wanting to
> keep your first one modest), then one soon after. His changes
> significantly improve the correctness of M:S:Q significantly WRT the
> current ABNF.

I do respect the work of Craig and you. However, I have not understood the
purpose of his changes from my rough review, and I'm sure you'll agree
that whoever puts out a new release should know what changes he is
applying. I feel that I shouldn't just apply the patch en bloc without
having understood it.

Craig Whitmore wrote:
> My Changes included (not not limited to)
>
> Checking for a: with numbers
> Check for more than 10 DNS Queries
> Checking for anything after all
> Checking for mx with a valud FQDN
> Checking for valid ip4:
> Check for people trying to use v=spf2.0/mfrom spf2.0/pra (not really
> needed)

Most of it sounds great. M:S:Q shouldn't begin touching SPFv2.x records
_now_, though. Also, IIRC having mechanisms after "all" isn't technically
invalid and thus should produce a warning at best, but since such a
warning can only go to the receiver and not the domain owner, it would be
mostly useless.

Craig, are there some more detailed records of your changes, i.e. a
changelog with references to the code, or an old mailing list thread
between Scott and you, that I can read up on?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDjaLrwL7PKlBZWjsRAnOpAJsHdDD/OWCYvPQFacp1tIYD/0KeEwCeJ+5n
vwyJefhvGFsBizu5SBDqWLw=
=hEIb
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Polishing Mail::SPF::Query [ In reply to ]

nobody at xyzzy

Nov 30, 2005, 8:22 AM

Post #13 of 27 (9169 views)

Craig Whitmore wrote:

> Checking for anything after all

AFAIK that isn't illegal, or is it ? If you have different
modes of operation ("validation" vs. "check") it could be a
"warning" for "validation": Anything behind "all" that's
not a modifier (like "exp=...") is utter dubious.

Additionally a record with both "all" and "redirect=..."
is dubious, even if "redirect=..." comes before "all".

Another dubious case would be records with neither "all"
nor "redirect=...", but AFAIK that's all "legal" (i.e. no
PermError or TempError in actual checks). Syntactically
you can have "v=spf1 +all -all" like say "v=spf1 +a -a"
or similar crap.

One unresolved issues is .../0 , Wayne proposed to kill it.

OTOH there's just an IETF last call for a kind of 1519bis:
http://tools.ietf.org/html/draft-ietf-grow-rfc1519bis#page-7

So generally .../0 isn't illegal, only for our purposes
it's almost useless, we have "all". But maybe something
like "ip6:0::0/0" could make sense (?).

Bye, Frank

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Polishing Mail::SPF::Query [ In reply to ]

julian at mehnle

Nov 30, 2005, 9:04 AM

Post #14 of 27 (9161 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arjen de Korte wrote:
> The only thing that still bothers me, are the examples with legitimate
> domainnames (particularly, 'mydomain.com'). This issue has been
> discussed on spf-help (if memory serves) as people used the same names
> when giving example SPF records. Confusing at best. I would applaud if
> we used RFC 2606 domain names wherever possible/practical in the
> documentation.

Hmm, generally you're right, but I wonder where we should draw the line
when deciding what to fix in M:S:Q and what not. Personally, I'm not
going to invest the time into fixing this, but if someone makes a good
patch, I'll happily apply it.

> Also, I noticed that 'spf.pobox.com' is still mentioned in some files,
> where it should read 'www.openspf.org'.

Fixed.

> Since I know crap about cvs (read: about pulling the latest sources from
> the server) it is hard to generate diffs. Is it possible to condense the
> whole trunk in one archive and make that available somewhere?

You can install Subversion and then do...

$ svn co http://www.openspf.org/svn/mail-spf-query-perl/trunk

Committing changes to the repository is restricted however. Please submit
patches instead (`svn diff >foo.diff`).

You can also click on the "Download tarball" link on the following page:

http://www.openspf.org/source/mail-spf-query-perl/trunk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDjduLwL7PKlBZWjsRAiDTAKCbTA9xbnM0nfc3U0pcNTM9iMt1GACeNTvh
fc7kFG+JPuKhe4cNnxDx1NI=
=3RDN
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Polishing Mail::SPF::Query [ In reply to ]

julian at mehnle

Nov 30, 2005, 4:57 PM

Post #15 of 27 (9167 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arjen de Korte wrote:
> I don't have time to come up with a patch now (it's late already here),
> but will look into it. When is the final submission date for patches?

No hard cutoff date. I'll wait for your patch, provided it doesn't take
too long.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDjkqRwL7PKlBZWjsRAk6fAKDGqOXeOVLG5H8xFqCV1IZ+bxL4YgCg2lgn
URrL6VazwmaLVHg5CqRIbUs=
=d6hL
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Re: Polishing Mail::SPF::Query [ In reply to ]

spf+devel at de-korte

Dec 1, 2005, 12:44 PM

Post #16 of 27 (9131 views)

Julian Mehnle schreef:

> No hard cutoff date. I'll wait for your patch, provided it doesn't take
> too long.

Find attached a patch. Besides renaming 'mydomain.com' (and other
example domain names) to 'example.com', it also modifies the MANIFEST to
reflect renaming 'Changes' to 'CHANGES'.

Regards,
Arjen

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Polishing Mail::SPF::Query [ In reply to ]

julian at mehnle

Dec 1, 2005, 1:47 PM

Post #17 of 27 (9158 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arjen de Korte wrote:
> Find attached a patch. Besides renaming 'mydomain.com' (and other
> example domain names) to 'example.com', it also modifies the MANIFEST to
> reflect renaming 'Changes' to 'CHANGES'.

Applied, thanks.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDj296wL7PKlBZWjsRAstKAKCg7fdl10WfNfEuZqoulsmnwuWj6gCgmZSz
IgjkdUKM4BSUHF+4HPOSgv8=
=HbKL
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Polishing Mail::SPF::Query [ In reply to ]

spf+devel at de-korte

Dec 5, 2005, 12:25 PM

Post #18 of 27 (9124 views)

The following patch (from revision 115) is incomplete as it is:

trunk/Query.pm
* Change local machine hostname macro from "xr" to "r" (closes rt.debian.org

It fails to change two instances of "xr" to "r" which causes that the
default explanation string is now broken (the hostname macro is not
expanded). The attached patch fixes this, as well as one line of dead
code from my earlier patch to remove C-ID.

Arjen

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Polishing Mail::SPF::Query [ In reply to ]

julian at mehnle

Dec 5, 2005, 1:03 PM

Post #19 of 27 (9130 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arjen de Korte wrote:
> The following patch (from revision 115) is incomplete as it is:
>
> trunk/Query.pm
> * Change local machine hostname macro from "xr" to "r" (closes
> rt.debian.org bug #9744).
>
> It fails to change two instances of "xr" to "r" which causes that the
> default explanation string is now broken (the hostname macro is not
> expanded).

Hmm, I thought I had searched and replaced case-insensitively, but it
appears I had not. Thanks, good catch!

> The attached patch fixes this, as well as one line of dead code from my
> earlier patch to remove C-ID.

Thanks, applied.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDlKsVwL7PKlBZWjsRAiyeAKDCCwuXAu8wULvLDvWQqraS5AqyNwCfWIae
AxGbbjrqJF4zBXeBl2c/0E4=
=jN0A
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Polishing Mail::SPF::Query [ In reply to ]

spf+devel at de-korte

Dec 6, 2005, 2:09 AM

Post #20 of 27 (9155 views)

I don't know if someone is working on the following TODO already, but do
we really want to fix this in M:S:Q?

* Add support for doing HELO tests before MAIL FROM tests.

My feeling is that this will require drastic changes to the internals of
M:S:Q and we don't want to spend too much effort here (with regard to the
fact that we intend it to be replaced in the not so distant future by
Mail::SPF). Also, we don't want 'local', 'fallback' and 'override'
mechanisms, nor 'trusted' and 'guess' processing for the HELO tests. Even
if we do, they may be different from the ones used in MAIL FROM tests. At
least, that is how I feel about it, since only the operator of a system
can tell if that system is allowed to send mail.

Basically we will only use SPF fail to reject in a HELO test, in all other
(?) cases, we want MAIL FROM to be tested. It is a horrible kludge, but is
calling M:S:Q twice (first with a 'null' sender address and then with the
real sender address) not an option here? M:S:Q will be forced to perform a
HELO test in the first case as far as I can see. This would require
minimal changes to the sample implementations only (and some explanation
why to do it like this in the documentation).

Arjen

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Re: Polishing Mail::SPF::Query [ In reply to ]

arjen at de-korte

Dec 6, 2005, 2:38 AM

Post #21 of 27 (9161 views)

> When M:S:Q was developed, the only time HELO was checked was for a null
> Mail From <>. I think that changing that would risk breakage that
> shouldn't be done with M:S:Q at this stage.

This is what my proposal is about. I'm suggesting to leave M:S:Q as it is
and do the HELO testing by calling it with a sender address that is
deliberately set to the null '<>' sender. This shouldn't break anything,
since this is what happens now already. I will post a patch for
'postfix-policyd-spf' later today to show what I mean.

Regards, Arjen

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Re: Polishing Mail::SPF::Query [ In reply to ]

spf2 at kitterman

Dec 6, 2005, 4:23 AM

Post #22 of 27 (9129 views)

On Tue, 6 Dec 2005 11:09:38 +0100 (CET) "Arjen de Korte"
<spf+devel@de-korte.org> wrote:
>I don't know if someone is working on the following TODO already, but do
>we really want to fix this in M:S:Q?
>
> * Add support for doing HELO tests before MAIL FROM tests.
>
>My feeling is that this will require drastic changes to the internals of
>M:S:Q and we don't want to spend too much effort here (with regard to the
>fact that we intend it to be replaced in the not so distant future by
>Mail::SPF). Also, we don't want 'local', 'fallback' and 'override'
>mechanisms, nor 'trusted' and 'guess' processing for the HELO tests. Even
>if we do, they may be different from the ones used in MAIL FROM tests. At
>least, that is how I feel about it, since only the operator of a system
>can tell if that system is allowed to send mail.
>
>Basically we will only use SPF fail to reject in a HELO test, in all other
>(?) cases, we want MAIL FROM to be tested. It is a horrible kludge, but is
>calling M:S:Q twice (first with a 'null' sender address and then with the
>real sender address) not an option here? M:S:Q will be forced to perform a
>HELO test in the first case as far as I can see. This would require
>minimal changes to the sample implementations only (and some explanation
>why to do it like this in the documentation).
>
>Arjen
>

When M:S:Q was developed, the only time HELO was checked was for a null
Mail From <>. I think that changing that would risk breakage that
shouldn't be done with M:S:Q at this stage. I think this should be
deferred to a probably never to happen M:S:Q 2.0 effort.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Re: Polishing Mail::SPF::Query [ In reply to ]

spf+devel at de-korte

Dec 6, 2005, 11:51 AM

Post #23 of 27 (9114 views)

See the attached patch for postfix-policyd-spf to see what I mean with
using the existing Mail::SPF::Query to perform HELO tests. It will first
do a lookup with a 'null' sender address, so that M:S:Q is forced to
fallback to HELO testing. Due to the widespread use of non-compliant
HELO's, only if the result is 'fail', a smtp reject will be returned. In
all other cases (even when errors are encountered), the usual MAIL FROM
testing will be performed. Of course, one could optimize this (for
instance, when there is no sender address to begin with). Since I'm not
that fluent in perl, I didn't include this.

Arjen

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Polishing Mail::SPF::Query [ In reply to ]

julian at mehnle

Dec 6, 2005, 2:48 PM

Post #24 of 27 (9154 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arjen de Korte wrote:
> See the attached patch for postfix-policyd-spf to see what I mean with
> using the existing Mail::SPF::Query to perform HELO tests. It will first
> do a lookup with a 'null' sender address, so that M:S:Q is forced to
> fallback to HELO testing. Due to the widespread use of non-compliant
> HELO's, only if the result is 'fail', a smtp reject will be returned. In
> all other cases (even when errors are encountered), the usual MAIL FROM
> testing will be performed.

Without having seen your patch, I am very reluctant to apply this to the
official M:S:Q repository, because it is essentially a gross hack. Let's
face it, M:S:Q does have some deficiencies that will never be resolved.
It not being able to do HELO and MAIL FROM checks separately is one of
them. Is it of much value for postfix-policyd-spf to work around this
limitation in such an awkward way?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDlhUywL7PKlBZWjsRAnM0AJwNjTVGPXVCLtiAfuRU+AF+JRgykwCfZVds
DAcpixUTHhuz8To6fQ6/nPo=
=TvmC
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Re: Polishing Mail::SPF::Query [ In reply to ]

julian at mehnle

Dec 6, 2005, 3:34 PM

Post #25 of 27 (9126 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arjen de Korte wrote:
> I don't know if someone is working on the following TODO already, but do
> we really want to fix this in M:S:Q?
>
> * Add support for doing HELO tests before MAIL FROM tests.
>
> My feeling is that this will require drastic changes to the internals of
> M:S:Q and we don't want to spend too much effort here (with regard to
> the fact that we intend it to be replaced in the not so distant future
> by Mail::SPF). [...]

As I said in my other message, I don't think this is something that can be
fixed in M:S:Q without unreasonable efforts.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDliAcwL7PKlBZWjsRAlY6AKCDJjPx91hE5XAptQBT0jBNw10CEgCeNz3U
8Ge6qVkR2tQwgPxUXzzDHpg=
=e7H9
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com