Mailing List Archive

Mfrom (was: Mail::SPF pre-release -- please review and test!)
Julian Mehnle wrote:

> 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

That's dubious, the "mfrom scope" (spf2.0/mfrom) checks HELO identity
and MAIL FROM identity as specified in 4408 (v=spf1). RFC 4406 got
that wrong, but at least it still uses the term "MAIL FROM identity".

The Received-SPF header definition intentionally uses the correct
4408 terms, not the scope mishmash of RFC 4406, where it's unclear
WTF %h might be, especially when checking a PRA. We're not collecting
4406-errata, but that would be one the errors.

> I think that "mfrom" makes a better (since shorter) scope name

I think that publishing "spf2.0/mfrom" today, without an equivalent
"v=spf1", is a bad idea. The identity in your case is a MAIL FROM.
The scope is "v=spf1", also known as SMTP. For a scope "mfrom" it's
less clear.

> the local explanation is just a free form explanation.

We should have said "envelope-sender" as in the DSN RFCs, it's longer
than MAIL FROM, but better reflects that it can be different from the
2822-From. If something already has eight names adding "mfrom" as a
8th name IMO doesn't help. (MAIL FROM + 2821-From + reverse path +
Return-Path + envelope from + envelope sender + originator, probably
I missed some aliases)

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

Yes, IIRC I threatened "over my dead body" when Wayne wrote "scope".
That's the language of the enemy, not much better than "bounces-to".
Sometimes terminology is important, e.g. "ADMD" vs. "MON" + "MRN".

With "ADMD" you get MTAs scattered everywhere doing some forwarding
magic, sometimes changing the RCPT TO because they feel like it. With
"MON" and "MRN" you get IMO better abstractions of SMTP based on the
MX-concept. Also better for SPF, no surprise.

"Scope" is a similar beast, folks dream up wild and wonderful scopes,
like helo, pra, from, mfrom, submit, and what else.

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
Re: Mfrom [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Ellermann wrote:
> Julian Mehnle wrote:
> > 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
>
> That's dubious, the "mfrom scope" (spf2.0/mfrom) checks HELO identity
> and MAIL FROM identity as specified in 4408 (v=spf1). RFC 4406 got
> that wrong, but at least it still uses the term "MAIL FROM identity".

No. I thought there was a consensus that RFC 4406 didn't support a "helo"
scope per se, but only (implicitly) if the MAIL FROM was empty. RFC 4406
merely says:

| This document only defines the existence of two scopes: "mfrom" and
| "pra". The details of these two scopes are defined in other
| documents: "mfrom" is defined in [RFC4408]; "pra" is defined in
| [RFC4407].

and:

| A scope of "pra" (for the PRA variant of the test), or "mfrom" (for the
| MAIL FROM variant of the test).

> The Received-SPF header definition intentionally uses the correct
> 4408 terms, not the scope mishmash of RFC 4406, where it's unclear
> WTF %h might be, especially when checking a PRA. We're not collecting
> 4406-errata, but that would be one the errors.

Well, yeah, that's a design bug in RFC 4406, which should have specified
the %{h} macro to be illegal in macro string expansions in the context of
PRA checks (i.e. that either separate macro strings and thus "spf2.0"
records must be used for the "mfrom" and "pra" scopes, or no %{h} macro
must be used at all).

In the context of "pra" scope checks, Mail::SPF chooses to expand the %{h}
macro to whatever was specified as the "helo_identity" Mail::SPF request
option or to "unknown" if nothing was specified. I think that's a sane
behavior.

> > I think that "mfrom" makes a better (since shorter) scope name
>
> I think that publishing "spf2.0/mfrom" today, without an equivalent
> "v=spf1", is a bad idea.

Well, perhaps. But that's nothing that Mail::SPF can do anything about.

> The identity in your case is a MAIL FROM. The scope is "v=spf1", also
> known as SMTP. For a scope "mfrom" it's less clear.

The Mail::SPF docs[1] make it quite explicit what the various scopes mean:

| scope
|
| A string denoting the authorization scope of the identity that should
| be checked. Defaults to 'mfrom'. The following scope values are
| supported:
|
| 'helo'
| The given identity is the HELO parameter of an SMTP transaction
| (RFC 2821) and should be checked against SPF records that cover
| the "helo" scope ("v=spf1"). See the SPFv1 specification (RFC
| 4408) for the formal definition of the HELO scope.
|
| 'mfrom'
| The given identity is the MAIL FROM parameter of an SMTP
| transaction (RFC 2821), or, in the case of an empty MAIL FROM
| parameter ("MAIL FROM:<>"), derived from the transaction's HELO
| parameter, and should be checked against SPF records that cover
| the "mfrom" scope ("v=spf1" and "spf2.0/mfrom"). See the SPFv1
| specification (RFC 4408) for the formal definition of the MAIL
| FROM scope.
|
| 'pra'
| The given identity is the "Purported Responsible Address" of an
| internet message (RFC 2822) and should be checked against SPF
| records that cover the "pra" scope ("spf2.0/pra"). See the PRA
| specification (RFC 4407) for the formal definition of the PRA
| scope.

Mail::SPF actually leaves it to the caller to perform a "helo" check
directly if the MAIL FROM is empty.

Or perhaps I'm just missing your point.

> > the local explanation is just a free form explanation.
>
> We should have said "envelope-sender" as in the DSN RFCs, it's longer
> than MAIL FROM, but better reflects that it can be different from the
> 2822-From. If something already has eight names adding "mfrom" as a
> 8th name IMO doesn't help. (MAIL FROM + 2821-From + reverse path +
> Return-Path + envelope from + envelope sender + originator, probably
> I missed some aliases)

