On Tue, 2004-06-29 at 11:39, Greg Connor wrote:
--Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
| Operators of MTAs are free to change nothing; and things will work
| about as well as they do now -- until spammers escalate things so that
| overly-broad IP blacklists are applied widely and the MTA's IP address
| finds its way onto them. Possibly, they'll even be miraculously lucky
| and its IP address _won't_ find its way onto any blacklist. ;^)
The above is also true of Unified SPF.
The major problems result from weak transversal authorization determined
by SPF. You may consider these the same, but the details entailing such
is important. ACCREDITATION can not be administered if the
Authentication and Authorization are not confirmed for unknown, in
addition to that determined to be accepted. It is apparent that SPF
only provides weak path assurance regarding an accepted message. The
assurances for either unknown or rejected messages are nil. That is a
huge category left open.
Doug- I couldn't understand this paragraph, and I think it's important to
understand what you're saying here -- some of the keywords suggest that you
feel it's an important point.
I am working on a more complete response but felt there was a demand
that something be said immediately...
Here are some followup questions.
Q. What is a "transversal authorization?" What makes one weak vs. strong?
There are undefined boundaries where SPF/CID _may_ be checked. Headers
are easily forged and should there be a machine internal to an undefined
administrative region erroneously accepting mail, this puts every
message carried in question. I would call this a weak from of
identification.
What identity is used to assert accountability? Due to this weak from
of identity, SPF/CID _MUST_ never be used to assert accountability. If
mail was injected somewhere inside a nebulous region devoid of SPF/CID
checks, how is this detected? Are those spoofed to be soiled by a
machine somewhere not tied down properly?
Q. Regarding this sentence, I couldn't quite unwind what you meant, though
I am probably close to understanding:
ACCREDITATION can not be administered if the Authentication and
Authorization are not confirmed for unknown, in addition to that
determined to be accepted.
I understand this to mean "If the result is "unknown" then accreditation
cannot be applied. I would take that as a given, but I believe that is the
same with both SPF and CSV.
If _everyone_ fully implemented SPF, there would still be the category
Unknown. If everyone implemented CSV, this category would no longer
exist. In addition, the identity established using CSV provides a means
to apply accountability. Those being spoofed would not be impacted,
just the administrative domain that failed to secure access to _all_
their machines.
Is this meant to imply that the existence of an "unknown" state itself
is a defect? If I understand correctly, CSV also has an "unknown"
state. In both proposals, I believe the domain owner has to make sure
a PASS or "known good" result is received before honoring any
accreditation, right? Anyway, let me know if you meant something
else here that I am not understanding.
Yes, there would be an unknown state, but only for those that failed to
implement CSV. In the normal operation of SPF/CID, an unknown state
must be allowed as an escape for those unable to publish a comprehensive
list of domain and address relationships. SPF/CID is unable to scale for
a comprehensive list, so by design there exists the unknown state. I
venture to say that SPF/CID may not handle even a conservative amount of
publishing of these relationships.
The full complexity of these relationships may become more pronounced
once SPF/CID checks are widely implemented and more domains attempt to
"close" their lists due to spam attacks. Attacks deployed against
hapless domains that would otherwise wish to publish more but are unable
to comply listing all points of mail access.
Q. Regarding these two sentences, please clarify:
It is apparent that SPF only provides weak path assurance regarding
an accepted message. The assurances for either unknown or rejected
messages are nil. That is a huge category left open.
Is this meant to state that a CSV "authorized" result is stronger than an
SPF PASS result?
The area of policy only applies to the MTA server and not to users of
mail. Reputation must only apply to the administration of policy for
the MTA. Reputation can not scale to the user nor should a mail stream
be considered secure to base assumptions about where a message was
derived. Who gets credited, should the published permitted path for a
message determined abusive traverse many domains? There is virtually no
cost associated in creating a user. There is some cost, albeit small,
for creating a domain.
Why do you say that?
Limiting the results of a check to answer just the question regarding
the channel and NEVER the message, then it is possible to ensure a valid
answer.
Both are comparing an IP address to a DNS record, and in that regard
seem to provide very similar features from the technical side. Do you
mean that there is a difference in how the records will be interpreted
by users?
These lists are not technically the same. One is a list to correlate
domains and addresses to express permitted traversals, the other is a
list of servers administered by a domain. These sentences include many
of the same words, and may even include some of the same addresses, but
these lists are not the same nor are they intended to answer the same
question.
Is it because of the way the drafts are written?
There is a major difference in paradigms where a slight of hand changing
a word here and there will not mollify these differences.
Publishing in DNS TXT records all mail domain paths using a technique of
linked records is a wholly different goal. I would question the
suitability of DNS for this. DNS is well suited to answer the question
what is the list of addresses associated with a EHLO domain which
provide both Authorization and Authentication with perhaps just an SRV
record.
I'm trying to understand if it is a difference in the design, or just
in how it is used by implementors and explained to users...
The difference is where the problem is addressed. Identify by the name
of the domain attempting to inject mail into the system and stop it
there rather than looking at each message. Each message may easily pass
muster with SPF/CID, in fact, it should be expect this to be the case.
Also what do you mean by "The assurances for either unknown or rejected
messages are nil". What assurance does CSV provide if the status is
unknown? If the status is reject/fail, doesn't that mean reject the
message, and isn't the "strength" of that assertion the same for both SPF
and CSV?
Should CSV be fully implemented, there will be no unknowns as opposed to
SPF/CID. If there is any abuse discovered, the accounting of this abuse
will be accurately applied to the domain and never is the header of a
message trusted. The ability of user to forward mail or use their
favorite access point to send mail containing their return address
remains unchanged. It does however mean for domains to protect their
accreditations, they must be responsive to abate abuse.
To abate identity fraud, I strongly suggest considering the use of
Fenton's "Identified Mail" proposal. This technique scales and does not
threaten the integrity of DNS and Mail in the process. Users will still
be allowed the freedom to send mail but commerce can be protected in a
very strong way against fraud regardless of the path taken.
-Doug