Mailing List Archive

On Wednesday 14 March 2007 08:42, Thomas Jacob wrote:
> Probably this is something for the mailing list administrator
> or possibly the libspf2 developers, but the problem
> occurs with this list....
>
> As mentioned in a post to spf-devel last week,
> I sometimes seem to be getting softfails for mailing list posts
> originating from v2.listbox.com. I now managed to trace this
> down to the builtin maximum of 5 MX-Entries that
> will be evaluated when one specifies "mx" in the
> SPF recorde, there are however
> 6 mx entries for domain listbox.com.
>
> Whenever the 6th MX (in the order that they are retrieved
> from DNS) is the one that would "allow" the sender-IP
> used, posts will be marked softfail (and thus be copied to my spambox).
>
> So what's the problem here? The MX setup
> of Listbox.com? My various libspf2-Installations? Puzzled....
>
In the RFC 4408 processing limits, up to 10 MX records should be checked.

The RFC 4408 limits are based on the libspf2 limits, but in some cases lipspf2
has lower limits. This appears to be one of them. IIRC libspf2 can be
configured to use different values than the defaults for the limits. I would
recommend changing that limit to 10.

I would appreciate it if you would let us know how/if you are able to change
it.

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Forgot to mention:

Very good analysis. That made it very easy to respond to.

Thanks,

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

> In the RFC 4408 processing limits, up to 10 MX records should be checked.
>
> The RFC 4408 limits are based on the libspf2 limits, but in some cases lipspf2
> has lower limits. This appears to be one of them. IIRC libspf2 can be
> configured to use different values than the defaults for the limits. I would
> recommend changing that limit to 10.
>
> I would appreciate it if you would let us know how/if you are able to change
> it.

Indeed that's the problem, libspf2 (1.2.5) has a builtin
fixed limit of 5 for MX lookups and PTR lookups, RFC 4408 specifies
a hard limit of 10.

This limit can only be increased by patching the code. There seems
to have been a plan to allow this value to be changed at run time
(via a macro-generated function SPF_server_set_max_dns_mx) but
the current code doesn't announce that function in the
library headers anymore. Hmm. Anyway this value would be used
only if it would be smaller than the builtin max so this would
not help here.

See spf_server.h, spf_interpret.c from line 790 onwards
and the RFC section 5.4

Fixing this locally out requires an update of libspf2 installations
on several machines... that's not something I will get around to
quickly, but I will certainly do it over the next weeks.

But it really there is no need to try this out, it's really obvious
from the code and the very helpful debugging output of spfquery/libspf2
(so there didn't have to be all that much effort from my side, cf. your
other mail ;-)

So the question is, shouldn't the libspf fixed limits be extended to at
least allow people to use the maximum number of MX records stipulated in
the RFC?

Afterall there is a good chance that a large number of mail servers will
be using
this lib directly..



-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Wed, 14 Mar 2007 15:16:31 +0100 Thomas Jacob <jacob@internet24.de> wrote:
>> In the RFC 4408 processing limits, up to 10 MX records should be checked.
>>
>> The RFC 4408 limits are based on the libspf2 limits, but in some cases
lipspf2
>> has lower limits. This appears to be one of them. IIRC libspf2 can be
>> configured to use different values than the defaults for the limits. I
would
>> recommend changing that limit to 10.
>>
>> I would appreciate it if you would let us know how/if you are able to
change
>> it.
>
>Indeed that's the problem, libspf2 (1.2.5) has a builtin
>fixed limit of 5 for MX lookups and PTR lookups, RFC 4408 specifies
>a hard limit of 10.
>
>This limit can only be increased by patching the code. There seems
>to have been a plan to allow this value to be changed at run time
>(via a macro-generated function SPF_server_set_max_dns_mx) but
>the current code doesn't announce that function in the
>library headers anymore. Hmm. Anyway this value would be used
>only if it would be smaller than the builtin max so this would
>not help here.
>
>See spf_server.h, spf_interpret.c from line 790 onwards
>and the RFC section 5.4
>
>Fixing this locally out requires an update of libspf2 installations
>on several machines... that's not something I will get around to
>quickly, but I will certainly do it over the next weeks.
>
>But it really there is no need to try this out, it's really obvious
>from the code and the very helpful debugging output of spfquery/libspf2
>(so there didn't have to be all that much effort from my side, cf. your
>other mail ;-)
>
>So the question is, shouldn't the libspf fixed limits be extended to at
>least allow people to use the maximum number of MX records stipulated in
>the RFC?
>
>Afterall there is a good chance that a large number of mail servers will
>be using
>this lib directly..
>
Agreed.

