Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02

[Hallam-Baker, Phillip]

Behalf Of Andrew Newton
If this is the source of the conflict, then BOTH experiments should
not use the v=spf1 records.

Which would at the same time provide an opportunity to address the one
part of SPF/Sender-ID that does give me significant concern, the
exclusive appropriation of the TXT record.

A prefixed record would be much less likely to collide with other
records.

A proposal has been made to cut an new RR but as the group discovered
50% of the legacy infrastructure does not support new RRs despite claims
to the contrary. Support in this case has to be production quality, not
the ability to coax particular bits out of a server in certain limited
circumstances that no network admi is ever going to accept on a
production server.


The main objection to prefixed records is that they do not work with
wildcards. This is actually a failure of imagination rather than fact.
It is quite possible to develop a resolution procedure for prefix
records that works acceptably with legacy DNS resolvers and meets the
needs of network admins.

The first step is to address the problem that wildcards do not match an
existing node. As was demonstrated on the list this is easily solved
using a macro processor.

The second step is how to create a wildcard for _prefix.*.example.com
without changing legacy DNS servers.

The way to do this is to introduce a pointer record using CNAME as
follows:

_prefix.exists.example.com TXT "Policy1"
*.example.com CNAME _wildcard.example.com
_prefix._wildcard.example.com TXT "Policy2"

The resolution algorithm for domain X is:

1) Check for a TXT record for _prefix.X if it exists, return the TXT
string and stop

2) Check for a CNAME at X, if it does not exist return 'NIL' and stop

3) Check for a TXT record for _prefix.Y where Y is the CNAME mapping. If
it exists return the TXT string, otherwise stop.

Applying these rules to the scheme above we get:

Lookup ("exists.example.com", "prefix") = "Policy1" [cost 1 lookup]
Lookup ("empty.example.com", "prefix") = "Policy2" [cost 3 lookups]
Lookup ("empty.example.com", "noprefix") = NIL [cost 3 lookups]

This algorithm is 100% compatible with the deployed, legacy DNS and
meets all use cases that were proposed for wildcarding. It never takes
more than three DNS lookups. The first two can be requested in parallel,
an intelligent DNS server could return the CNAME as an additional record
for optimization purposes.

If this mechanism was adopted as policy for ALL prefixed records there
would no longer be any need to define new RRs unless there was a need to
define a new record syntax. It would also allow admins to manage their
policy records much more effectively, the default node is treated as if
it was just another node.


If folk really want to argue over the SPF=1 issue I think that they are
saying that the protocol is not really embedded enough to be beyond
change. If that is the case I think that we should fix the problem
caused by the exclusive appropriation of TXT.

[wayne]

[PHB brainstorms about a new protocol...]
The main objection to prefixed records is that they do not work with
wildcards. This is actually a failure of imagination rather than fact.
It is quite possible to develop a resolution procedure for prefix
records that works acceptably with legacy DNS resolvers and meets the
needs of network admins.
[...]
The way to do this is to introduce a pointer record using CNAME as
_prefix.exists.example.com TXT "Policy1"
*.example.com CNAME _wildcard.example.com
_prefix._wildcard.example.com TXT "Policy2"

I don't believe this will work since CNAMEs have to be the only thing
in a given node, and so a wildcard CNAME would conflict with all other
wildcard usage, such as wildcard MX records.


-wayne

[Hallam-Baker, Phillip]

All SPF does is provide a mechanism whereby sending parties can
describe their outgoing edge mail servers. The recipient has the
absolute right to interpret that data in any way they see

fit. That is

the entire point of a spam filtering scheme.

You have long advocated this position, but unfortunately the
definition of "outgoing edge mail servers" is not a nice,
clean, crisp concept. It sounds good, but unfortunately, it
doesn't work.

OK, "All SPF does is ATTEMPT TO provide a mechanism whereby "

Happy now?

It does not matter which way you try to slice it, the sender of the
message has no connection to any of the forwarder mechanisms or any
other part of the email infrastructure.

At some point there is a boundary between infrastructure the sender has
control of and where he does not. That boundary is very clearly defined
in my universe but even if it was ambiguous it would still exist.

[wayne]

Post by Hallam-Baker, Phillip

All SPF does is provide a mechanism whereby sending parties can
describe their outgoing edge mail servers. The recipient has the
absolute right to interpret that data in any way they see

fit. That is

the entire point of a spam filtering scheme.

You have long advocated this position, but unfortunately the
definition of "outgoing edge mail servers" is not a nice,
clean, crisp concept. It sounds good, but unfortunately, it
doesn't work.

OK, "All SPF does is ATTEMPT TO provide a mechanism whereby "
Happy now?

Sorry, but no..

Post by Hallam-Baker, Phillip
At some point there is a boundary between infrastructure the sender has
control of and where he does not. That boundary is very clearly defined
in my universe but even if it was ambiguous it would still exist.

The problem is that for different identities, this "boundary" is
different. In particular, the boundaries between the SPF identities
(2821.MAILFROM and 2821.HELO) are different than SenderID (PRA).


-wayne

[Nicholas Staff]

"Two will leave but only one shall return"...I'm by no means suggesting
that's a desirable approach to decision making but we've managed to get
ourselves into a place where I think it's now the best way out. Fortunately
since this incompatibility will result in email that should have been
received not being received I can't imagine the fight lasting very long
(when the president of one company can't send an email and the president of
another company can't receive that email, one of those companies will be
making changes to their messaging infrastructure). The alternative, having
the IETF Chair or IESG make the decision, would in my opinion generate so
much bad blood for such a long time that it would be detrimental to most
everything else the IETF is involved in.

Ultimately the technology that breaks email less will win regardless of
which one has more benefits or which one offers better protection for this
or that. Form follows function.

Thanks,
Nick

Post by Hallam-Baker, Phillip

All SPF does is provide a mechanism whereby sending parties can
describe their outgoing edge mail servers. The recipient has the
absolute right to interpret that data in any way they see

fit. That is

the entire point of a spam filtering scheme.

You have long advocated this position, but unfortunately the
definition of "outgoing edge mail servers" is not a nice,
clean, crisp concept. It sounds good, but unfortunately, it
doesn't work.

OK, "All SPF does is ATTEMPT TO provide a mechanism whereby "
Happy now?
It does not matter which way you try to slice it, the sender of the
message has no connection to any of the forwarder mechanisms or any
other part of the email infrastructure.
At some point there is a boundary between infrastructure the
sender has
control of and where he does not. That boundary is very
clearly defined
in my universe but even if it was ambiguous it would still exist.
_______________________________________________
Ietf mailing list
https://www1.ietf.org/mailman/listinfo/ietf

[Nicholas Staff]

"Two will leave but only one shall return"...I'm by no means suggesting
that's a desirable approach to decision making but we've managed to get
ourselves into a place where I think it's now the best way out. Fortunately
since this incompatibility will result in email that should have been
received not being received I can't imagine the fight lasting very long
(when the president of one company can't send an email and the president of
another company can't receive that email, one of those companies will be
making changes to their messaging infrastructure). The alternative, having
the IETF Chair or IESG make the decision, would in my opinion generate so
much bad blood for such a long time that it would be detrimental to most
everything else the IETF is involved in.

Ultimately the technology that breaks email less will win regardless of
which one has more benefits or which one offers better protection for this
or that. Form follows function.

Thanks,
Nick

Post by Hallam-Baker, Phillip

All SPF does is provide a mechanism whereby sending parties can
describe their outgoing edge mail servers. The recipient has the
absolute right to interpret that data in any way they see

fit. That is

the entire point of a spam filtering scheme.

You have long advocated this position, but unfortunately the
definition of "outgoing edge mail servers" is not a nice,
clean, crisp concept. It sounds good, but unfortunately, it
doesn't work.

OK, "All SPF does is ATTEMPT TO provide a mechanism whereby "
Happy now?
It does not matter which way you try to slice it, the sender of the
message has no connection to any of the forwarder mechanisms or any
other part of the email infrastructure.
At some point there is a boundary between infrastructure the
sender has
control of and where he does not. That boundary is very
clearly defined
in my universe but even if it was ambiguous it would still exist.
_______________________________________________
Ietf mailing list
https://www1.ietf.org/mailman/listinfo/ietf

[Hallam-Baker, Phillip]

There are several known conflicts, as outlined in the appeal,
and they don't begin with "the sender intends".

You appear to refer to:
http://www.mhonarc.org/archive/cgi-bin/mesg.cgi?a=ietf&i=200508250045.27
704.julian%40mehnle.net

* Many mailing lists rewrite the MAIL FROM identity when distributing
messages, but do not change the header (PRA) identities. And they
are
not required to do so by RFCs 2821 or 1123 or any other current IETF
standards.

* Many organizations with their own domains outsource their bulk
message
sending (newsletters, etc.) to ESPs, who use their own domain in the
MAIL FROM identity and the organization's domain in the From:
header,
but do not add a Sender: header.[12]

* If the MAIL FROM is empty ("MAIL FROM:<>"), the MAIL FROM identity,
as
defined by the SPF specification, falls back to HELO identity[5,
section 2.2], while the PRA identity is usually unpredictable.


The first is simply a KNOWN FAILURE MODE of Sender-ID. The PRA check is
known to fail in certain circumstances, just as the SPF check is known
to give false positives. In both cases the overwhelming number of false
positives come from poorly maintained records, not the internals of the
protocol.

The second is also a known failure mode of the PRA check. That is why
the bulk mail senders have been adding Sender-ID records and adding
From: headers. Paid bulk senders that have not fixed this already went
out of business. PRA comaptibility is a checklist compliance item in all
RFPs for that type of business. If you want to send bulk email you
already have to meet this criteria, PRA checking is already live at
several anti-spam vendors and it is not going to be turned off.

The final case is one that Lyon and others strongly assert should be
handled by a BATV type mechanism. Treatment of bounce mail is outside
the scope of PRA because it can be handled much more effectively by
other means.


Since all these 'failures' are simply known properties of the PRA check
there is absolutely no value in changing the version string. The PRA
implementations are certainly not going to follow this advice if it is
made. All that the IESG would achieve is to further confuse and
complicate deployment of SPF/Sender-ID by giving advice that is
ill-founded.

Only the receiver of an email has any right to decide how their spam
filter is going to work. The purpose of SPF is to provide the sender a
mechanism that helps them to pursuade the recipient to receive the email
message.

The way that all email authentication checks work in practice is to look
for any form of evidence that would allow the mail to be whitelisted.
The fact that an email message might fail a particular test is
irrelevant, the receiver is trying to help the sender to pass.

[Julian Mehnle]

Post by Hallam-Baker, Phillip
Since all these 'failures' are simply known properties of the PRA check
there is absolutely no value in changing the version string.

Of course there is. The fact alone that S-ID has different "failure
modes" than SPF does, justifies a clear separation between those two
"experiments".

Post by Hallam-Baker, Phillip
The PRA implementations are certainly not going to follow this advice if
it is made. All that the IESG would achieve is to further confuse and
complicate deployment of SPF/Sender-ID by giving advice that is
ill-founded.
Only the receiver of an email has any right to decide how their spam
filter is going to work. The purpose of SPF is to provide the sender a
mechanism that helps them to pursuade the recipient to receive the
email message.

Please be aware that your personal view of what is the purpose of SPF is
far from authoritative.

Furthermore, this is _not_ about policing receivers on how they filter
their incoming mail. This is about the IETF publishing conflicting
specifications. (Yes, I am aware that _you_ don't see any conflict.
That however is besides the point of this paragraph.)

[Alan DeKok]

Post by Hallam-Baker, Phillip
Only the receiver of an email has any right to decide how their spam
filter is going to work.

Sure, but the intent of the sender, and/or owner of the SPF record
matters, too. Common consent makes the net work. Otherwise, people
could send HTTP GET requests to an MX, and claim it's their "valid"
interpretation of MX records.

If a recipient doesn't want to use SPF records in the way the
publishers intended, that's their right. But they shouldn't claim
that their interpretation is compliant.

If the SPF authors believe that another proposal has an incompatible
interpretation of SPF records, then that belief should be relevant to
the discussion. Otherwise, any large company can DoS the IETF by
publishing incompatible interpretations and/or implementations of
proposals they don't like.

Alan DeKok.

[Julian Mehnle]

Post by Hallam-Baker, Phillip
Which would at the same time provide an opportunity to address the one
part of SPF/Sender-ID that does give me significant concern, the
exclusive appropriation of the TXT record.
A prefixed record would be much less likely to collide with other
records.
A proposal has been made to cut an new RR but as the group discovered
50% of the legacy infrastructure does not support new RRs despite
claims to the contrary. Support in this case has to be production
quality, not the ability to coax particular bits out of a server in
certain limited circumstances that no network admi is ever going to
accept on a production server.

What about the new SPF RR type (99) recently assigned by IANA?

$ named -v
BIND 9.3.1
$ grep TYPE99 /etc/bind/zones/net.mehnle
@ IN TYPE99 \# 15 0e763d73706631206d78202d616c6c

$ dig -v
DiG 9.3.1
$ dig mehnle.net TYPE99 +sho
\# 15 0E763D73706631206D78202D616C6C

$ host -V
host version 991529
$ host -t 99 mehnle.net
mehnle.net 99 # ( ; unknown type
0E 76 3D 73 70 66 31 20 6D 78 20 2D 61 6C 6C ; .v=spf1 mx -all
)

[Hallam-Baker, Phillip]

As has recently been pointed out on the namedroppers list, the dual
track RR and TXT approach does not work. It leads to ambiguities when
the records do not match - which they will inevitably dur to the DNS
protocol.

-----Original Message-----
Behalf Of Julian Mehnle
Sent: Friday, August 26, 2005 5:21 PM
Subject: Re: Appeal: Publication of
draft-lyon-senderid-core-01 in conflictwith referenced
draft-schlitt-spf-classic-02
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Hallam-Baker, Phillip
Which would at the same time provide an opportunity to

address the one

Post by Hallam-Baker, Phillip
part of SPF/Sender-ID that does give me significant concern, the
exclusive appropriation of the TXT record.
A prefixed record would be much less likely to collide with other
records.
A proposal has been made to cut an new RR but as the group

discovered

Post by Hallam-Baker, Phillip
50% of the legacy infrastructure does not support new RRs despite
claims to the contrary. Support in this case has to be production
quality, not the ability to coax particular bits out of a server in
certain limited circumstances that no network admi is ever going to
accept on a production server.

What about the new SPF RR type (99) recently assigned by IANA?
$ named -v
BIND 9.3.1
$ grep TYPE99 /etc/bind/zones/net.mehnle
@ IN TYPE99 \# 15 0e763d73706631206d78202d616c6c
$ dig -v
DiG 9.3.1
$ dig mehnle.net TYPE99 +sho
\# 15 0E763D73706631206D78202D616C6C
$ host -V
host version 991529
$ host -t 99 mehnle.net
mehnle.net 99 # ( ; unknown type
0E 76 3D 73 70 66 31 20 6D 78 20 2D 61 6C 6C ;
.v=spf1 mx -all
)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDD4ewwL7PKlBZWjsRAsJ1AJ9mS+vB3+zp5MVWTB5x5Q6N4oZK1gCgvn+e
hOvx+pNMHSIPVU1Q9HnvzOg=
=+/dM
-----END PGP SIGNATURE-----
_______________________________________________
Ietf mailing list
https://www1.ietf.org/mailman/listinfo/ietf

[william(at)elan.net]

Post by Hallam-Baker, Phillip
As has recently been pointed out on the namedroppers list, the dual
track RR and TXT approach does not work. It leads to ambiguities when
the records do not match - which they will inevitably dur to the DNS
protocol.

Actually what has been pointed out is that it is incorrect to make it
a permanent error if the client when retrieving both RRs checks if
they are the same and finds they are not because in some cases due
to DNS caching the results would not be consistent even if on the
server side it is (only a problem when record was recently updated).

That does not mean you can't make it part of the spec that if both RRs
are published they MUST be the same and that client should check SPF
(type99) RR and if its not present then look for TXT RR. For those clients
where algorithm like that is considered too slow (i.e. spamassasin which
does all dns queries in parallel), then it will have to be that if SPF RR
is received, its data is to be used (no matter if TXT RR as present or not).

--
William Leibzon
Elan Networks
***@elan.net