I think "2821.mfrom" or something would have been most clear, but among SPF
developers, "mfrom" should still be sufficiently clear. I may change
Mail::SPF (_after_ the first gold release) to accept (and recommend)
"2821.helo", "2821.mfrom", and "2822.pra", though (and the old scope names
would still be accepted, too).

> > 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.
>
> Yes, IIRC I threatened "over my dead body" when Wayne wrote "scope".
> That's the language of the enemy, not much better than "bounces-to".
> [...]
> "Scope" is a similar beast, folks dream up wild and wonderful scopes,
> like helo, pra, from, mfrom, submit, and what else.

Sorry, I cannot follow your complaint here. I think "scope" is a good name
for the concept of identity types. Perhaps you should try to come up with
a better one first before complaining.

References:
1. http://search.cpan.org/dist/Mail-SPF-2.000_003/lib/Mail/SPF/Request.pm#new

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

iD8DBQFFceddwL7PKlBZWjsRAmAPAKD52t7q+oZo0Xcrq2DReZB4EUZS1QCeMPNo
QvulIEnVFlUEqPjFKSBe0So=
=Rung
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
Re: Mfrom [ In reply to ]
Julian Mehnle wrote:

> I thought there was a consensus that RFC 4406 didn't support a "helo"
> scope per se, but only (implicitly) if the MAIL FROM was empty.

It's hard to judge what the co-author had in his mind, after all he
managed to have a SHOULD conflicting with a NOT RECOMMENDED in two
RFCs with his name on it... ;-)

But we're sure that HELO can be always checked if the MAIL FROM is
empty, therefore it was always an option, therefore it was upgraded
to a SHOULD, and the proponent of the latter was Meng.

