> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Douglas Otis > Sent: Wednesday, October 12, 2011 12:51 AM > To: [email protected] > Subject: Re: [marf] Suggested changes to draft-ietf-marf-authfailure-report > > 10 macro mechanisms x 10 resolutions per connection represents a hazard, > especially when confronting IPv4 in a growing IPv6 world. How can > defensive strategies deal with shared translation mechanisms without > causing significant disruption? Distributing the potential of SPF > derived transactions emitted by libraries applying script-like macro > expansions represent a real risk of enabling distributed denial of > services. The underlying mechanism of such attacks will be difficult to > identify and impossible to defend against, that can target any domain > not even present within the message. > [...]
Concerns about SPF aren't appropriate fodder for discussion of this draft. Both this draft and RFC5451 make it clear that those issues belong to those protocols, and don't need to be re-hashed yet again in this forum. They are off-topic. > Also too many forget SPF is _not_ an Authentication mechanism. SPF can > offer pass results unrelated to the source IP address also not captured > in Authentication-Results headers. Those making use of SPF need to be > repeatedly reminded of SPF limitations and risks. For example, SPF > selected by Mail From or PRA can not be used to validate receivers of > feedback. This is covered in RFC5451, to which this draft already refers. > Requiring DKIM headers not be redacted also provides spammers a sure > place to encode spamtrap locations. Another don't care for bulk > senders. This, however, is something this group should consider and comment on. Please stick to reviewing the specific content of this draft. Concerns you have with SPF or DKIM should be addressed elsewhere. -MSK, as co-chair _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
