I concur. Trying to slide PRA around the non-consensus wall by making it
one of several optional scopes is not a good answer.
Doesn't making it a hinted scope of a single record solve the concensus
problem, or am I correct to sense the SPF camp is unwilling to try for a
concensus with the SenderID camp?
There needs to be at
least one unencumbered mandatory scope so that deployment does not
degenerate into non-interoperable closed source 'PRA supporters' and F/OSS
based 'SPF supporters' camps. Which is precisely what will happen if
passed along in this form.
Is there is only one record format, with scope as a hint only, then how can the
specification of the DNS record degenerate into multiple camps?
I think both are correct. I think the PASS result will end up being much
more widely used in practice than the FAIL result, as Shelby claims. For
example, I would consider bypassing SMTP verification callouts for
sender addresses when there is an SPF/Sender-ID 'PASS' result, yet I
would never consider actually rejecting mail due to a 'FAIL' result.
However I agree with Tony that this renders the whole thing pretty
worthless.
We already have ways to rate the trustworthiness of IP addresses.
We're introducing all this breakage, requiring hosts to 'upgrade' to
join the Brave New World by performing SRS or some abuse of Resent-*
headers which is inconsistent with RFC2822, and what do we achieve at
the end of it?
Agree that the forwarding breakage is a big factor, but remember for the PASS
case you do not care about this breakage.
There are other ways in anti-spam to use the data that an email came from a
domain as PASS.
Also the proposals could help stop phishing for corporations that publish
"-all" (HARD FAIL) (but within the scope of forwarding breakage).
I can think of reasons why we should ensure that there is a clear
distinction between those addresses which are considered to be an
acceptable RFC2821 reverse-path, and those addresses which are
considered to be acceptable in RFC2822 headers.
If I understood your example correctly, I am suggesting 1 record per domain,
and I have agreed that a hint on applicable scopes is acceptable as long as we
do not end up with different record formats and multiple records, so if you
need to specify different hinted scopes on different domains then I agree you
should be able to.
PRA isn't what I would think of when I think of the word scope. The scope
within which PRA operates is the 2822 message header. Within this scope
there is more than one way to determine which header field is appropriate to
use. PRA is one way. There are others.
If scope were defined by the type of data used to make a determination vice
the method, then I believe there is a limited, bounded set of potential
scopes that can be defined now. Pick different names if you want, but I
think they are:
1. Envelope [2821] ~ mail_from
2. Header [2822] (I would include SUBMITTER here since it's an early look at
this scope)
3. HELO (separate from Envelope because it relates to the MTA and not the
message)
I am not against this if either:
1. A common DNS record is used for all scopes.
2. Or there is a compelling reason a common record can not be used that
overrides the compelling desire to not get fragmentation and proliferation of
DNS records for per-domain anti-forgery.
But the "modular" approach must not serve as an excuse for approving
"among other possibilities" a scope/algorithm for which a massive number
of WG participants (read : a clear majority) have expressed that they
disapprove of because of the IPR encumbrance issue.
What is wrong with approving SenderID/PRA as an optional algorithm scope in
"modular" (common or single or unified) DNS record format?
I am worried about:
1. People being induced to only publish SenderID or SPF records but not both.
2. Endorsing SenderID first or as the only algorithm scope.
I am not so paranoid to think we have to ry to kill SenderID. We can not kill
it. We would be much better off to embrace it carefully (force it into a
common DNS record so other algorithms do not get locked out).
Some compelling reasons for a single DNS record which does not specify
algorithm scope:
[snip]
This is all well covered stuff that was decided months ago.
I don't think it is a productive use of this working group's time to
re-raise issues that have already been decided just because someone
new has joined the working group.
If you and everyone else is sure that all my points were covered from the same
perspective as I am suggesting, then so be it.
Then again, such a generalization could be a way to mask some points which were
not covered.
I think you have written here that you are not against PRA using SPF records,
and I have written that I am not against a single DNS record that specifies all
intended scopes, so I hope you are writing about the same history that I am.
I see basically two camps in this list. One camp wants SPF as the mandatory
standard. The other wants SenderID to be approved. Rather I am interested in
getting a concensus.
Reading the complete archive will help you understand why the
decisions were made. You may not agree with those decisions, but so
be it.
I have an extremely large archive of discussions I have made over the past
several years. Reading that might help you understand my perspective. You may
not agree with my perspective, nor have a month of time to read all my
historical perspective, but nevertheless I think we are both entitled to
express our opinion, especially about an important decision that affects all
e-mail.
That is to say do not assume your history is more important than my history (or
perspective).
Okay I made my opinions clear and will be a bystander for next 2 days or so...
Thanks,
Shelby Moore