I have managed to end up being the defacto lipspf2 maintainer for Ubuntu.
If I can get a patch this week I can probably get it into the next release.
I'm neither a C programmer nor a lipspf2 user, so I need a patch I can
test/package.

Later I will work on pushing it upstream to Debian.

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

>>>>> "Scott" == Scott Kitterman
>>>>> "Re: Softfail when spf-checking mails from this list, max_dns_mx=5"
>>>>> Wed, 14 Mar 2007 10:33:44 -0400

Scott> I have managed to end up being the defacto lipspf2
Scott> maintainer for Ubuntu. If I can get a patch this week I
Scott> can probably get it into the next release.
Scott> I'm neither a C programmer nor a lipspf2 user, so I need a
Scott> patch I can
Scott> test/package.

Scott> Later I will work on pushing it upstream to Debian.

Surely you have considered this, but what is the rationale for pushing
to distributions SPF implementations that are not known, according to
<http://www.openspf.org/Implementations>, to fully comply with rfc
4408?

Will the package documentation point out that it does or does not
comply fully with the specification or has or has not passed the
current test suite?

BTW don't we want to read "comply" where "conform" is written in

... there are currently two library implementations that are
known to _fully conform_ to the final SPFv1 specification (RFC
4408)

at <http://www.openspf.org/Implementations>?

jam

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

> I have managed to end up being the defacto lipspf2 maintainer for Ubuntu.
> If I can get a patch this week I can probably get it into the next release.
> I'm neither a C programmer nor a lipspf2 user, so I need a patch I can
> test/package.
>
> Later I will work on pushing it upstream to Debian.
>
> Scott K

So what about the actual library source distribution (not the packaged
version for various OSes), who is managing that....? It would
seem more appropriate to change it there, and then use the new release
in the Ubuntu package....

Also, does the RFC set a limit on the number of
SPF mechanism a record may contain? Libspf2 seems be setting this
to 10, maybe this should be adjusted as well...

I've attached a patch that increases the MX/PTR limit to 10.


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Wed, 14 Mar 2007 12:01:04 -0400 "John A. Martin" <jam@jamux.com> wrote:
>>>>>> "Scott" == Scott Kitterman
>>>>>> "Re: Softfail when spf-checking mails from this list, max_dns_mx=5"
>>>>>> Wed, 14 Mar 2007 10:33:44 -0400
>
> Scott> I have managed to end up being the defacto lipspf2
> Scott> maintainer for Ubuntu. If I can get a patch this week I
> Scott> can probably get it into the next release.
> Scott> I'm neither a C programmer nor a lipspf2 user, so I need a
> Scott> patch I can
> Scott> test/package.
>
> Scott> Later I will work on pushing it upstream to Debian.
>
>Surely you have considered this, but what is the rationale for pushing
>to distributions SPF implementations that are not known, according to
><http://www.openspf.org/Implementations>, to fully comply with rfc
>4408?
>
>Will the package documentation point out that it does or does not
>comply fully with the specification or has or has not passed the
>current test suite?
>
>BTW don't we want to read "comply" where "conform" is written in
>
> ... there are currently two library implementations that are
> known to _fully conform_ to the final SPFv1 specification (RFC
> 4408)
>
>at <http://www.openspf.org/Implementations>?
>
Libspf2 was was in Debian/Ubuntu long before I was involved. What I am
doing is trying to make it better. Many of the existing implementations
were done before RFC 4408 was published and so to varying degrees the do
not match the RFC.

Libspf2 is additionally a special case. The RFC 4408 processing limits
were modeled on the Libspf2 limits and so while different in some cases, it
doesn't present the same kind of risks associated with other, older, SPF
implementations. If you need a C SPF library, libspf2 is IMO the one to be
using.

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Thomas Jacob wrote:

> does the RFC set a limit on the number of SPF mechanism a record
> may contain? Libspf2 seems be setting this to 10

The 4408 limit is 10 counting only the mechanisms (and redirect=)
causing a DNS lookup (e.g. "a", but not "ip4" or "all"). That's a
global limit (over any include: or redirect=), no per record limit.

