On 10/4/11 11:43 PM, Eliot Lear wrote:
For the record, I tend to dislike pollution of the RFC series with PR
blurbs as well. This having been said, I would be far more interested
in a discussion about the actual substantive content of the document.
Eliot
Eliot,
Thank you for asking.
In addition to PR and copyright issues that forbid modification of the
draft, there are a few technical issues that also affect the MARF draft
as well. The assertion of being DDoS experts does not explain why
potential DDoS attacks perpetrated by leveraging recipient resources
necessary for processing SPF scripts had been overlooked. SPF can be
exploited to initiate a highly distributed demand against any targeted
domain unrelated to any domain found within an attacking email campaign.
The assertion that it is difficult to forge a DKIM message overlooks the
purpose of feedback and what these reports imply. DKIM does NOT assure
a domain can be held accountable for any unsolicited message which
creates some risks to feedback resources. The domain of the DKIM
signature may serve as a basis for permitting feedback to the specific
domain, but should not be used to confirm any unrelated domains.
A more serious problem exists with the use of SPF in permitting
feedback. This problem is made more problematic by
Authentication-Results headers not capturing the IP address used to
"verify" SPF records, although the MARF report includes a purported
Source IP address. There is still no way to determine how this
purported IP address information had been derived, or how it might
relate with SPF verification assertions. An SPF record can be crafted
to return a pass result unrelated to the originating IP address. As
such, SPF can be subverted to gain feedback access with lax validation
results returned in Authentication-Results headers. This oversight had
been officially challenged, but never corrected. :^(
Any domain can resolve any IP address. The draft's assertion that
forging the IP address is difficult must be considered in respect to the
use of SPF in qualifying for feedback. The source IP address does not
receive feedback. The feedback relationship is further undermined with
consensus on which message element, whether the EHLO, the MailFrom, or
the PRA selects the SPF resource record. In addition, feedback is
likely to occur when SPF assertions fail, so it becomes imperative to
understand what was used to initially qualify SPF feedback relationships.
In addition, this draft describes use of third-parties located at
different domains without advising how these entities being given access
to feedback streams are to be vetted, or whether they should be allowed
at all.
-Doug
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf