[Top] [All Lists]

Re: NDNs considered harmful

2010-08-13 08:59:46

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

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.


[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)

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.


Hector Santos