Of course a single record containing 11 counted mechanisms is also
invalid: "v=spf1 a a a a a a a a a a a ?all" is bad (11 As), and
x.example IN SPF "v=spf1 redirect=x.example" is also bad (INF > 10).

Frank


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Wednesday 14 March 2007 12:05, Thomas Jacob wrote:
> > I have managed to end up being the defacto lipspf2 maintainer for Ubuntu.
> > If I can get a patch this week I can probably get it into the next
> > release. I'm neither a C programmer nor a lipspf2 user, so I need a patch
> > I can test/package.
> >
> > Later I will work on pushing it upstream to Debian.
> >
> > Scott K
>
> So what about the actual library source distribution (not the packaged
> version for various OSes), who is managing that....? It would
> seem more appropriate to change it there, and then use the new release
> in the Ubuntu package....

The maintenance of libspf2 is in transition at the moment. The original
developer turned maintenance over to someone else. The someone else had
stopped working on it. The original developer has said he is going to take
maintenance of the library back, but has not yet done so. So, at the moment,
there isn't a good way to accomplish that.

Additionally, the Ubuntu release that is currently in development is well past
the upstream version freeze and taking bug fixes only at the moment, so with
the patch, I should be able to get that fielded relatively quickly.

Thank you for your contribution. The patch looks quite reasonable. I'll see
what I can do to get it included.

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

> Surely you have considered this, but what is the rationale for pushing
> to distributions SPF implementations that are not known, according to
> <http://www.openspf.org/Implementations>, to fully comply with rfc
> 4408?

What exactly are the things that lead to non-compliance? Are they
listed somewhere?

> Will the package documentation point out that it does or does not
> comply fully with the specification or has or has not passed the
> current test suite?

The output of this test suite maybe?

> BTW don't we want to read "comply" where "conform" is written in

> ... there are currently two library implementations that are
> known to _fully conform_ to the final SPFv1 specification (RFC
> 4408)

I'm trying to understand the difference between "comply" and "fully
conform"
in this context (my native language not being English), could you
please shed some light on that?





-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

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

Thomas Jacob wrote:
> > BTW don't we want to read "comply" where "conform" is written in
> >
> > ... there are currently two library implementations that are
> > known to _fully conform_ to the final SPFv1 specification (RFC
> > 4408)
>
> I'm trying to understand the difference between "comply" and "fully
> conform" in this context (my native language not being English), could
> you please shed some light on that?

I don't think there is any. What makes you think otherwise?

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

iD8DBQFF+W3ewL7PKlBZWjsRAgovAJ0XquRtveU/UA8XXDWyeGcnd+iSsQCggGTA
AU9sk002zUknbk73oDdi4TI=
=unID
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Thursday 15 March 2007 11:46, Thomas Jacob wrote:
> > Surely you have considered this, but what is the rationale for pushing
> > to distributions SPF implementations that are not known, according to
> > <http://www.openspf.org/Implementations>, to fully comply with rfc
> > 4408?
>
> What exactly are the things that lead to non-compliance? Are they
> listed somewhere?

No. The problem is that libspf2 was completed before RFC 4408 were published.

There are two areas that I know of where it is non-compliant:

1. Result names - libspf2 still uses the pre-RFC result names of unknown and
error. In RFC 4408 terms unknown = permerror and error = temperror.

2. Processing limits - unlike other pre-RFC 4408 libraries, libspf2 at least
uses the same processing limit structure (other libraries used a recursion
depth limit) and so if someone would evaluate that code it should be
relatively straightforward to identify and patch libspf2 to align it to RFC
4408 (as your patch did with MX limits), but no one has done a review of all
the limits to determine what all the required changes are.

There are probably others, but they are likely all low probability corner
cases.

> > Will the package documentation point out that it does or does not
> > comply fully with the specification or has or has not passed the
> > current test suite?
>
> The output of this test suite maybe?

The current test suite requires a library specific driver that no one has
written for libspf2, and so this is unknown. There is a test suite for
libspf2, but it is based on pre-RFC requirements (the relevant tests from it
were brought forward into the current test suite).

