On Nov 30, 3:35pm, Hector Santos wrote:
}
} ----- Original Message -----
} From: "Bart Schaefer" <schaefer(_at_)brasslantern(_dot_)com>
}
} > You might believe it's a non-issue for you, but that doesn't make it a
} > non-issue for everyone who might become a victim of it. Recommending an
} > approach such as your caller-ID technique is irresponsible, because it
} > can lead to indirect abuse of innocent third parties.
}
} I fail to see how. I would love to see an example.
As my original example doesn't seem to have gotten the point across, I'll
try it another way.
Let's suppose that your product with WSCAP included is wildly successful,
and 10,000 sites deploy it. Collectively call these sites W.
Further suppose that some other vendor likes your suggestion and deploys
an equivalent system to another 10,000 sites. Call these Q.
Now add spammer X and third-party site V.
X sends 1000 messages to each of the sites in W, forging V's domain in
the MAIL FROM:. What happens to V's MX host?
Next X sends 1000 messages to each of the sites in Q, forging random
domains from W. What happens? (Remember that some fraction, possibly
all, of the hosts in both W and Q are performing the caller-id probes
with non-empty MAIL FROM: because they don't want to be mistaken for a
wormspew bounce.)
In the victim V case, an innocent third party has been DDoS'd by the
servers in set W. That there currently exist other mechanisms by which
a similar DDoS could be caused is not justification for recommending
yet another one.
In the Q vs. W case, what stops all the systems involved from deadlocking,
as each site in W tries to caller-ID the non-empty MAIL FROM: generated by
the servers in Q, which then try to caller-ID the non-empty MAIL FROM:
generated by the servers in W, and so on around again?
} > } This is already controlled by server access and availability.
} > } The number of receiver threads are definable by the sysop with a
} > } server 421 greeting response of:
} > }
} > } 421 domain, Service not available. Try again later
}
} > How is this a non-issue?
}
} Retries are part of the functional specification of SMTP systems.
That's not what I mean.
How is it a non-issue _for the system that is issuing the 421 response_
that it has become so busy that it is _necessary_ for it to issue such
response?
Why is it a non-issue that timely receipt of email by your servers has
been interrupted, even if temporarily?
} > ALL of your mail is going to stop flowing with
} > this error until such time as the flood of caller-ID connections stops.
}
} No, its not. Again, I fail to see this. I have WCSAP running for nearly
} 5-6 days now with very little issues that is being worked out.
That _you_ have WCSAP running is irrelevant. The point is to consider
what happens when someone else has WCSAP running, and further that said
someone else (or maybe many someones) is hammering some unrelated server
(maybe yours, maybe mine, maybe the IETF's) with caller-ID callbacks for
mail that the unrelated server never originated.
} > you'll have those interruptions repeatedly until all the forged messages
} > drain out of the ISP's queues.
}
} Not an issue.
Again, why not?
} But BY FAR, with EMPERICAL DATA on hand, that this is the best METHOD
} out there to combat illegal spoofing by spammers.
All challenge systems are highly effective when deployed in isolation.
The troubles begin when you consider what happens if they become widely
distributed.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg