Mailing List Archive

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

Julian Mehnle wrote:
> It is finally done! Well, very nearly, that is.
>
> Here's a pre-release of Mail::SPF, the (incompatible) successor to the
> old Mail::SPF::Query Perl module:
>
> http://search.cpan.org/dist/Mail-SPF-2.000_003/

I forgot to mention: The 2.00 release that's on CPAN is an old defunct
release uploaded by Shevek last year. The gold release will be 2.001.

Oh, and please try not to follow up to _both_ spf-discuss and spf-devel
unless it is really relevant to both lists.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFa2I3wL7PKlBZWjsRApX+AKCruuXMFjPWBKh27n/RQzLq6YN+GACgiOrF
fqe502QH63IEH+hROKxKyBs=
=y5Sh
-----END PGP SIGNATURE-----

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

>>>>> "Julian" == Julian Mehnle
>>>>> "Mail::SPF pre-release -- please review and test!"
>>>>> Mon, 27 Nov 2006 22:06:25 +0000

Julian> Here's a pre-release of Mail::SPF, the (incompatible)
Julian> successor to the old Mail::SPF::Query Perl module:

Julian> http://search.cpan.org/dist/Mail-SPF-2.000_003/

No Postfix policy daemon included?
<http://search.cpan.org/src/JMEHNLE/Mail-SPF-2.000_003/MANIFEST> Am I
missing something?

jam

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

> -----Original Message-----
> From: Julian Mehnle [mailto:julian@mehnle.net]
> Sent: maandag 27 november 2006 23:07
> To: SPF Development; SPF Discussion
> Subject: [spf-devel] Mail::SPF pre-release -- please review and test!
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all!
>
> It is finally done! Well, very nearly, that is.
>
> Here's a pre-release of Mail::SPF, the (incompatible)
> successor to the old
> Mail::SPF::Query Perl module:
>
> http://search.cpan.org/dist/Mail-SPF-2.000_003/

Minor snare. :)

asarian-host: {root} % make
/usr/local/standard-perl/bin/perl5.8.8 Build --makefile_env_macros 1
Global symbol "$VAR1" requires explicit package name at (eval 24) line 1075,
<GEN6> line 1.
...propagated at
/usr/local/standard-perl/lib/perl5/site_perl/5.8.8/Module/Build/Base.pm line
1002, <GEN6> line 1.
*** Error code 255

Stop in /usr/home/asarian-host/temp/Mail-SPF-2.000_003.

- Mark

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

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

John A. Martin wrote:
> Julian> Here's a pre-release of Mail::SPF, the (incompatible) successor
> Julian> to the old Mail::SPF::Query Perl module:
>
> Julian> http://search.cpan.org/dist/Mail-SPF-2.000_003/
>
> No Postfix policy daemon included?
> <http://search.cpan.org/src/JMEHNLE/Mail-SPF-2.000_003/MANIFEST> Am I
> missing something?

Yes, you are. The Postfix policy daemon based on Mail::SPF::Query has been
split out into its own package a while ago:

http://new.openspf.org/source/software/postfix-policyd-spf-perl/tags/

The latest version, 1.08, is still based on Mail::SPF::Query. As I don't
use Postfix, I probably won't take the time to update it to work with
Mail::SPF instead. If anyone else wants to do that, they can have write
access to the postfix-policyd-spf-perl Subversion repo.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFbGxzwL7PKlBZWjsRAhaWAJwPjUWf+sH8pzHClJsdO7HxLElGTgCcC/tZ
vnqDCXw7NWsYWBZUKcfpx24=
=Ntry
-----END PGP SIGNATURE-----

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

> -----Original Message-----
> From: Mark [mailto:admin@asarian-host.net]
> Sent: dinsdag 28 november 2006 18:04
> To: spf-devel@v2.listbox.com
> Subject: RE: [spf-devel] Mail::SPF pre-release -- please
> review and test!
>
>
> Minor snare. :)
>
> asarian-host: {root} % make
> /usr/local/standard-perl/bin/perl5.8.8 Build --makefile_env_macros 1
> Global symbol "$VAR1" requires explicit package name at (eval
> 24) line 1075,
> <GEN6> line 1.
> ...propagated at
> /usr/local/standard-perl/lib/perl5/site_perl/5.8.8/Module/Buil
> d/Base.pm line
> 1002, <GEN6> line 1.
> *** Error code 255
>
> Stop in /usr/home/asarian-host/temp/Mail-SPF-2.000_003.
>
> - Mark

Oops, forgot to mention that changing "$VAR1" to "$main::VAR1" makes
it install again.

- Mark

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

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

Mark wrote:
> > asarian-host: {root} % make
> > /usr/local/standard-perl/bin/perl5.8.8 Build --makefile_env_macros 1
> > Global symbol "$VAR1" requires explicit package name at (eval
> > 24) line 1075,
> > <GEN6> line 1.
> > ...propagated at
> > /usr/local/standard-perl/lib/perl5/site_perl/5.8.8/Module/Buil
> > d/Base.pm line
> > 1002, <GEN6> line 1.
> > *** Error code 255
> >
> > Stop in /usr/home/asarian-host/temp/Mail-SPF-2.000_003.
>
> Oops, forgot to mention that changing "$VAR1" to "$main::VAR1" makes
> it install again.

Changing it _where_?

What does

$ perl -MModule::Build -e 'print(Module::Build->VERSION, "\n")'

say?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFbHHqwL7PKlBZWjsRAm5xAJ0f00qHauE6C9cth7DTqqH5k5DcNgCdEhd6
UGKIs+LeyJC6AplscLKnm04=
=kenu
-----END PGP SIGNATURE-----

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

> -----Original Message-----
> From: Julian Mehnle [mailto:julian@mehnle.net]
> Sent: dinsdag 28 november 2006 18:43
> To: spf-devel@v2.listbox.com
> Subject: [spf-devel] Re: Mail::SPF pre-release -- please
> review and test!
>
>
> > > Stop in /usr/home/asarian-host/temp/Mail-SPF-2.000_003.
> >
> > Oops, forgot to mention that changing "$VAR1" to "$main::VAR1"
> > makes it install again.
>
> Changing it _where_?

In _build/build_params.

> What does
>
> $ perl -MModule::Build -e 'print(Module::Build->VERSION, "\n")'
>
> say?

It's the latest version alright: 0.280500.

- Mark

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

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

Mark wrote:
> > > Oops, forgot to mention that changing "$VAR1" to "$main::VAR1"
> > > makes it install again.
> >
> > Changing it _where_?
>
> In _build/build_params.
>
> > What does
> >
> > $ perl -MModule::Build -e 'print(Module::Build->VERSION, "\n")'
> >
> > say?
>
> It's the latest version alright: 0.280500.

Hmm, this seems to be a bug with versions of Module::Build later than 0.26,
probably just with 0.28 and above. I have been getting similar errors
with the automatic CPAN build tests:

http://cpantesters.perl.org/show/Mail-SPF.html

I'll flag this as a potential bug with the Module::Build developers. *sigh*

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFbH8+wL7PKlBZWjsRAjqJAKDqB3+j5kQj2+ebOpxUPuMtG3nyqQCfXqIU
0jJmybHzIeySq/rkndQHsN8=
=5RvA
-----END PGP SIGNATURE-----

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

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

Julian Mehnle wrote:
> It is finally done! Well, very nearly, that is.
>
> Here's a pre-release of Mail::SPF, the (incompatible) successor to the
> old Mail::SPF::Query Perl module:
>
> http://search.cpan.org/dist/Mail-SPF-2.000_003/

One more note: For those who use Debian, I have built a Debian package:

http://files.mehnle.net/software/mail-spf-perl/debian/

There are the "libmail-spf-perl" and "spf-tools-perl" packages.

There is a run-time dependency on libnetaddr-ip-perl >= 4 that is unsol-
vable with the package version available in the official Debian/unstable
distribution (the Debian maintainer responsible for it is sleeping). You
can get an updated package here:

http://files.mehnle.net/software/debian/libnetaddr-ip-perl/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFbMiSwL7PKlBZWjsRAjOpAKCEKEWIOGDGywkg+6qoGAm7MwDkMQCdHVH+
VCpm7Ol7cKcFMtRHOIIt288=
=pcQb
-----END PGP SIGNATURE-----

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

> -----Original Message-----
> From: Julian Mehnle [mailto:julian@mehnle.net]
> Sent: woensdag 29 november 2006 0:40
> To: SPF Development; SPF Discussion
> Subject: [spf-discuss] Re: Mail::SPF pre-release -- please
> review and test!

Quick question.

I remember us saying that in the long term (RFC 4408bis and SPFv3),
"PermError" should be the equivalent to SMTP's 5xx error code. Did we
decide what code yet? I'm implementing the new Mail::SPF right now.

- Mark

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

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

Mark wrote:
> Quick question.
>
> I remember us saying that in the long term (RFC 4408bis and SPFv3),
> "PermError" should be the equivalent to SMTP's 5xx error code. Did we
> decide what code yet? I'm implementing the new Mail::SPF right now.

RFC 2821 says:

| The second digit encodes responses in specific categories:
|
| x0z Syntax: These replies refer to syntax errors, syntactically
| correct commands that do not fit any functional category, and
| unimplemented or superfluous commands.
|
| x1z Information: These are replies to requests for information,
| such as status or help.
|
| x2z Connections: These are replies referring to the transmission
| channel.
|
| x3z Unspecified.
|
| x4z Unspecified.
|
| x5z Mail system: These replies indicate the status of the receiver
| mail system vis-a-vis the requested transfer or other mail system
| action.

and:

| 550 Requested action not taken: mailbox unavailable
| (e.g., mailbox not found, no access, or command rejected
| for policy reasons)
| 551 User not local; please try <forward-path>
| (See section 3.4)
| 552 Requested mail action aborted: exceeded storage allocation
| 553 Requested action not taken: mailbox name not allowed
| (e.g., mailbox syntax incorrect)
| 554 Transaction failed (Or, in the case of a connection-opening
| response, "No SMTP service here")

So I'd say 550, or some other 55x code.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFbPDuwL7PKlBZWjsRAg+qAKDl6oCSUmE/Wryh4octsCZA10X1LQCgkVJR
pde3O5Bf30yRXoDi+Z2TkBc=
=sl6a
-----END PGP SIGNATURE-----

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

On Wed, 29 Nov 2006 00:37:10 GMT Mark <admin@asarian-host.net> wrote:
>> -----Original Message-----
>> From: Julian Mehnle [mailto:julian@mehnle.net]
>> Sent: woensdag 29 november 2006 0:40
>> To: SPF Development; SPF Discussion
>> Subject: [spf-discuss] Re: Mail::SPF pre-release -- please
>> review and test!
>
>Quick question.
>
>I remember us saying that in the long term (RFC 4408bis and SPFv3),
>"PermError" should be the equivalent to SMTP's 5xx error code. Did we
>decide what code yet? I'm implementing the new Mail::SPF right now.

I researched this for a patch I was doing for tumgreyspf a few months ago.
550 was the answer I came up with.

Scott K

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

> -----Original Message-----
> From: Julian Mehnle [mailto:julian@mehnle.net]
> Sent: woensdag 29 november 2006 3:31
> To: spf-devel@v2.listbox.com
> Subject: [spf-devel] Re: Mail::SPF pre-release -- please
> review and test!
>
>
> Mark wrote:
>
> > Quick question.
> >
> > I remember us saying that in the long term (RFC 4408bis and
> > SPFv3), "PermError" should be the equivalent to SMTP's 5xx
> > error code. Did we decide what code yet? I'm implementing
> > the new Mail::SPF right now.
>
> | 550 Requested action not taken: mailbox unavailable
> | (e.g., mailbox not found, no access, or command rejected
> | for policy reasons)
> | 551 User not local; please try <forward-path>
> | (See section 3.4)
> | 552 Requested mail action aborted: exceeded storage allocation
> | 553 Requested action not taken: mailbox name not allowed
> | (e.g., mailbox syntax incorrect)
> | 554 Transaction failed (Or, in the case of a
> | connection-opening
> | response, "No SMTP service here")
>
> So I'd say 550, or some other 55x code.

Thanks. Definitely a 55x code. I was actually more thinking of RFC 1893
("Enhanced Mail System Status Codes"). Perhaps the combo 550 5.5.2 ?

X.5.2 Syntax error

A mail transaction protocol command was issued which could
not be interpreted, either because the syntax was wrong or
the command is unrecognized. This is useful only as a
permanent error.

I think I'll go with that, for now.

- Mark

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

On Tuesday 28 November 2006 22:21, Mark wrote:
> > -----Original Message-----
> > From: Julian Mehnle [mailto:julian@mehnle.net]
> > Sent: woensdag 29 november 2006 3:31
> > To: spf-devel@v2.listbox.com
> > Subject: [spf-devel] Re: Mail::SPF pre-release -- please
> > review and test!
> >
> > Mark wrote:
> > > Quick question.
> > >
> > > I remember us saying that in the long term (RFC 4408bis and
> > > SPFv3), "PermError" should be the equivalent to SMTP's 5xx
> > > error code. Did we decide what code yet? I'm implementing
> > > the new Mail::SPF right now.
> > >
> > | 550 Requested action not taken: mailbox unavailable
> > | (e.g., mailbox not found, no access, or command rejected
> > | for policy reasons)
> > | 551 User not local; please try <forward-path>
> > | (See section 3.4)
> > | 552 Requested mail action aborted: exceeded storage allocation
> > | 553 Requested action not taken: mailbox name not allowed
> > | (e.g., mailbox syntax incorrect)
> > | 554 Transaction failed (Or, in the case of a
> > | connection-opening
> > | response, "No SMTP service here")
> >
> > So I'd say 550, or some other 55x code.
>
> Thanks. Definitely a 55x code. I was actually more thinking of RFC 1893
> ("Enhanced Mail System Status Codes"). Perhaps the combo 550 5.5.2 ?
>
> X.5.2 Syntax error
>
> A mail transaction protocol command was issued which could
> not be interpreted, either because the syntax was wrong or
> the command is unrecognized. This is useful only as a
> permanent error.
>
> I think I'll go with that, for now.
>
Sorry, yes, for permerror I think that's appropriate. The patch I did for
tumgreyspf was for a Fail, so 550 for policy reasons was appropriate.

Scott K

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

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

Mark wrote:
> Thanks. Definitely a 55x code. I was actually more thinking of RFC 1893
> ("Enhanced Mail System Status Codes"). Perhaps the combo 550 5.5.2 ?
>
> X.5.2 Syntax error
>
> A mail transaction protocol command was issued which could
> not be interpreted, either because the syntax was wrong or
> the command is unrecognized. This is useful only as a
> permanent error.

I don't think a "syntax error" is appropriate. Yes, a PermError may be due
to a syntax error, but (1) that syntax error would not be in a "mail
transaction protocol command", and (2) SPF's PermError doesn't always mean
a syntax error in the SPF record, either.

Scott Kitterman wrote:
> Sorry, yes, for permerror I think that's appropriate. The patch I did
> for tumgreyspf was for a Fail, so 550 for policy reasons was
> appropriate.

What Mark said he would be using _is_ 550 -- with an extended status code
of 5.5.2.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFbW6dwL7PKlBZWjsRAhVrAKDWeVYmgYSAhlhenpUKRzXeaCbPEwCglaxb
L0pDyUaFenNMUeDRRp2Mer0=
=EXRc
-----END PGP SIGNATURE-----

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

On Wednesday 29 November 2006 06:27, Julian Mehnle wrote:
> Mark wrote:
> > Thanks. Definitely a 55x code. I was actually more thinking of RFC 1893
> > ("Enhanced Mail System Status Codes"). Perhaps the combo 550 5.5.2 ?
> >
> > X.5.2 Syntax error
> >
> > A mail transaction protocol command was issued which could
> > not be interpreted, either because the syntax was wrong or
> > the command is unrecognized. This is useful only as a
> > permanent error.
>
> I don't think a "syntax error" is appropriate. Yes, a PermError may be due
> to a syntax error, but (1) that syntax error would not be in a "mail
> transaction protocol command", and (2) SPF's PermError doesn't always mean
> a syntax error in the SPF record, either.
>
> Scott Kitterman wrote:
> > Sorry, yes, for permerror I think that's appropriate. The patch I did
> > for tumgreyspf was for a Fail, so 550 for policy reasons was
> > appropriate.
>
> What Mark said he would be using _is_ 550 -- with an extended status code
> of 5.5.2.

Yes. I was kind of fuzzy last night (not that today is any better).

Scott K

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

> -----Original Message-----
> From: Julian Mehnle [mailto:julian@mehnle.net]
> Sent: woensdag 29 november 2006 12:28
> To: spf-devel@v2.listbox.com
> Subject: [spf-devel] Re: Mail::SPF pre-release -- please
> review and test!
>
>
> Mark wrote:

> > Thanks. Definitely a 55x code. I was actually more thinking of RFC
> > 1893 ("Enhanced Mail System Status Codes"). Perhaps the combo
> > 550 5.5.2 ?
> >
> > X.5.2 Syntax error
> >
> > A mail transaction protocol command was issued which could
> > not be interpreted, either because the syntax was wrong or
> > the command is unrecognized. This is useful only as a
> > permanent error.
>
> I don't think a "syntax error" is appropriate. Yes, a PermError may
> be due to a syntax error, but (1) that syntax error would not be
> in a "mail transaction protocol command", and (2) SPF's PermError
> doesn't always mean a syntax error in the SPF record, either.

I know this. :) But see, none of them really match precisely.
Alternatives? "5.5.0" might work.

X.5.0 Other or undefined protocol status

Something was wrong with the protocol necessary to deliver
the message to the next hop and the problem cannot be well
expressed with any of the other provided detail codes.

But there's no "next hop". Although "Something was wrong with the protocol
necessary to deliver the message," and "the problem cannot be well
expressed with any of the other provided detail codes." comes close.

- Mark

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

Julian,

For starters, I must say I'm impressed with the production-grade level
stability of the new Mail::SPF. :) One or two small comments, though.

1): In RFC 4408, 7. ("The Received-SPF Header Field"), we define identity
as:

identity = "mailfrom" ; for the "MAIL FROM" identity
/ "helo" ; for the "HELO" identity
/ name ; other identities

Yet Mail::SPF uses "in 'mfrom' identity" for the local_explanation. That's
not technically wrong, as it's not a key/value pair like
"identity=mailfrom;" but for consistency's sake, I wouldn't mind if
Mail::SPF also said "in 'mailfrom' identity".

2): It used to be (though nothing official) that the first word in a
Received-SPF header, after the result, was the receiving domain ($j in
sendmail); like:

Received-SPF: pass (asarian-host.net: ...

I see you changed that to:

Received-SPF: pass (v2.listbox.com ... listbox.com: ...

Also, not technically wrong, as a key/value pair of
"receiver=asarian-host.net;" should contain such receiver info. In fact, I
kinda like the new way. :) I just wonder if there are perhaps folks out
there who rely on the receiver info being included in the old manner. RFC
4408 also used the 'old way' example:

Received-SPF: Pass (mybox.example.org: domain of
myname@example.com designates 192.0.2.1 as permitted sender)
receiver=mybox.example.org; client-ip=192.0.2.1;
envelope-from=<myname@example.com>; helo=foo.example.com;

Perhaps you could add a line or two in the documentation, stating that the
'new way' lists the domain used in mailfrom, respectively, the final
domain the SPF check was made on.

- 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/?list_id=1007

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

Mark wrote:
> For starters, I must say I'm impressed with the production-grade level
> stability of the new Mail::SPF. :) One or two small comments, though.

Thanks for your feedback!

> 1): In RFC 4408, 7. ("The Received-SPF Header Field"), we define
> identity as:
>
> identity = "mailfrom" ; for the "MAIL FROM" identity
> / "helo" ; for the "HELO" identity
> / name ; other identities
>
> Yet Mail::SPF uses "in 'mfrom' identity" for the local_explanation.
> That's not technically wrong, as it's not a key/value pair like
> "identity=mailfrom;" but for consistency's sake, I wouldn't mind if
> Mail::SPF also said "in 'mailfrom' identity".

The reason for that is that I defined the following set of "scopes" for
request parameterization and internal use: "helo", "mfrom", "pra". The
"mfrom" and "pra" scope names obviously come from the "spf2.0" scope names,
and I'd like to keep that consistent, not the least because I think that
"mfrom" makes a better (since shorter) scope name -- generally, and for
some SPFv3 -- than "mailfrom". And as you said, the local explanation is
just a free form explanation.

BTW, there is also an unlucky collision between how RFC 4408 (and
Mail::SPF) generally uses the term "identity" and how it is used specifi-
cally by the definition of the "Received-SPF" header. In the former,
"identity" means the identity itself, not its type. In the latter, the
"identity" key name should really have been named "identity-type" or
"scope" or something.

> 2): It used to be (though nothing official) that the first word in a
> Received-SPF header, after the result, was the receiving domain ($j in
> sendmail); like:
>
> Received-SPF: pass (asarian-host.net: ...
>
> I see you changed that to:
>
> Received-SPF: pass (v2.listbox.com ... listbox.com: ...
>
> Also, not technically wrong, as a key/value pair of
> "receiver=asarian-host.net;" should contain such receiver info. In fact,
> I kinda like the new way. :) I just wonder if there are perhaps folks
> out there who rely on the receiver info being included in the old
> manner.

They must not rely on that, because this is in a header _comment_, which by
definition never has any defined semtantics.

I think that the new comment style is more useful for debugging SPF records
and mail setups because it gives information that cannot be found anywhere
else.

> RFC 4408 also used the 'old way' example:
>
> Received-SPF: Pass (mybox.example.org: domain of
> myname@example.com designates 192.0.2.1 as permitted sender)
> receiver=mybox.example.org; client-ip=192.0.2.1;
> envelope-from=<myname@example.com>; helo=foo.example.com;
>
> Perhaps you could add a line or two in the documentation, stating that
> the 'new way' lists the domain used in mailfrom, respectively, the final
> domain the SPF check was made on.

A good idea. Will do.

Again, thanks for your feedback!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFcXIzwL7PKlBZWjsRArw2AJ9rbXsJTVvUs+QGrWaCsG2JNRil4ACg2EXB
hKS59wmxmp3cuMeqm9ZM+gM=
=l4sL
-----END PGP SIGNATURE-----

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

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

Mark,

Julian Mehnle wrote:
> Mark wrote:
> > > > Oops, forgot to mention that changing "$VAR1" to "$main::VAR1"
> > > > makes it install again.
> > >
> > > Changing it _where_?
> >
> > In _build/build_params.
> >
> > > What does
> > >
> > > $ perl -MModule::Build -e 'print(Module::Build->VERSION, "\n")'
> > >
> > > say?
> >
> > It's the latest version alright: 0.280500.
>
> Hmm, this seems to be a bug with versions of Module::Build later than
> 0.26, probably just with 0.28 and above. I have been getting similar
> errors with the automatic CPAN build tests:
>
> http://cpantesters.perl.org/show/Mail-SPF.html
>
> I'll flag this as a potential bug with the Module::Build developers.
> *sigh*

the Module::Build devs are asking what Data::Dumper version you have? And
can you please try to build Mail::SPF again (without your work-around)
and, when it fails, send your _build/build_params file directly to my
address?

TIA.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFdVZnwL7PKlBZWjsRAhQ9AJ48wTgX+Q5RIYZEBp6Z2CtAG90bZACg2x49
XrX92fgfoHucRMopaxRVicI=
=yGMs
-----END PGP SIGNATURE-----

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

A couple of questions...

1. Any particular reason for requiring Net::DNS >= 0.58?

2. Is Net::DNS::Resolver::Programmable needed for anything but build tests?

I'm looking at supporting Mail::SPF in SpamAssassin while keeping in
mind that the more dependencies there are the longer it'll be before
distros include newer versions of SA in their repos.


Regards,

Daryl

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

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

Daryl C. W. O'Shea wrote:
> A couple of questions...
>
> 1. Any particular reason for requiring Net::DNS >= 0.58?

- From the changelog of Net::DNS:

| *** 0.58 July 4, 2006
|
| [...]
| Fix rt.cpan.org 18785
| SPF would not work unless the TXT RR was not loaded first. No
| wonder, SPF fully inherits TXT and loading of TXT.pm is therefore a
| prerequisit.
| [...]
|
| *** 0.56 February 20, 2006
|
| [...]
| Feature Implemented SPF (typecode 99).
| The class completely inherits from Net::DNS::RR::TXT (the easiest
| RR to implement ever).
| [...]

I could have worked around the SPF deficiency in 0.56/0.57, but Net::DNS
0.58 was released on 2006-07-04 -- and NetAddr::IP 4 on 2006-06-19, which
is _absolutely_ required by Mail::SPF. So there was little point in
dropping the dependency on Net::DNS 0.58.

(Can you believe it? All three IP address modules that were on CPAN before
the advent of NetAddr::IP 4 -- Net::IP, Net::IPAddress, and NetAddr::IP
3.x -- are significantly broken in one way or another. I was very close
to writing my own, but then, luckily, NetAddr::IP 4 appeared.)

> 2. Is Net::DNS::Resolver::Programmable needed for anything but build
> tests?

No, it is just needed for build testing. See META.yml:

| requires:
| Error: 0
| Net::DNS: 0.58
| NetAddr::IP: 4
| URI: 1.13
| perl: 5.006
| version: 0
| build_requires:
| Module::Build: 0.26
| Net::DNS::Resolver::Programmable: 0.002001
| Test::More: 0

> I'm looking at supporting Mail::SPF in SpamAssassin while keeping in
> mind that the more dependencies there are the longer it'll be before
> distros include newer versions of SA in their repos.

Yeah, I generally do see that problem. However, I don't think the
dependencies of Mail::SPF are unreasonable.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFffzYwL7PKlBZWjsRAiN9AJwLmGGIwkZ/kIOhiCurtCfGhqXdngCg/JKh
Mh3McxkoyfEmomuPari85F0=
=o/UO
-----END PGP SIGNATURE-----

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

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

Julian Mehnle wrote:
> Mark,
>
> the Module::Build devs are asking what Data::Dumper version you have?
> And can you please try to build Mail::SPF again (without your
> work-around) and, when it fails, send your _build/build_params file
> directly to my address?

Mark?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFff0JwL7PKlBZWjsRAuZ7AJ9bdDtSiIqPc8fRf25HHPpSX0zrCACdFjWc
pu9aqOOcKMXgfZSfwQzrpkc=
=8ye7
-----END PGP SIGNATURE-----

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

Julian Mehnle wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Daryl C. W. O'Shea wrote:
>> A couple of questions...
>>
>> 1. Any particular reason for requiring Net::DNS >= 0.58?
>
> - From the changelog of Net::DNS:

OK, thanks.


> (Can you believe it? All three IP address modules that were on CPAN before
> the advent of NetAddr::IP 4 -- Net::IP, Net::IPAddress, and NetAddr::IP
> 3.x -- are significantly broken in one way or another. I was very close
> to writing my own, but then, luckily, NetAddr::IP 4 appeared.)

I generally expect brokenness in Net-anything on CPAN.


Question 3...

Why is it that only Mail::SPF::Result::Fail implements
authority_explanation() ? I'd expect it to be present in at least
softfail and neutral too. Ideally pass would have it also.


Daryl

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