> > BTW don't we want to read "comply" where "conform" is written in
> >
> > ... there are currently two library implementations that are
> > known to _fully conform_ to the final SPFv1 specification (RFC
> > 4408)
>
> I'm trying to understand the difference between "comply" and "fully
> conform"
> in this context (my native language not being English), could you
> please shed some light on that?

Well, English is my native language and I don't know what he was getting at
either.

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Thu 15 Mar 2007 13:08:57 Scott Kitterman wrote:
> On Thursday 15 March 2007 11:46, Thomas Jacob wrote:
> > > Surely you have considered this, but what is the rationale for pushing
> > > to distributions SPF implementations that are not known, according to
> > > <http://www.openspf.org/Implementations>, to fully comply with rfc
> > > 4408?
> >
> > What exactly are the things that lead to non-compliance? Are they
> > listed somewhere?
>
> No. The problem is that libspf2 was completed before RFC 4408 were
> published.
>
> There are two areas that I know of where it is non-compliant:
>
> 1. Result names - libspf2 still uses the pre-RFC result names of unknown
> and error. In RFC 4408 terms unknown = permerror and error = temperror.
>
> 2. Processing limits - unlike other pre-RFC 4408 libraries, libspf2 at
> least uses the same processing limit structure (other libraries used a
> recursion depth limit) and so if someone would evaluate that code it should
> be relatively straightforward to identify and patch libspf2 to align it to
> RFC 4408 (as your patch did with MX limits), but no one has done a review
> of all the limits to determine what all the required changes are.
>
> There are probably others, but they are likely all low probability corner
> cases.

It seems to support some modifiers not in the RFC (default= is one).

--
 ("\''/").__..-''"`-. .         Roberto Alsina
 `9_ 9  )   `-. (    ).`-._.`)  ralsina@kde.org
 (_Y_.)' ._   ) `._`.  " -.-'   KDE Developer (MFCH)
  _..`-'_..-_/ /-'_.'
(l)-'' ((i).' ((!.'   Buenos Aires - Argentina

Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it. --Brian W. Kernighan

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Thu, 2007-03-15 at 17:01 +0100, Julian Mehnle wrote:
> > > BTW don't we want to read "comply" where "conform" is written in
> > >
> > > ... there are currently two library implementations that are
> > > known to _fully conform_ to the final SPFv1 specification (RFC
> > > 4408)
> >
> > I'm trying to understand the difference between "comply" and "fully
> > conform" in this context (my native language not being English), could
> > you please shed some light on that?
>
> I don't think there is any. What makes you think otherwise?

This part:
--> BTW don't we want to read "comply" where "conform" is written in



-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

> > 1. Result names - libspf2 still uses the pre-RFC result names of unknown
> > and error. In RFC 4408 terms unknown = permerror and error = temperror.
> >
> > 2. Processing limits - unlike other pre-RFC 4408 libraries, libspf2 at
> > least uses the same processing limit structure (other libraries used a
> > recursion depth limit) and so if someone would evaluate that code it should
> > be relatively straightforward to identify and patch libspf2 to align it to
> > RFC 4408 (as your patch did with MX limits), but no one has done a review
> > of all the limits to determine what all the required changes are.
> >
> > There are probably others, but they are likely all low probability corner
> > cases.
>
> It seems to support some modifiers not in the RFC (default= is one).

Bottom line though this shouldn't affect libspf2's interoperability
with other fully RFC compliant SPF implementations (apart
from maybe the limits issue), or am I mistaken here?


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Thursday 15 March 2007 13:46, Thomas Jacob wrote:

> > It seems to support some modifiers not in the RFC (default= is one).
>
> Bottom line though this shouldn't affect libspf2's interoperability
> with other fully RFC compliant SPF implementations (apart
> from maybe the limits issue), or am I mistaken here?

That is correct. This is not even a 'violation' of the RFC as RFC 4408 has
explicit allowance for addition of unknown modifiers later.

The result names are only problematic for programs calling libspf2 within a
system. This is an integration issue that is minor (libspf2 is well
documented and so as long as an integrator RTFM, the shouldn't be a problem).
It is not an interoperability concern.

Processing limits are, as you said, the core interoperablity issue here. BTW,
I've submitted your patch to Ubuntu.

Thanks again,

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Thu, 15 Mar 2007, Scott Kitterman wrote:

> That is correct. This is not even a 'violation' of the RFC as RFC 4408 has
> explicit allowance for addition of unknown modifiers later.

However, modifiers aren't allowed to change the SPF result, which
'default=' does. I'll have to add a test:

testdefault.example.com: IN TXT "v=spf1 default=pass"

which had better result in neutral.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Thursday 15 March 2007 13:58, Stuart D. Gathman wrote:
> On Thu, 15 Mar 2007, Scott Kitterman wrote:
> > That is correct. This is not even a 'violation' of the RFC as RFC 4408
> > has explicit allowance for addition of unknown modifiers later.
>
> However, modifiers aren't allowed to change the SPF result, which
> 'default=' does. I'll have to add a test:
>
> testdefault.example.com: IN TXT "v=spf1 default=pass"
>
> which had better result in neutral.

Good point.

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

>>>>> "Thomas" == Thomas Jacob
>>>>> "Re: Re: Softfail when spf-checking mails from this list, max_dns_mx=5"
>>>>> Thu, 15 Mar 2007 16:46:33 +0100

>> BTW don't we want to read "comply" where "conform" is written
>> in

>> ... there are currently two library implementations that are
>> known to _fully conform_ to the final SPFv1 specification (RFC
>> 4408)

Thomas> I'm trying to understand the difference between "comply"
Thomas> and "fully conform" in this context (my native language
Thomas> not being English), could you please shed some light on
Thomas> that?

The first definition given by my American Heritage Dictionary (1st
Ed)[1] for each of these words differ:

comply
1. To act in accordance with a command, request, rule, wish, or
the like. Used with _with_.

conform
1. To come to have the same form or character.

Indeed, _conform_ has a secondary meaning, "to act or be in accord or
agreement; to comply." That is however only a secondary meaning.
Many may agree that _comply_ has a much stronger connotation of
constraint or compulsion[2]. AFIK, in well edited contemporary
writing, we normally see compliance with standards but seldom if ever
conformance thereto.

Like standards, dictionaries are wonderful in that there are many from
which to choose[3]:

,----[ Merriam-Webster - http://tinyurl.com/2ggtur ]
comply
One entry found for comply.
Main Entry: com·ply
Pronunciation: k&m-'plI
Function: intransitive verb
Inflected Form(s): com·plied; com·ply·ing
Etymology: Italian complire, from Spanish cumplir to complete, perform
what is due, be courteous, modification of Latin complEre to complete
1 obsolete : to be ceremoniously courteous
2 : to conform, submit, or adapt (as to a regulation or to another's
wishes) as required or requested <comply with federal law> <the
devices comply with industry standards>
`----
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <<<<<<<< !!!!!!!!

,----[ Merriam-Webster - http://tinyurl.com/2tgu92 ]
conform
One entry found for conform.
Main Entry: con·form
Pronunciation: k&n-'form
Function: verb
Etymology: Middle English, from Anglo-French conformer, from Latin
conformare, from com- + formare to form, from forma form
transitive verb : to give the same shape, outline, or contour to :
bring into harmony or accord <conform furrows to the slope of the
land>
intransitive verb
1 : to be similar or identical; also : to be in agreement or harmony
-- used with to or with <changes that conform with our plans>
2 a : to be obedient or compliant -- usually used with to <conform to
another's wishes> b : to act in accordance with prevailing standards
or customs <the pressure to conform>
synonym see ADAPT
- con·form·er noun
- con·form·ism /-'for-"mi-z&m/ noun
- con·form·ist /-mist/ noun or adjective
`----

,----[ TheFreeDictionary - http://tinyurl.com/yr5n5r ]
com·ply Pronunciation (km-pl)
intr.v. com·plied, com·ply·ing, com·plies
1. To act in accordance with another's command, request, rule, or
wish: The patient complied with the physician's orders.
2. Obsolete To be courteous or obedient.
`----

,----[ TheFreeDictionary - http://tinyurl.com/2fgkle ]
con·form Pronunciation (kn-fôrm)
v. con·formed, con·form·ing, con·forms
v.intr.
1. To correspond in form or character; be similar.
2. To act or be in accord or agreement; comply: a computer that
conforms to the manufacturer's advertising claims. See Synonyms at
agree.
3. To act in accordance with current customs or modes. See Synonyms at
adapt.
v.tr.
To bring into agreement or correspondence; make similar.
`----

HTH

jam

Footnotes:
[1] Now in the 4th Edition at <http://tinyurl.com/yvs5cb>.

[2] Except in English History with reference to conformity and the
Church of England.

[3] See also: <http://dictionary.reference.com/browse/en:comply> and
<http://dictionary.reference.com/browse/en:conform>.



-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

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

Thomas Jacob wrote:
> Julian Mehnle wrote:
> > > > BTW don't we want to read "comply" where "conform" is written in
> > > >
> > > > ... there are currently two library implementations that
> > > > are known to _fully conform_ to the final SPFv1 specification (RFC
> > > > 4408)
> > >
> > > I'm trying to understand the difference between "comply" and "fully
> > > conform" in this context (my native language not being English),
> > > could you please shed some light on that?
> >
> > I don't think there is any. What makes you think otherwise?
>
> This part:
> --> BTW don't we want to read "comply" where "conform" is written in

That was a question by John A. Martin. That question doesn't make "comply"
and "fully conform" have separate meanings.

As a matter of fact, it was _me_ who wrote that part[1] of <http://www.
openspf.org/Implementations>, and my intent was to put the fully confor-
ming implementations "pyspf 2.0" and "Mail::SPF" in contrast to the NOT
fully conforming legacy implementation "Mail::SPF::Query". Thus I can say
with certainty that no difference between "comply" and "fully conform" was
intended. I don't get where anyone sees such a difference. (Note that I
am not a native English speaker, though.)

References:
1. http://www.openspf.org/?action=browse&diff=1&id=Implementations&revision=87&diffrevision=86

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

iD8DBQFF+egJwL7PKlBZWjsRAlU1AJsHI0mjkUXicVF11/BvI23OO/g72wCffgcy
xmgi4yT5DHzLCfUFyLs1QB8=
=UILe
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

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

Stuart D. Gathman wrote:
> On Thu, 15 Mar 2007, Scott Kitterman wrote:
> > That is correct. This is not even a 'violation' of the RFC as RFC
> > 4408 has explicit allowance for addition of unknown modifiers later.
>
> However, modifiers aren't allowed to change the SPF result, [...]

Where do you take that from?

http://www.openspf.org/RFC_4408#evaluation-mod

I agree however that modifiers changing the SPF result is generally a bad
idea from a design perspective. Given that the "redirect=" _modifier_
really should have been a "redirect:" _mechanism_, this concept isn't
being violated all that badly...

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

iD8DBQFF+elVwL7PKlBZWjsRAieYAJ9EA+bXY64TfyMTGujn3EgoDVD3kQCg3RQG
DJ58Z7Dq6azOumn4JmGxmRQ=
=PYXf
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

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

John A. Martin wrote:
> > I'm trying to understand the difference between "comply" and "fully
> > conform" in this context (my native language not being English), could
> > you please shed some light on that?
>
> The first definition given by my American Heritage Dictionary (1st
> Ed)[1] for each of these words differ:
>
> comply
> 1. To act in accordance with a command, request, rule, wish, or
> the like. Used with _with_.
>
> conform
> 1. To come to have the same form or character.
>
> [...]

I think you're taking the nit-picking much too far. ;-)

Seriously, do you think the current wording of <http://www.openspf.org/
Implementations> is ambiguous or misleading? Unless that's the case, I
think this debate is a waste of time.

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

iD8DBQFF+eq7wL7PKlBZWjsRAucAAJ9La163BYKnSQ+izRkkk+tFXM8KPACcCLor
Ldy9c62RJOr/BP3XU/wZrv8=
=a7+i
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

John A. Martin wrote:

> Indeed, _conform_ has a secondary meaning, "to act or be in accord
> or agreement; to comply." That is however only a secondary meaning.

In an IT context "conformance testing" is a well-known term. I have
not yet read "compliance testing" anywhere.

> Like standards, dictionaries are wonderful in that there are many
> from which to choose

Yeah, sometimes I use en-gb-oed as language tag just for fun... :-)

Google test (using the phrases, i.e. with quotes):

"conformance test" 368,000 Limited to IETF: 706
"compliance test" 456,000 Limited to IETF: 99

Frank


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Wednesday 14 March 2007 12:05, Thomas Jacob wrote:
...
> I've attached a patch that increases the MX/PTR limit to 10.

Thank you for your contribution. An update that includes the patch has been
released for the next Ubuntu version (currently just about to go to beta
release).

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735