Re: Last Call: <draft-jdfalk-maawg-cfblbcp-02.txt> (Complaint Feedback Loop Operational Recommendations) to Informational RFC

[Douglas Otis <[e-mail]>]

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