On Nov 30, 12:51am, Hector Santos wrote:
}
} ----- Original Message -----
} From: "Bart Schaefer" <schaefer(_at_)brasslantern(_dot_)com>
} To: "ASRG" <asrg(_at_)ietf(_dot_)org>
} >
} > Suppose a large ISP were to adopt the "caller ID" scheme (one
} > already may have, see below). A spammer forges winserver.com MAIL
} > FROM: on a couple of million messages destined for that ISP,
} > distributed across all its dozens of MXs. They all begin connecting
} > to your MX to ID the caller. Are you prepared to handle that load,
} > or have you just been DoS'd into oblivion?
}
} I was thinking more about this when it dawn on me, this is non-issue.
}
} This is already controlled by server access and availability.
You're missing the point.
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.
} 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? ALL of your mail is going to stop flowing with
this error until such time as the flood of caller-ID connections stops.
And assuming the hypothetical ISP in the example does wait and try again,
you'll have those interruptions repeatedly until all the forged messages
drain out of the ISP's queues.
This leads to a further question (of academic interest only, really): You
have said that your system returns a 4xx to the sender when the caller-ID
callback is unable to connect. What does it do when the callback gets a
4xx response itself?
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg