Re: NDNs considered harmful

Rich Kulawiec wrote:
> [ On-list or off-list replies only, please; never both. ]
[Do us a favor and present your "list etiquette" note to most of the 
posters here as well. I generally try to prune all the unnecessary 
addresses but forgive the few oops.]
> On Thu, Aug 12, 2010 at 08:36:08PM -0400, Hector Santos wrote:
> > The valid return path is a SMTP requirement and it MUST be valid at
> > the time it is issued by the sender.  Testing it is a VALID option
> > to perform for the simple reason ERROR REPORTING is a required
> > possibility.  It must not be invalid.
> Welcome to 2010. 
Huh?  This isn't new stuff or issues.

> That's all very nice, but practical reality
> overrides it. 
No it doesn't. Following the SMTP recommendations generally worked the 
best.
> The RFCs allow many things, but some of those
> are no longer a very good idea, and some of them are downright
> dangerous.  
I have no problem with the SMTP specification, except when there are 
relaxed provisions (in any protocol) which allowed for abuse, 
ambiguity and most of the issues we have today.
> Or to put it another way, de facto operational practice
> supersedes de jure specifications indicating what we *could* do,
> if we were freed of all constraints imposed by reality.
I get your point, but I don't agree with you. I don't think the 
industry would of survive this long if there was not a solid set of 
inherent and expected protocol consistency followed by all automated 
software.
In todays highly abusive "bad guy" age, one fundamental idea is 
following SMTP compliancy which works extremely well to filter a good 
chuck of the bad actors. That includes return path verification.
> > I don't see how it allows spammers to bypass security measures. 
> That's probably because you haven't read the original source material
> that I referenced. 
I probably didn't need too because u said nothing knew. But I am sure 
I have in the past and I just didn't agree. Usually the same 
characters with one sided opinions.
> [1]  Extensive analysis of this technique was done
> during the summer of 2004 on spam-l, when we caught the incompetent
> morons at Verizon doing it. 
Verizon had a poor implementation that I recalled allowed for 
potential loops.  It wasn't a good implementation and poor case for 
judging.
> That analysis conclusively demonstrates that
> callbacks support, enable and facilitate spam and DoS/DDoS attacks.
Verizon.NET gets attacks for all sorts of reasons simply because of 
who they are. CBV was not the culprit.
> This is so well established, by the way, that it's a BCP to blacklist
> those caught doing it, and there are multiple public and private resources
> which do exactly that.
This would suggest bounces in general are subject to blacklisting. 
However, I will note an instance where it was personal issue to block 
people they didn't like.
> More generally, any putatively defensive technique which permits unknown
> third parties to generate outbound traffic from *your* operation to
> arbitrary destinations of *their* choosing is clearly a very bad idea.
Again, that would imply that a general bounce is prone to a high 
incident of blacklisting and that is simply not the case.  We would 
have major problems is that was the case.  That is not to suggest that 
many system do not count or analysis the bounce sources.  But to black 
one is generally because of abuse and in the case of CBV - poor 
implementations.
> ---Rsk
>
> [1] For example, and this condensed outline of just one of many possible
> scenarios is NOT a substitute for reading the original source material:
> consider what happens when an abuser registers a throwaway domain and
> points the MX's for it at the victim's MX's, then uses a few million
> zombies to simultaneously send traffic putatively from that throwaway
> domain to mail servers which use callbacks.  This is not a theoretical
> attack, by the way.
Well, first of all, I am not advocating any CBV standardization or 
across the board adoption. It is a implementation just like any other 
non-standard implementations of various anti-forgery techniques in 
play by various systems.
Second, seven years of implementation with a few thousand 
installations has shown a high popularity and very successful case of 
usage with little to no repercussions.
Third, there were early issues that were learned and required fine 
tuning. honeypots, for example.
Forth, in our implementation, CBV is the last test in a suite of tests.

    RBM (operator defined rule-based message filters)
    DNSRBL
    SPF
    CBV

Fifth, Caching is important.

Lastly, the above scenario is not specific to dealing or a root cause 
by CBV, but a general issue across the board.  Lacking any 
anti-forging techniques, you are vulnerable to a higher degree with 
your BOUNCE requirements - that was the problem created by SORBIG Dual 
Blitz DoD attacks in 2003 that finally work up the industry and begin 
the efforts to find and invent new anti-spam email techniques .  These 
attacks have to be dealt with regardless if you have CBV or not.
Look, I am sticker for optimization. I would be the first to throw 
away CBV or any other idea if it didn't have value and was a major 
overhead issue.  Taking your advice, pointing to SPAM-L is just not 
convincing enough, wasn't back in 2003, nor 2004 with the Verizon.NET 
version, although I do recall it was poor, and hasn't been since that 
point on.
Other software also support CBV out of the box, I believe Exim and I 
believe there is SendMail CBV Milter and there are Microsoft SMTP 
ActiveX tools, etc, etc.  Clearly, they are not all wrong in believe 
in an method that does work.
With that said, will I advocate a standard for this?  No. Its a KLUDGE 
and wouldn't work well in a widely adopted manner.  Furthermore, no 
extension will make it work because a key reason why CBV does works is 
because it deals with legacy SMTP client issues which in my view, is 
the #1 problem in addressing the spam dilemma.
Thanks for your comments and input.

--
Sincerely

Hector Santos
http://www.santronics.com