-----BEGIN PGP SIGNED MESSAGE-----
Thanks for your review.
Douglas Otis wrote:
The email provider must be held accountable in any meaningful approach
for abating abuse. However, SPF avoids such accountability. A provider
may feel SPF based reputation systems are of little concern to them, but
it should be of tremendous concern for their customers, who are often
little more than domain owners.
Why do you think ISPs must be held accountable instead of domain owners?
Only signatures offer domain owners a modicum of control and oversight in
their pursuit of protecting their domain's reputation.
Unless providers can assure their customers that there are no conflicts
within all message PRAs, any other customer would be allowed to create
If you are talking of cross-user forgery, see SPF, section 10.4. This
isn't something that can generally be solved by an authorization protocol
that works with a granularity of IP addresses.
If you are talking of something else, I don't know what it is.
This harm could originate from a Zombied computer of such a customer.
The abuser may utilize SPF records to obfuscate where the message
originates to prolong their success, when seeing such messages are not
blocked by the sending server.
How could SPF records be used to "obfuscate" a message's origin? The last
time I looked, SPF didn't suppress the generation of "Received:" headers.
SPF based reputation systems could employ local or divergent databases
that attribute domain abuse based upon the "assumed" sender.
So what? Receivers are already doing the same with IP address white- and
black-lists. The world has not gone up in flames, though.
How can the domain owner restore the use of their domain, after their
provider naively believes they can assume how a record will be
interpreted which has an undefined scope?
(I assume you aren't implying that the concepts of accountability and
reputation are fundamentally flawed.)
There are no SPF records with an undefined scope. If, for v=spf1 records,
receivers choose to apply Sender-ID's inconsistent scope definition (PRA)
over that of SPF itself, is it SPF's fault?
Have you complained already to Microsoft and the IESG about Sender-ID
redefining v=spf1 records? If not, why do you keep bringing up this issue
here? To say that even though this inconsistency is not SPF's fault,
another draft can always be employed to destroy its usefulness?
What if I submitted a draft to the IETF that conflicted with the DomainKeys
specification? Would that make DomainKeys useless (or harmful)?
10. Security Considerations
With this draft mandating more than one hundred DNS lookups,
The SPF specification does not "mandate more than one hundred" DNS lookups.
It mandates that a receiver must be prepared to perform at most 111 DNS
lookups. This does not mean that the usual case is anywhere near that.
this raises a concern regarding how the 20 second time limit is employed.
A local recursive DNS resolver may act as a UDP amplifier. Congestion
avoidance depends upon the application making the requests to wait, in
order to maintain stability.
This sounds like a valid concern.
There should also be a warning about acceptance of duplicate records.
What do you mean by "duplicate records"?
Again, thanks for your review.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
-----END PGP SIGNATURE-----