I guess that he didn't intend to introduce a bogus difference between
v=spf1 and spf2.0/mfrom when he proposed the SHOULD, and therefore I
think _our_ consensus (minus Andy's MAAWG considerations) was that
v=spf1 and spf2.0/mfrom (modulo positional modifiers) are equivalent.

No positional modifier exists, therefore they're semantically 100%
identical. Does that in any way differ from your view, or from what
you've implemented as spf2.0/mfrom ?

> | "mfrom" is defined in [RFC4408]

IMO that's "spf2.0/mfrom" == "v=spf1" (modulo positional parameter)

Mark's positional parameter was added to spf2.0 because some folks
including Meng and me liked it (at that time, today it's clear that
this was a waste of time, because nobody uses it).

> Well, yeah, that's a design bug in RFC 4406, which should have
> specified the %{h} macro to be illegal in macro string expansions
> in the context of PRA checks

ACK, that screw-up was a side-effect of the MARID disaster, at some
point we considered spf2.0/helo, and %h was removed, also from the
emergency v=spf1 draft. Wayne immediately added it again, but I'm
not sure that the SenderID folks (excl. Meng) ever looked carefully
into the earlier or later v=spf1 drafts.

> In the context of "pra" scope checks, Mail::SPF chooses to expand
> the %{h} macro to whatever was specified as the "helo_identity"

You also do PRA ? I vaguely recall a statement that you only wanted
to implement "mfrom". Are there more interesting features, do you
honour op=pra by chance ?

The test suite is, putting it mildly, incomplete for PRA and spf2.0,
or did you add that already ?

> "unknown" if nothing was specified. I think that's a sane behavior.

How about "invalid" / "test" / "example" / "localhost" ? The chances
for a TLD "unknown" are lousy, and it's a missing-dot-syntax-error in
2821 and 2821bis (John's private -01 copy, not the published -00 I-D),
but my gut feeling is to stay away from strings like "unknown".

I missed that in RFC 4408 for %p, tough. In USEFOR we finally decided
that "posted" / "mismatch" / "seen" are bad ideas as "pseudo-domains",
and found another syntax, not depending on ICANN's good will. Took us
(USEFOR) some months, maybe that's why I missed the "unknown" here ;-)

>> I think that publishing "spf2.0/mfrom" today, without an equivalent
>> "v=spf1", is a bad idea.

> Well, perhaps. But that's nothing that Mail::SPF can do anything about.

ACK. But you should seriously consider to support op=pra. Otherwise
publishers deciding that they don't like to tell the same story *four*
times would be forced to use spf2.0/pra,mfrom (or spf2.0/mfrom,pra),
not checked by "classic" implementations. Missing willing checkers is
a Bad Thing for the overall effect wrt forged MAIL FROMs.

>| 'helo'
>| The given identity is the HELO parameter of an SMTP transaction
>| (RFC 2821) and should be checked against SPF records that cover
>| the "helo" scope ("v=spf1"). See the SPFv1 specification (RFC
>| 4408) for the formal definition of the HELO scope.

In v=SPF1 terminology that's no scope, but an identity, defined in 2.1.

>| 'mfrom'
>| The given identity is the MAIL FROM parameter of an SMTP
>| transaction (RFC 2821), or, in the case of an empty MAIL FROM
>| parameter ("MAIL FROM:<>"), derived from the transaction's HELO
>| parameter, and should be checked against SPF records that cover
>| the "mfrom" scope ("v=spf1" and "spf2.0/mfrom"). See the SPFv1
>| specification (RFC 4408) for the formal definition of the MAIL
>| FROM scope.

In v=SPF1 terminology that's an identity, defined in 2.2. In spf2.0
terminology it's a scope, covering all of RFC 4408 (see above), with
checks of the MAIL FROM identity and (SHOULD) the HELO identity.

IMO %h in spf2.0/mfrom (+ variants) policies is okay, and calling
check_host() with an undefined %h for v=spf1 or spf2.0/mfrom is an
error like forgetting to specify the connecting IP.

In RFC 4408 check_host() has three arguments, scope isn't one of the
three arguments. Admittedly %h is a kind of 4th argument, but it
should work with three arguments + some kind of %h ("unknown" etc.)
also for PRA, no scope needed. Check_host() doesn't need to know
what it's really checking, HELO, MAIL FROM, or PRA. Is that still
correct, or did I miss something about the scope here ? %d is a
different story, implemented in various ways, none of them related
to some scope.

In RFC 4408 terminology it's really "identity", not "scope". At worst
it's "sender" in 4.1, that's also fine for the three checked identities.

> perhaps I'm just missing your point.

RFC 4408 carefully avoids to use the term "scope", because it's coupled
with some really long and exhausting rat-holes examined on the "discuss"
list, for months, again and again. The "submit scope", the "from scope",
the "ptr scope", and in one of my more ironical articles I proposed a
"message-id scope" (and I'm still not sure if it's complete nonsense ;-)

For SSP (DKIM) they're at it again, claiming that some "from scope"
exists, and that a domain owner can regulate the use of his 2822-From
in e-mail (all of it, news2mail, resend, mailing lists, and what else).

> among SPF developers, "mfrom" should still be sufficiently clear.

Yeah, but you might mention Meng's SHOULD somewhere, IIRC that was an
unanimous decision including your vote, with published minutes and
resolution. If receivers don't check HELO for v=spf1 or spf2.0/mfrom
they're confused. I can understand to check only HELO, neither PRA
nor MAIL FROM, but not checking HELO when it's possible just makes no
sense. When could that be a good idea, excl. the obvious spf2.0/pra ?

> I think "scope" is a good name for the concept of identity types.
> Perhaps you should try to come up with a better one first before
> complaining.

Identity, as in RFC 4408, is a good name. For the first word at the
begin of SPF records, "v=spf1", "spf2.0/mfrom", etc. (three others
at the moment), I'd say "tag" or "record-tag". Only three of these
tags are actually different:

1: "v=spf1", in practice the same as "spf2.0/mfrom"
2: "spf2.0/pra"
3: "spf2.0/pra,mfrom" == "spf2.0/mfrom.pra", i.e. both (1) and (2)

New tags could use an entirely different syntax with new mechanisms,
e.g. a tag "spf3/signature" could talk about public keys. New tags
could also talk about the same identities like v=spf1, but using a
simplified and/or upgraded syntax.

Where you have "identity" now you could use "sender" (as in RFC 4408),
and then "identity" is free for what you have as "scope" now.

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
Re: Mfrom [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Ellermann wrote:
> Julian Mehnle wrote:
> > In the context of "pra" scope checks, Mail::SPF chooses to expand
> > the %{h} macro to whatever was specified as the "helo_identity"
>
> You also do PRA ?

Mail::SPF does support evaluating SPF records within a PRA scope context,
yes. It does not implement the patented PRA algorithm, though.

> Are there more interesting features, do you honour op=pra by chance ?

Mail::SPF does not currently support the "op=" modifier. I might add that
at a later time, though.

> The test suite is, putting it mildly, incomplete for PRA and spf2.0,
> or did you add that already ?

No. As I said, Mail::SPF doesn't implement the PRA algorithm as such, so
there is little to test additionally for that. I have a stub test suite
for RFC 4406, though, that has two tests about "spf2.0" and "spf2.0 vs.
v=spf1" record selection.

> > "unknown" if nothing was specified. I think that's a sane behavior
> > [for expanding the %{h} macro].
>
> How about "invalid" / "test" / "example" / "localhost" ? The chances
> for a TLD "unknown" are lousy, and it's a missing-dot-syntax-error in
> 2821 and 2821bis (John's private -01 copy, not the published -00 I-D),
> but my gut feeling is to stay away from strings like "unknown".

"unknown" is what RFC 4408 specifies for impossible expansions of the %{p}
and %{r} macros as well, so I assumed it was an acceptable choice.

> > | 'helo'
> > | The given identity is the HELO parameter of an SMTP transaction
> > | (RFC 2821) and should be checked against SPF records that cover
> > | the "helo" scope ("v=spf1"). See the SPFv1 specification (RFC
> > | 4408) for the formal definition of the HELO scope.
>
> In v=SPF1 terminology that's no scope, but an identity, defined in 2.1.

In RFC 4408, a "HELO identity" is, for example, "mta.example.com".
However, "HELO" is not an identity -- it is the _type_ of the identity.
I am using "scope" as a synonym for "identity type", which is what RFC 4406
does. Also this does not generally conflict with the terminology of RFC
4408, except for the very specific case of the "identity" R-SPF header
information key name.

> > | 'mfrom'
> > | The given identity is the MAIL FROM parameter of an SMTP
> > | transaction (RFC 2821), or, in the case of an empty MAIL FROM
> > | parameter ("MAIL FROM:<>"), derived from the transaction's HELO
> > | parameter, and should be checked against SPF records that cover
> > | the "mfrom" scope ("v=spf1" and "spf2.0/mfrom"). See the SPFv1
> > | specification (RFC 4408) for the formal definition of the MAIL
> > | FROM scope.
>
> In v=SPF1 terminology that's an identity, defined in 2.2. In spf2.0
> terminology it's a scope, covering all of RFC 4408 (see above), with
> checks of the MAIL FROM identity and (SHOULD) the HELO identity.

No, I don't think so. RFC 4406 talks of "the MAIL FROM variant of the
test". The separate(!) HELO check was introduced into draft-schlitt-...
_after_ draft-lyon-senderid-core was initially published. I don't think
that RFC 4406's "mfrom" scope means doing both a MAIL FROM and a separate
HELO check.

> IMO %h in spf2.0/mfrom (+ variants) policies is okay, and calling
> check_host() with an undefined %h for v=spf1 or spf2.0/mfrom is an
> error like forgetting to specify the connecting IP.

Since when is an undefined HELO identity an error in a MAIL FROM check? If
I can specify such crap as "9" or "_#!" and have "None" returned, then why
whould an empty HELO suddenly be an error?

> In RFC 4408 check_host() has three arguments, scope isn't one of the
> three arguments.

(1) You _can_ call Mail::SPF with just three parameters (ip_address,
authority_domain, identity), and (2) Mail::SPF does not implement just RFC
4408.

> Check_host() doesn't need to know what it's really checking, HELO, MAIL
> FROM, or PRA. Is that still correct, or did I miss something about the
> scope here ?

You are missing the fact that check_host() performs record selection, for
which it must know the scope/type of the given identity.

> RFC 4408 carefully avoids to use the term "scope", because it's coupled
> with some really long and exhausting rat-holes examined on the "discuss"
> list, for months, again and again. The "submit scope", the "from
> scope", the "ptr scope", and in one of my more ironical articles I
> proposed a "message-id scope" (and I'm still not sure if it's complete
> nonsense ;-)

Yes, the Message-ID could be considered a scope AKA identity type, even if
it's not very useful.

> > among SPF developers, "mfrom" should still be sufficiently clear.
>
> Yeah, but you might mention Meng's SHOULD somewhere, IIRC that was an
> unanimous decision including your vote, with published minutes and
> resolution. If receivers don't check HELO for v=spf1 or spf2.0/mfrom
> they're confused. I can understand to check only HELO, neither PRA
> nor MAIL FROM, but not checking HELO when it's possible just makes no
> sense. When could that be a good idea, excl. the obvious spf2.0/pra ?

Perhaps if you don't _care_ about the SPF result for the HELO? Then what's
the point in doing a costly SPF check on it? But apart from that,
Mail::SPF doesn't really care about the caller's motivations. You'll
always be able to call Mail::SPF in nonsensical ways if you insist.

> > I think "scope" is a good name for the concept of identity types.
> > Perhaps you should try to come up with a better one first before
> > complaining.
>
> Identity, as in RFC 4408, is a good name.
> [...]
> Where you have "identity" now you could use "sender" (as in RFC 4408),
> and then "identity" is free for what you have as "scope" now.

Perhaps you'd like to have a look at a dictionary for the meaning
of "identity". "Person" is not an identity. "Frank Ellermann" is.

This discussion doesn't lead us anywhere, though, so I'll shut up now.
If you write your own implementation, feel free to call the concept of
"identity type" by the name of "identity". :-)

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

iD8DBQFFcil9wL7PKlBZWjsRAmm/AJ4+InJmktvKyx+5i9TeVVQosYDk3ACdEksU
3GTmiPn38fqI+gUrbY05Q1E=
=8bK9
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
Re: Mfrom [ In reply to ]
Julian Mehnle wrote:

> Mail::SPF does not currently support the "op=" modifier. I might add
> that at a later time, though.

The op=pra is relevant for your general v=spf1 + spf2.0 implementation.
The rest, well, you've read it. If op=auth has merits, then certainly
not within any check_host(). The op=helo and op=nohelo mainly prove
that the absence of options has nothing to do with the opposite of
options, and that a separate "spf2.0/helo" is pointless, nobody needs
or wants this, even in the simple and painless form of an op=(no)helo.

> "unknown" is what RFC 4408 specifies for impossible expansions of the
> %{p} and %{r} macros as well, so I assumed it was an acceptable choice.

An "unknown" is no "erratum", but for 4408bis we could silently replace
it by "invalid".

> In RFC 4408, a "HELO identity" is, for example, "mta.example.com".
> However, "HELO" is not an identity -- it is the _type_ of the identity.
> I am using "scope" as a synonym for "identity type", which is what
> RFC 4406 does.

Yes, I prefer the 4408 terminology. You could also interpret identity
as key=value pairs, with key 'helo' and 'value' mta.example.com But
after a look in your docu, where you have consistently used SenderID-
terminology, changing that would be a huge effort. It could confuse
some users more familiar with 4408 SPF than 4406 SenderID terminology.

[mfrom]
>> In v=SPF1 terminology that's an identity, defined in 2.2. In spf2.0
>> terminology it's a scope, covering all of RFC 4408 (see above), with
>> checks of the MAIL FROM identity and (SHOULD) the HELO identity.

> No, I don't think so. RFC 4406 talks of "the MAIL FROM variant of the
> test". The separate(!) HELO check was introduced into draft-schlitt-...
> _after_ draft-lyon-senderid-core was initially published.

No, the MAY is older, before MARID, "SMTP+SPF receivers MAY check the
HELO argument, and MUST" (etc.) The upgrade from MAY to SHOULD came
after draft-lyon. In the SPF Council session Meng joked about "Hector
hectored us", and Hector did that before I started to read the SPF
lists (spring 2004).

The step from MAY to SHOULD later was only logical, if publishers have
to get it right anyway, then receivers should as well always use it.

> I don't think that RFC 4406's "mfrom" scope means doing both a
> MAIL FROM and a separate HELO check.

Obviously we disagree on that. Checking only MAIL FROM is a bad idea,
what's the relevant application, a sender never using an empty Return-
Path, as in MDNs and auto-replies (3834) ? Is that a sender always
using some smart hosts using different FQDNs as their Helo ? Even if
that's the case, why would he wish that any spammer can abuse his FQDN
as HELO if it's "only" protected by spf2.0/mfrom instead of v=spf1 ?

Makes no sense for me, spf2.0/mfrom and v=spf1 are equivalent, both
identities can be checked. For the same reasons. And it was Meng's
proposal to upgrade this MAY to a SHOULD. The "mfrom scope" in 4406
is v=spf1 with HELO and MAIL FROM identity. That it doesn't say so
explicitly is an accident, or maybe Mark's vision, but not Meng's or
ours. CSV-fans might love to get rid of HELO, because their solution
is better, but that's another story.

> Since when is an undefined HELO identity an error in a MAIL FROM
> check?

At least it has to be an empty string, NULL, NIL, or similar. The
caller has to assign a value to %h. Like he has to specify an IP,
a sender, and a domain. I.e. %h, %i, %s, and %d. The other macro
values can be derived from those four values, if they're "valid" to
some degree, check_host() can't get %v if %i is "17" or "foo".

> why whould an empty HELO suddenly be an error?

I had something else in mind when I wrote "undefined". For a PRA
check it's hard to to figure out some %h. The caller could still
use a special empty %h value, to distinguish that situation from an
empty or missing HELO. Clear syntax errors, should never arrive in
check_host(), but of course shit happens.

>> Check_host() doesn't need to know what it's really checking,
>> HELO, MAIL FROM, or PRA. Is that still correct, or did I miss
>> something about the scope here ?

> You are missing the fact that check_host() performs record
> selection, for which it must know the scope/type of the given
> identity.

ACK, it has to find the corresponding "tags" (in my terminology,
the "scopes" in SenderID). Kind of tricky if you find both v=spf1
and some spf2.0 combo with "mfrom". What do you do, first come,
first served ?

> Yes, the Message-ID could be considered a scope AKA identity type,
> even if it's not very useful.

But also not much worse than the PRA, and maybe better than some
SSP From-ideas. I'd be pissed if somebody abuses "my" domain in
their Message-IDs, the spammers love everything with an "@". And
a Message-ID collision could also cause damage in NetNews.

>> I can understand to check only HELO, neither PRA nor MAIL FROM,
>> but not checking HELO when it's possible just makes no sense.
>> When could that be a good idea, excl. the obvious spf2.0/pra ?

> Perhaps if you don't _care_ about the SPF result for the HELO?
> Then what's the point in doing a costly SPF check on it?

But one potential HELO FAIL is much cheaper than checking all the
MAIL FROMs in that SMTP session with a spammer. After a HELO FAIL
it's clear that you're talking with a liar, or the policy is wrong.

And you need that result anyway if there's only one empty reverse
path in the SMTP session. It's the same idea as "ptr", a decent MX
already has the answer in its DNS cache, because it checked the
HELO and IP for its timestamp line, before SPF. And then "ptr" is
relatively cheap, or is this wrong ? Any number of "ptr" actually.

> Mail::SPF doesn't really care about the caller's motivations.

Sure, but documenting how to get it right, normally, helps.

> If you write your own implementation, feel free to call the
> concept of "identity type" by the name of "identity". :-)

No temptation. I wouldn't use the word "scope" in a 4408bis draft,
that's more tempting, sometimes I think that RFC 4408 presents an
in essence simple concept (RMX) in a too complex way.

Frank



-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
Re: Mfrom [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Ellermann wrote:
> Julian Mehnle wrote:
> > [mfrom]
> > > In v=SPF1 terminology that's an identity, defined in 2.2. In spf2.0
> > > terminology it's a scope, covering all of RFC 4408 (see above), with
> > > checks of the MAIL FROM identity and (SHOULD) the HELO identity.
> >
> > No, I don't think so. RFC 4406 talks of "the MAIL FROM variant of the
> > test". The separate(!) HELO check was introduced into draft-
> > schlitt-... _after_ draft-lyon-senderid-core was initially published.
>
> No, the MAY is older, before MARID, "SMTP+SPF receivers MAY check the
> HELO argument, and MUST" (etc.) The upgrade from MAY to SHOULD came
> after draft-lyon. In the SPF Council session Meng joked about "Hector
> hectored us", and Hector did that before I started to read the SPF
> lists (spring 2004).

Well, right, "MAY also check HELO separately" was there _before_ draft-
lyon-senderid-core. But Hector hectoring us into changing it to "SHOULD"
is irrelevant because that was an internal decision making process of the
project and MS certainly didn't base their drafts on that internal
decision making process. MS just didn't care much for the HELO, or they
would have introduced a "helo" scope.

> > You are missing the fact that check_host() performs record
> > selection, for which it must know the scope/type of the given
> > identity.
>
> ACK, it has to find the corresponding "tags" (in my terminology,
> the "scopes" in SenderID). Kind of tricky if you find both v=spf1
> and some spf2.0 combo with "mfrom". What do you do, first come,
> first served ?

If, for example, a scope of "mfrom" is specified, and both "v=spf1" and
"spf2.0/mfrom" are found, then the higher version, i.e. "spf2.0", is used.

> >> I can understand to check only HELO, neither PRA nor MAIL FROM,
> >> but not checking HELO when it's possible just makes no sense.
> >> When could that be a good idea, excl. the obvious spf2.0/pra ?
> >
> > Perhaps if you don't _care_ about the SPF result for the HELO?
> > Then what's the point in doing a costly SPF check on it?
>
> But one potential HELO FAIL is much cheaper than checking all the
> MAIL FROMs in that SMTP session with a spammer. After a HELO FAIL
> it's clear that you're talking with a liar, or the policy is wrong.

Well, why don't you go and convince all the Mail::SPF users that they
should always do a "helo" check? No harm done. ;-)

> > Mail::SPF doesn't really care about the caller's motivations.
>
> Sure, but documenting how to get it right, normally, helps.

Perhaps I'll do that, but don't hold your breath. Too many more important
things to do. :-/

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

iD8DBQFFcrQBwL7PKlBZWjsRAjkqAJwPryRPStN1399Yvkz7QPJLoglUjQCfYds4
mvZphoXs2vsOhWSB2LK8nis=
=cREd
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
Re: Re: Mfrom [ In reply to ]
On Sunday 03 December 2006 01:34, Frank Ellermann wrote:

> No, the MAY is older, before MARID, "SMTP+SPF receivers MAY check the
> HELO argument, and MUST" (etc.) The upgrade from MAY to SHOULD came
> after draft-lyon. In the SPF Council session Meng joked about "Hector
> hectored us", and Hector did that before I started to read the SPF
> lists (spring 2004).
>
> The step from MAY to SHOULD later was only logical, if publishers have
> to get it right anyway, then receivers should as well always use it.

Yes, but the lack of HELO scope in SPF2.0 is by design (good or bad, it was
intentional). There is, IIRC, room for additional scopes, all someone needs
to do is write a draft and publish it.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
Re: Mfrom [ In reply to ]
Scott Kitterman wrote:

> the lack of HELO scope in SPF2.0 is by design (good or bad, it was
> intentional).

It *_was_* intentional for some hectic days short before MARID was
killed, because CSV and SPF weren't on topic at this time. But as
demonstrated it's technically bogus. These "intentions" were only
political, they make no sense in practice.

> all someone needs to do is write a draft and publish it.

That person better invests her energy in improving the Leibniz-draft,
getting more IPs with a "new" IPv4 than we have today in IPv6 is a
major scientific breakthrough... <eg>

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
Re: Re: Mfrom [ In reply to ]
On Monday 04 December 2006 10:44, Frank Ellermann wrote:
> Scott Kitterman wrote:
> > the lack of HELO scope in SPF2.0 is by design (good or bad, it was
> > intentional).
>
> It *_was_* intentional for some hectic days short before MARID was
> killed, because CSV and SPF weren't on topic at this time. But as
> demonstrated it's technically bogus. These "intentions" were only
> political, they make no sense in practice.
>
Agreed. Let's just not pretend that it's hiding in there somewhere for us to
find it. It's not there and it SPF2.0 wants to be taken seriously (not
recommended in my book) then someone needs to add it back.

Scott K

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