On Jan 13, 2009, at 9:02 AM, SM wrote:
Hi Doug,
At 18:53 12-01-2009, Doug Otis wrote:
(see section 3.4.1 of [MAIL]) of an address, the "pvalue" reported
along with results for these mechanisms SHOULD NOT include the
local- part.
"SHOULD NOT" is not an recommendation to do something.
Someone marketing their services using email will read this as saying
"Unless local-part macros are included within the SPF record,
annotations will be limited. To be noticed, local-part macros are
required." An earlier draft published an example of a local-part
exploits leveraging cached SPF records. The exploit is able to
sustain sizable attacks while utilizing little of the attackers
resources, beyond the sending of email. The more a DNS cache is
inundated, the more effective the attack becomes. :^(
Are you recommending coercion to resolve conflicts? Not all SMTP
The question I asked was about implementations. I'm at a lost as to
why you see that as recommending coercion.
Since the IP address of the SMTP client is omitted in the
Authentication-Results header, domains must be assessed on a fairly
static basis. Using domains in the case of SPF or Sender-ID increases
the number of assessments by more than an order of magnitude, that
will also need to rely on the actions of many additional entities.
The indirection of domain assessment significantly impairs effective
responses to PRAs being exploited. The exploit may have been enabled
by compromised access, or imprudent record use by some inbound
provider, neither directly be controlled by the domain. As recipients
fall prey, mounting damages will likely have a coercive effect. Since
assessment of the SMTP client is precluded by the Authentication-
Results header, this eliminates practical, prompt, and comprehensive
assessments, and places recipients at much greater risk. The omission
shields providers from being held accountable by pointing to some
domain, rather than toward the likely source of a problem. This
indirection comes at the expense of recipient security. Too bad
security and authentication appears to have lost its meaning. :^(
-Doug
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf